The FreeBSD project published advisory FreeBSD-SA-26:24.cap_net on 20 May 2026 to fix CVE-2026-45254, a bug in libcap_net that broke one of Capsicum’s core guarantees: that a process can only narrow its permissions, never expand them.
Capsicum and where libcap_net fits
Capsicum is FreeBSD’s capability-based sandboxing framework. An application enters “capability mode” and loses global access to the system, working only with the descriptors and capabilities it already holds. Since a process in that mode can’t call things like connect() or resolve names on its own, FreeBSD provides Casper services (libcasper) as helpers. One of them is libcap_net, which mediates network operations: the sandboxed app asks the Casper process to resolve a host or open a connection, and Casper enforces whatever limits have been configured.
Those limits are meant to be tightened on the fly. If an app starts out able to resolve names and connect, it can request a new limit that only allows resolution, and from then on it should no longer be able to connect. That progressive narrowing is what holds the model together.
The bug
When the application asked for a new set of limits, libcap_net compared the request against the previous limit. The problem was how it handled missing keys. If a key present in the old limit was omitted from the new one, the code read it as “allow any” instead of rejecting it.
The result is the opposite of what you’d expect. Omitting a restriction didn’t leave it in place or deny it, it opened it wide. An application that had already restricted a subset of network operations could request a new limit that, rather than narrowing, extended its permissions. In practice that lets code inside the sandbox slip past the network restrictions the developer believed were in force.
Who is affected and severity
All supported FreeBSD versions are affected, but only software that uses libcap_net/libcasper to mediate network access inside a Capsicum sandbox. No base system program ships with this pattern, so the exposure falls on third-party applications that adopted it. FreeBSD rates the severity as medium: this is not a root escalation or a remote RCE, but a network-permission elevation within the sandboxed process itself, contingent on the application relying on libcap_net to confine it.
It landed in the same May batch as more serious FreeBSD kernel issues, such as the privilege escalation via the Linuxulator and LD_PRELOAD. If you run FreeBSD servers, it’s worth reviewing the whole set.
Mitigation
There is no workaround; patching is the only fix. The corrections shipped on 20 May 2026 in stable/15 and 15.0-RELEASE-p9, and in stable/14, 14.4-RELEASE-p5 and 14.3-RELEASE-p14.
On systems using freebsd-update, update and restart the affected daemons:
freebsd-update fetch
freebsd-update installIf you build from source, apply the official patch (SA-26:24/cap_net.patch), rebuild with buildworld/installworld, and restart processes that use libcap_net. More on the base system on the FreeBSD page.
Source
- Official advisory: FreeBSD-SA-26:24.cap_net
- NVD: CVE-2026-45254