The 2026 Open-Source Endpoint Defender Coverage Map

1. The myth of "defense in depth"

"Defense in depth" has become shorthand for "we run more than one thing." The unstated assumption is that the union of two defenders' rule packs covers more of your risk surface than either alone, and that adding a third narrows the residual gap further. In our experience auditing customer environments, this is true only in the trivial case where the tools observe overlapping inputs. When they observe the same input class — system logs, on-disk file hashes, syslog-derived IPs — the union approaches the larger of the two coverage sets, not their sum.

We tested this assumption directly. Across April and early May 2026, our research squad enumerated 220 distinct attack angles against eleven of the most commonly deployed open-source endpoint defenders: AIDE, AIDITD (in practice, the auditd/Laurel pairing it implies), CrowdSec, Fail2Ban, Falco, GRR Rapid Response, OpenEDR, OSSEC, Samhain, Velociraptor, and Wazuh. Each angle was tied to a specific MITRE ATT&CK technique and, where possible, a public CVE or GHSA advisory. We then mapped which defenders, in their default configurations, would fail to alert on each angle.

The result is a coverage map. It is not a leaderboard. None of these tools is bad. Several are excellent at the one thing they were built for. The map shows where each is structurally blind, where multiple tools share the same blind spot, and where attacker windows of three or more simultaneous blackouts open up inside otherwise-credible deployments. If you run five or more of these tools and have never measured their union, this is the article we wrote for you.

2. The eleven tools, briefly

AIDE. A scheduled file-integrity monitor that hashes a defined inventory and reports diffs. Best at: cryptographically anchoring a known-good filesystem state on rarely-changing assets (firewalls, jump hosts, build agents). It does exactly that one thing, with low false-positive rate and good signal density.

AIDITD. As we documented internally, "AIDITD" is most likely a typo or rebrand reference to the auditd / Laurel pairing rather than a discrete project. Treated here as the kernel-audit-subsystem cohort. Best at: structured per-syscall event capture when paired with a real consumer.

CrowdSec. A modern collaborative IPS that consumes logs, applies behavioral scenarios, and shares decisions with a community blocklist API. Best at: low-latency reaction to credentialed reuse of bad-reputation IPs, and at network-layer anomaly suppression backed by a multi-tenant signal pool.

Fail2Ban. The reference log-anchored IP-banning daemon. Best at: simple, fast, well-understood SSH and basic-auth brute-force suppression on a single host with a small set of well-defined log sources.

Falco. The CNCF runtime-security project, eBPF-default since 0.37, with a mature rule grammar and broad container/Kubernetes integration. Best at: real-time syscall-anchored detection inside container workloads — by a meaningful margin, the strongest open-source peer in this list at that one job.

GRR Rapid Response. Google's open-source remote-forensics framework, with the v4.0 release (December 2025) representing its largest refactor in project history including the new Rust agent (RRG). Best at: structured fleet-wide hunts, especially hash-sweep and YARA-against-fleet patterns, when an analyst is in the loop.

OpenEDR. The Comodo/Xcitium open-source Windows endpoint agent. Best at: providing a baseline behavioral telemetry stream on Windows hosts where licensing precludes commercial EDR. We have to say it plainly: the upstream repo has been dormant since January 2024, with v2.5.1 from September 2022 still shipping with unpatched CVEs. It is no longer fit for the role most deployments still ask of it.

OSSEC. The original host IDS that begat Wazuh. Best at: legacy log-and-FIM hybrid duty on long-lived UNIX hosts where it has institutional inertia. The 4.0.0 release in February 2026 was the first non-bugfix in five years.

Samhain. A long-tenured FIM with optional stealth (XOR-stego config), HMAC-signed databases, and the Yule console. Best at: tamper-resistant integrity monitoring in environments where the threat model includes a privileged adversary mucking with the FIM agent itself.

Velociraptor. The Rapid7-stewarded DFIR platform built around the VQL query language. Best at: ad-hoc live-forensics across a fleet, especially for incident response. Powerful, and ironically also a frequent ransomware target in 2025.

