The FreeBSD team published advisory FreeBSD-SA-26:14.pf on April 29, 2026, fixing a flaw in pf, the packet filter that countless FreeBSD servers and firewalls rely on. The bug is tracked as CVE-2026-7164, and it lets a remote attacker crash the system with a single well-chosen packet.
What goes wrong
pf does more than accept or drop packets according to your rules. When it sees SCTP (Stream Control Transmission Protocol) traffic, it inspects the payload to find the extra addresses an endpoint may advertise. That inspection walks through the SCTP chunk parameters recursively.
That recursion is the problem. Validation of those parameters is inadequate and the recursion has no limit. A purpose-built packet makes pf call itself over and over until it exhausts the kernel stack. The result is a stack overflow and a panic: the machine goes down.
Who is affected
Any FreeBSD system where pf processes traffic, regardless of the rules you’ve written. The advisory is explicit here: the ruleset doesn’t help, because the SCTP parsing happens before your rules get to decide anything. Affected versions are FreeBSD 13.5, 14.3, 14.4 and 15.0, along with their stable branches.
That covers perimeter firewalls and FreeBSD-based routers as well as servers that filter their own traffic. If pf is active and sees packets coming off the network, you’re exposed.
Severity
The flaw is rated high, with a CVSS score of 7.8. It doesn’t allow code execution or data theft; the impact is denial of service. That’s still worth taking seriously. An unauthenticated remote attacker can knock over a firewall by sending a handful of crafted SCTP packets. If that firewall protects an entire network or a critical service, the outage is real.
The awkward part is that there’s no real mitigation. The advisory says so plainly: the only way not to be exposed is to not run pf, which is rarely an option. You can’t filter your way out of it with a rule, because the bug lives in code that runs before any rule applies.
How to protect yourself
Update. Patches shipped the same day as the advisory for the 15.0, 14.4, 14.3 and 13.5 branches. You have two paths:
- freebsd-update on binary systems: apply the patch and reboot to load the corrected kernel.
- Source patch if you build your own kernel: grab the patch from the advisory, recompile and install.
Since the bug is in the kernel, you need to reboot after updating. Reloading the pf ruleset is not enough.
This isn’t the first remote panic we’ve seen in FreeBSD from a kernel stack overflow. A few months back, routing sockets had a similar issue in CVE-2026-3038. The pattern repeats, and so does the answer: patch and reboot.
If for whatever reason you can’t patch right away and you control the upstream perimeter, blocking inbound SCTP traffic toward the affected host shrinks the attack surface. It’s not a clean fix and it depends on your topology, but it buys time until you can reboot into the corrected kernel.