Research: All three major eBPF security monitors (Falco, Tracee,…

Published research on a telemetry trust boundary weakness affecting the three most widely deployed eBPF-based security monitors.

The finding: eBPF security tools store their runtime configuration in BPF maps (kernel data structures). The Linux kernel has no per-map access control — any process with CAP_BPF can modify any map. None of the three tools protect their maps with available hardening primitives (bpf_map_freeze, integrity checks).

A same-privilege process can modify these maps to suppress all security events. The tools keep running, health checks pass, but detection drops to zero.

Tested against: Tracee v0.24.1, Tetragon v1.4.0, Falco latest. All achieved 100% event suppression with zero logs or errors.

Think of it as: The eBPF equivalent of disabling an EDR agent, except the agent doesn't crash and keeps reporting "healthy."

CAP_BPF is privileged, but realistically available after container escape, kernel privesc, or in misconfigured environments. These are exactly the scenarios these tools are deployed to detect.

Research repo with full details and reproducible PoCs: https://github.com/azqzazq1/SunnyMapBPF

DOI: https://doi.org/10.5281/zenodo.20413161

Impact

An attacker with CAP_BPF capability can silently disable the three major eBPF security monitors by poisoning their BPF maps, resulting in complete suppression of security event detection without triggering errors, logs, or health check failures. This creates a blind spot in security monitoring, allowing malicious activity to go undetected despite the monitors appearing healthy and operational. The vulnerability affects environments where CAP_BPF is accessible, typically after container escapes, kernel privilege escalations, or in misconfigured Kubernetes workloads. There are no known exploits in the wild at this time.

Defensive guidance

Currently, no official patches exist due to the architectural nature of the issue in the Linux BPF subsystem. Tool maintainers can mitigate risk by applying bpf_map_freeze() on configuration maps that do not change at runtime, implementing periodic map integrity verification, and using heartbeat canaries to detect tampering. Operators should restrict CAP_BPF capability distribution to minimize exposure and consider auditing bpf() syscall usage to detect unauthorized map modifications. Kernel-level mitigations such as per-map owner binding or BPF token scoping are not yet broadly available. These mitigations raise the bar but do not fully eliminate the risk.

Summary

This research demonstrates that Falco, Tracee, and Tetragon, the three widely deployed eBPF-based security monitors, store their runtime state in BPF maps that are writable by any process with CAP_BPF capability. Since the Linux kernel lacks per-map access control and these tools do not employ hardening primitives like bpf_map_freeze or runtime integrity verification, a same-privilege attacker can modify these maps to suppress all security telemetry silently. Empirical tests showed 100% event suppression with no errors or health check failures, effectively disabling the monitors while they continue running normally. The vulnerability requires CAP_BPF, which is privileged but realistically obtainable in post-exploitation scenarios such as container escapes or kernel privilege escalations. Mitigation strategies include applying bpf_map_freeze on static maps, implementing periodic integrity checks, restricting CAP_BPF access, and auditing bpf() syscalls. Kernel-level fixes do not currently exist, making this an architectural issue in the Linux BPF subsystem.

Research: All three major eBPF security monitors (Falco, Tracee, Tetragon) can be silently disabled via BPF map poisoning

Discussion

Links cited in the discussion

Impact

Defensive guidance

Summary

References

Community reviews

Discussion

Links cited in the discussion

AI analysisMachine-generated, updated 27 May 2026, 16:03 UTC

Technical details

References

Community reviews