Wazuh. A fork of OSSEC that has grown into a full XDR/SIEM stack — agents, manager, analysisd, indexer, dashboard, vuln detector, SCA, AR. Best at: being the most-deployed open-source XDR by a wide margin, which makes it both the most useful and the most attractive target on this list.

3. Where each is blind

The crisp version of our finding: every one of these tools has at least one structural class of attack that walks past it untouched. Most have several. The table below names the one representative class for each, with the specific advisory or technique that crystallizes it. Commentary follows.

| Tool | Blind class | Anchor reference | |---|---|---| | AIDE | memfd_create fileless exec; on-disk hash unchanged | T1620; AIDE config drift on /sys/fs/bpf | | AIDITD (auditd) | Audit-rule reload race window; ring-buffer overflow with silent AUDIT_LOST | T1562.006 | | CrowdSec | X-Forwarded-For: 127.0.0.1 whitelist abuse; CRLF log-line forgery | upstream issue #3090 | | Fail2Ban | IPv6 /128 ban defeated by /64 rotation; mail-whois RCE on legacy hosts | CVE-2021-32749 | | Falco | io_uring syscall-hook evasion; silent kmod crash | GHSA-7cq5-h4p2-h37p, GHSA-c7mr-v692-9p4g | | GRR | ScheduleFlow missing-authz pre-commit 6855668; AdminUI HTTP Basic | upstream PR #1161 | | OpenEDR | Filename-trust IOCTL self-defense bypass; path-traversal LPE to SYSTEM | CVE-2025-69783, CVE-2025-69784 | | OSSEC | UDP/Blowfish on 1514 pre-4.0; eBPF/syscall threats outside its hook surface | T1014, T1557 | | Samhain | LD_PRELOAD userland rootkits; default unsigned DB tampering | T1574.006, T1565.001 | | Velociraptor | Stale-GUI fleet RCE; rogue-client server RCE; MSI ACL to SYSTEM | CVE-2025-6264, CVE-2026-5329, CVE-2024-10526 | | Wazuh | DAPI deserialization RCE; remoted pre-auth stack overflow on 1514 | CVE-2025-24016, GHSA-q9vv-7w4c-f4cm |

Falco and io_uring

Falco's strongest property — eBPF syscall instrumentation — is also the entry point for its sharpest blind class. The Linux io_uring interface lets userland submit operations to the kernel via shared ring buffers without invoking the syscalls Falco hooks. ARMO and Sysdig published the working assumption in 2025: an attacker can IORING_OP_OPENAT, IORING_OP_READ, IORING_OP_CONNECT, even spawn through IORING_OP_EXEC-class submissions, and the default Falco rule set will not see it. The advisory that crystallizes this is GHSA-7cq5-h4p2-h37p. Compounding it, GHSA-c7mr-v692-9p4g describes a kernel module crash path that disables Falco silently if the kmod driver is in use.

A representative Falco rule that should detect a sensitive read but does not, when the read is issued through an io_uring SQE rather than read(2):

- rule: Read sensitive file untrusted
  desc: Detect attempts to read /etc/shadow by non-trusted programs
  condition: >
    open_read and sensitive_files and
    not proc_name_exists in (trusted_programs)
  output: >
    Sensitive file opened for reading (file=%fd.name proc=%proc.name)
  priority: WARNING

The rule fires on open(2) plus subsequent read(2). It does not fire on a ring-submitted IORING_OP_OPENAT followed by IORING_OP_READ on the same fd. This is structural, not a tuning bug.

Wazuh, where the attack surface is the management plane

Wazuh's CVE backlog over the past eighteen months reads like a tour through every server-side memory-safety failure mode. CVE-2025-24016 is an unauthenticated-from-agent deserialization RCE in the DAPI for versions 4.4.0 through 4.9.0, scored 9.9, with public PoCs and Censys reporting roughly 17,000 internet-exposed Wazuh servers at disclosure time. CVE-2026-25769 and CVE-2026-25770 (both Wazuh GHSA-tracked) extend cluster-side RCE through 4.14.3. GHSA-q9vv-7w4c-f4cm is a pre-auth stack overflow in ossec-remoted reachable on TCP 1514 — the agent ingestion port — the one Wazuh deployments are most likely to expose.

A canonical Wazuh decoder fragment for SSH login parsing illustrates a different class of blind:

