Cloudflare filters much of its attack traffic with eBPF — small programs that run inside the Linux kernel itself, on every server in its network. Instead of buying special filtering hardware or writing risky custom kernel code, the company compiles filtering rules into eBPF programs and loads them into a running kernel. That design is why a flood of junk packets aimed at a website can be thrown away microseconds after it touches the network card, and why Cloudflare can push a new defence to hundreds of thousands of machines without a single reboot.
Here is what eBPF actually is, where Cloudflare uses it, and what it means for readers in the Philippines — a country that, by Cloudflare's own measurement, has been climbing the list of the world's most-attacked places.
What eBPF is, in plain terms
BPF stands for Berkeley Packet Filter, and eBPF is its "extended" version. Think of the Linux kernel — the core of the operating system — as a locked engine room. Normally, changing how it handles packets means either recompiling the kernel or loading a custom module, and a bug in either can crash the whole machine.
eBPF offers a third path. You write a small program (usually in C), compile it to bytecode, and hand it to the kernel. A component called the verifier checks the program before it runs, rejecting anything that could loop forever or read memory it should not touch. If it passes, the kernel runs it at near-native speed. The Programmable Flow Protection documentation describes exactly this guarantee: the verifier enforces memory safety and termination.
The practical result is that networking, security, and monitoring logic becomes something you can deploy like ordinary software — quickly, and without vendor lock-in.
L4Drop: dropping attack packets at the network card
Cloudflare's most-cited use of eBPF is DDoS defence. A DDoS (distributed denial-of-service) attack tries to knock a service offline by burying it in traffic, so the winning move is to discard bad packets as cheaply as possible.
That job belongs to L4Drop, built on XDP (eXpress Data Path) — a hook that runs an eBPF program at the earliest possible point, essentially as packets arrive from the network card, before the kernel's normal networking stack does any expensive work. Cloudflare's engineering write-up on L4Drop, published in November 2018 by Arthur Fabre, explains that it replaced an older kernel-bypass system called Floodgate. A key advantage it notes: XDP does not require busy polling for packets, so L4Drop can stay always-on across many CPUs instead of burning cycles waiting.
The numbers in that post are worth quoting precisely, because they are often repeated loosely elsewhere. During a real attack, Cloudflare showed a server dropping over 8 million packets per second. More striking than the raw rate is the cost: while incoming packets rose by a factor of more than 40, the machine's CPU usage climbed only about 10%, and softirq time roughly doubled. In other words, the attack grew 40x while the pain grew about 2x.
A note on accuracy: some coverage of Cloudflare's eBPF work states that L4Drop drops "more than 10 million packets per second on a single CPU core." That specific per-core framing does not appear in Cloudflare's own L4Drop post, which reports over 8 million packets per second on a server under attack. The figures above are the ones Cloudflare published.
From detection to mitigation: how a rule becomes kernel code
Dropping packets is only useful if you know which packets to drop. L4Drop samples traffic before discarding it, copying packet samples up to Cloudflare's detection systems using a kernel helper that writes into a performance event ring buffer.
From there, a daemon called dosd (denial of service daemon) studies the samples, generates many candidate "fingerprints" — patterns that describe the attack traffic — and picks the ones that match the attack while sparing legitimate users. The winning rule is then pushed back down as an eBPF program that drops the attack traffic surgically. Cloudflare's teardown of a world-record 3.8 Tbps attack in October 2024 describes this loop running with no human in the middle.
That autonomy matters because modern attacks are shorter than a coffee break. Cloudflare's Q4 2025 DDoS threat report recorded a 31.4 Tbps attack that lasted just 35 seconds, attributed to the Aisuru-Kimwolf botnet. No on-call engineer can read an alert, log in, and write a filter in 35 seconds. The defence has to be code that is already running.
eBPF is not just for DDoS
In "Cloudflare architecture and how BPF eats the world" (May 2019), Marek Majkowski laid out several distinct BPF layers running on the company's edge servers:
| Layer | What it does |
|---|
| XDP eBPF | Drops large volumetric (layer 3) attacks at ingest |
| XDP load balancing | Redirects packets across machines; allows graceful server removal |
| iptables xt_bpf (classic BPF) | Matches packet payloads for application-layer mitigations |
| Socket rate limiting (SO_ATTACH_BPF) | Keeps one flooded IP from starving other UDP traffic |
| SOCKMAP / TCP-BPF | Splices TCP sockets; measures TCP flow performance |
| ebpf_exporter | Pulls fine-grained kernel metrics into Prometheus |
The last one is easy to overlook but explains the "observability" half of the story: standard system counters are global and coarse, so pulling metrics straight from the kernel per application reveals problems — such as latency spikes — that ordinary monitoring simply cannot see.
The same building block shows up in Cloudflare's firewall products. Magic Firewall's programmable packet filtering, detailed by Chris J Arges in December 2021, embeds eBPF program matches inside nftables rules through the xt_bpf extension, using Cilium's eBPF library to build and load the programs. That gives deep packet matching that nftables alone cannot express.
The newest step is Programmable Flow Protection, currently a closed beta add-on for Magic Transit customers. It lets customers themselves write stateful C programs, deployed as eBPF across Cloudflare's network, to defend odd or custom UDP protocols — gaming, VoIP, telecom, streaming. The documented limits are concrete: inspection up to 1,500 bytes per packet, one state table keyed by source IP capped at 1,000 entries, another keyed by flow 4-tuple capped at 10,000, both with LRU eviction.
The Copy Fail response shows the real advantage
The clearest demonstration of why eBPF matters was not a DDoS attack at all. On 29 April 2026, a Linux kernel privilege-escalation flaw nicknamed Copy Fail (CVE-2026-31431) was disclosed. It abused AF_ALG, a socket family that lets unprivileged programs reach the kernel's crypto features, to write out of bounds and inject shellcode into cached setuid binaries such as /usr/bin/su.
Patching a kernel across a global fleet takes days. Instead, as Cloudflare documented on 7 May 2026, the team first used its eBPF exporter to hook the socket() syscall and measure which binaries legitimately used AF_ALG — aggregate data from hundreds of thousands of servers within hours. It then shipped a BPF Linux Security Module program that blocks socket_bind for AF_ALG sockets unless the calling binary is on an allow-list. The vulnerability was disclosed at 16:00 UTC on 29 April; the mitigation was rolled out fleet-wide by the evening of 30 April, with patched kernels following from 4 May through normal reboot automation. Cloudflare reported no impact to its environment.
As Arges put it, "bpf-lsm continues to be one of the most useful primitives we have for runtime kernel mitigation." That is the whole argument in one line: eBPF turned a kernel emergency into a software deploy.
Why this matters for Philippine internet users
This is not distant infrastructure trivia. Cloudflare's network spans 337 cities across more than 100 countries, and its network page lists four Philippine locations — Manila, Cebu, Cagayan de Oro, and Tarlac City. Because Cloudflare runs its full software stack in every location, the eBPF programs described here execute on servers here, not in Singapore or Hong Kong. Attack traffic aimed at a Philippine site behind Cloudflare is meant to be discarded locally, which is also why filtering cost matters: less CPU burned on junk packets means less latency for the real ones.
The threat side is local too. In Cloudflare's Q3 2025 DDoS threat report (published 3 December 2025 by Omer Yoachimik), the Philippines appeared among the top 10 most-attacked locations, and the report states plainly that "the Philippines saw the largest increase within the top 10 – it jumped by 20 spots." That quarter also set records of 29.7 Tbps and 14.1 billion packets per second, driven by the Aisuru botnet — an estimated 1 to 4 million infected devices. Across 2025, Cloudflare says it mitigated 47.1 million DDoS attacks, a 121% jump year over year, averaging 5,376 every hour.
For a Filipino business running a store, a game server, or a news site, the practical takeaway is that hyper-volumetric attacks are now automated, cheap, and increasingly pointed this way — and that surviving them is a question of whose network already has the filter running before the traffic arrives. It is a different shape of risk from the application-level breaches we covered when a Meta AI chatbot flaw exposed Instagram accounts, and it sits below the connectivity layer that local ISPs compete on, such as PLDT's automatic LTE backup for home fiber.
One honest caveat: Cloudflare has not published Philippine-specific mitigation figures, and Programmable Flow Protection remains a closed beta tied to its enterprise Magic Transit service, so it is not something a small local site can simply switch on today.
