eBPF Rootkits: Why Underground Actors Are Taking Notice

eBPF has a newly disclosed security flaw that anyone running it should know about.

This requires local or already-authenticated access to reach.

For years, eBPF (extended Berkeley Packet Filter) has been one of the most celebrated technologies in the Linux kernel.

The same eBPF capabilities that are attractive for defenders, however, can be a powerful weapon in the hands of attackers.

Flare’s research found underground forum posts sharing eBPF rootkit code and step-by-step tutorials.

Flare monitors forums, marketplaces, and paste sites in real time, so your team sees new tooling, exploits, and chatter early enough to track eBPF threats.

Anyone running eBPF is exposed, specifically wherever eBPF is actually deployed rather than just licensed or installed somewhere unused.

Linux is extremely popular in production servers and giants like Google, Cloudflare, and Meta rely on it daily.

Traditional Linux rootkits typically rely on loadable kernel modules (LKMs) to hook system calls and hide malicious activity.

What an attacker actually gains: the advisory describes a real security impact once the vulnerable path is reached.

An eBPF malware can hook into kernel functions, observe system calls, or inspect and modify network traffic using the same kernel-supported bpf() interface as legitimate tools like Cilium.

Its programs run without loading a kernel module, so a routine lsmod check can miss them.

This is tracked as CVE-2017-16995 -- use that identifier when checking vendor guidance or scanner results.

It lets developers run sandboxed programs inside the kernel without writing kernel modules, while powering everything from network monitoring to security tooling.

eBPF rootkits are moving from conference talks to underground forum tutorials, and by the time one loads on a host, it’s built to evade your usual checks.

Lastly, in October 2025, Synacktiv reported LinkPro after investigating a compromise that began with an exposed Jenkins server.

In one exploit sample we reviewed, the author credited Claude in a source code comment with generating the BPF instructions.

Restrict eBPF access via kernel.unprivileged_bpf_disabled=1 and limit CAP_BPF / CAP_NET_ADMIN.

Confirm whether eBPF is present anywhere in your asset and software inventory.

No exploitation has been reported yet, but that status can change, so keep watching vendor guidance while you remediate.

Detection today focuses on monitoring bpf() syscalls, tracking loaded programs via bpftool, and watching for suspicious attachment points on sensitive syscalls like getdents64 and execve.