<decoder name="sshd-success">
  <parent>sshd</parent>
  <prematch>^Accepted </prematch>
  <regex offset="after_prematch">^(\S+) for (\S+) from (\S+) port</regex>
  <order>protocol,user,srcip</order>
</decoder>

If the upstream log line is forged via CRLF injection in a user-controllable field — a username on a public-facing service, for example — this decoder will happily ingest the forged line as legitimate, attribute the "login" to whatever IP the attacker chose, and pass it to active-response. The injection vector underlies a family of decoder-level evasions tracked across GHSA-fcpw-v3pg-c327 and GHSA-vw3r-mjg3-9hh2.

Velociraptor, the DFIR platform that became the foothold

The Velociraptor advisories of the past twelve months document a trajectory the DFIR community should not look away from. CVE-2025-6264 lets an account with the COLLECT_CLIENT role push a new client.config.yaml to every endpoint in the fleet — effectively, a role-bypass-to-arbitrary-RCE primitive that was actively exploited by ransomware crews in August 2025 (Talos, Huntress, and Sophos all published incident writeups). CVE-2026-5329 is a rogue-client-to-server RCE via crafted queue names. CVE-2024-10526 is an MSI ACL bug that lets a local user achieve SYSTEM via the installer directory's weak DACL. CVE-2025-0914 bypasses the prevent_execve ACL gate. CVE-2026-6290 is a multi-tenant ACL bypass through query().

The pattern is not Velociraptor-specific. Hunt-driven DFIR tools, by design, have hours-long gaps between collections, and concentrate enormous post-exploitation capability behind a single management plane. When that plane is compromised, the DFIR tool is the lateral-movement infrastructure.

OpenEDR, where dormancy is the vulnerability

CVE-2025-69783 and CVE-2025-69784 are both 8.8-class issues in OpenEDR's self-defense IOCTL surface and DLL-injection path-traversal. There is no upstream patch. The vendor's GitHub has been quiet since January 2024. Customers running OpenEDR today are running an agent whose driver is exploitable, whose self-defense is bypassable by renaming a benign signed binary, and whose maintainer has not shipped a security release in over two years. The honest finding to deliver to a board is that OpenEDR has moved from "asset" to "liability."

Fail2Ban, CrowdSec, and the IPv6 problem

Fail2Ban defaults to banning the exact IP that triggered a filter. With IPv6, that means a /128 ban — and any attacker on a /64 (which is the smallest prefix routinely allocated to a residential subscriber, let alone a hosting tenant) simply rotates within their own block. CrowdSec is more configurable but ships the same default. CVE-2021-32749 — the mail-whois RCE in older Fail2Ban — is still encountered on legacy hosts in our customer environments. CrowdSec's X-Forwarded-For: 127.0.0.1 whitelist abuse, tracked as upstream issue #3090, is structurally similar.

AIDE, Samhain, and the disk-anchored ceiling

AIDE and Samhain are excellent at what they do — and what they do is hash files at rest. Anything that does not hit disk — memfd_create fileless execution, process_vm_writev injection, in-memory-only payloads served via mprotect(PROT_EXEC) — never registers. CVE-2025-54389 and CVE-2025-54409 (terminal-escape report tamper and null-deref DoS in AIDE under 0.19.2) are real, and the AIDE GPG signing key expired 2025-06-27, complicating supply-chain trust. But the structural blind is the disk ceiling, not the CVEs.

GRR, when the management plane is the production interface

GRR's AdminUI ships HTTP Basic auth with the upstream README explicitly noting "not for production." Pre-6855668 builds expose ScheduleFlow without proper authorization checks. The ExecutePython flow, when reachable to a non-admin role, is fleet-wide RCE by design. None of these has an assigned CVE; all of them are documented in upstream pull requests and issue threads.

4. The compound-blackout problem

Stacking defenders shifts the question from "is any tool blind?" to "are enough tools simultaneously blind that an attacker has a usable window?"

We define a compound blackout as a moment in time during which three or more deployed defenders, each responsible for a different detection class (FIM, syscall, vuln-detector, hunt cadence, IDS/IPS, cloud audit-log ingestion), are all simultaneously incapable of observing a given technique. Compound blackouts open even when each tool individually advertises high coverage, because their blind windows align in the time domain.

Consider a representative customer environment we audited: AIDE on a 24-hour cron, Wazuh's vuln-detector configured to refresh feeds every 48 hours, Velociraptor in hunt-only mode with manual hunts roughly every 6 hours, Falco running on the eBPF driver with default rules, and auditd backing the standard Wazuh localfile consumers. The advertised stack coverage was, predictably, framed as "five layers." The measured compound blackout matrix told a different story:

The intersection of those five blind windows — the moments where all five are simultaneously unable to observe — is non-trivial. We estimate it routinely runs 4 hours or more per 24-hour day in default deployments.

This is what our Detection Window Auditor (DWA) architecture computes. The shape of the calculation is straightforward: build a per-defender, per-detection-class coverage timeline driven by the defender's actual configured schedule, ruleset, feed age, and hunt cadence; intersect the BLACKOUT segments across the stack for each MITRE technique; rank techniques by how much continuous attacker time the intersection represents. The output is a per-technique ranking of how much continuous attacker time the customer's stack hands over by default. It is the difference between claimed and measured MITRE coverage, expressed in seconds.

5. A defender's response framework

We do not believe one-shot audits are the answer. The CVE landscape moves weekly; rule packs drift; plugin ecosystems acquire new contributors with no signed-release discipline; tool vendors go dormant. The honest framework is a continuous-improvement loop with four cooperating components, each of which we have prototyped against the eleven-tool corpus above.

Stack Coverage Auditor (SCA). Fingerprint the actually-installed defenders, parse their actually-loaded rule packs at runtime, compute the set-union coverage against MITRE ATT&CK Enterprise, Containers, and Cloud, and report the complement — the customer's blind matrix — ranked by exploit-in-wild evidence. This is not a checkbox audit. It is a measurement, and the measurement number matters.

Defense-Tool Supply-Chain Auditor (DTSCA). Audit the supply chain of the customer's defenders themselves. Per-tool fingerprint plus trust-posture manifest: signing-key validity (AIDE's expired 2025-06-27), branch protection, Cosign attestations on falcoctl plugins, channel hygiene for the CrowdSec hub. The point is that your detection stack is somebody else's supply chain risk.

Plugin Trust Auditor. Continuous detection of plugin-compromise indicators across the Falco rule index, Wazuh wodles, Velociraptor exchange artifacts, CrowdSec hub scenarios, GRR artifacts, and OSSEC rulesets. Maintainer-account hygiene, OWNERS-list singletons, threshold relaxation drift, new outbound calls inserted into community rules — these are the pre-compromise indicators that the SolarWinds / xz-utils class of supply attack telegraphs in advance.

Detection Window Auditor (DWA). The time-domain instrument described above. One-second resolution, twenty-four-hour timeline per detection class per host, compound-blackout calculation, boundary visualization, TTP mapping per gap.

The four components feed each other. SCA finds a blind class; DTSCA finds a tool whose supply chain is fragile; Plugin Trust Auditor flags the fragile community rule that was supposed to cover the blind class; DWA shows the time of day that gap is open longest. This is the loop we propose, not a deliverable.

6. If you have never measured your union

If you are running five or more of these tools — and many of our customers are — and you have never measured the union of their coverage as opposed to assuming it, the practical first step is small. Pick the three highest-value MITRE techniques in your threat model. For each, walk every defender's rule pack and answer one question: which rule fires, and in which condition does it fail? Then take the intersection of the failure conditions and ask whether any single attacker action satisfies all of them simultaneously. That intersection is your real exposure for that technique.

We respect what commercial vendors like Microsoft Sentinel and CrowdStrike Falcon Insight bring to this problem; their telemetry breadth and managed update cadence cover several of the structural gaps named above. Open-source endpoint defense remains worth the effort it takes — but only when it is measured rather than assumed. We measure what others claim, and we publish our measurements. If this map is useful to your team, we would rather you build the measurement loop yourselves than buy ours; the loop is what matters. We are happy to share the test catalog underlying this article on request.

The map is not the territory. But the territory is large, the defenders are many, and the attackers are not waiting for our diagrams to settle. Measure.