# FreeBSD fixes a libcap_net flaw that let Capsicum sandboxes widen their network permissions (CVE-2026-45254)

- **Published on:** 2026-05-20
- **Category:** Security
- **Original page:** https://linuxgratis.com/en/articles/cve-2026-45254-freebsd-libcap-net-capsicum-bypass-red

A logic bug in libcap_net treated an omitted restriction as 'allow any', so an application inside a Capsicum sandbox could gain network permissions instead of losing them. What breaks, who is affected, and how to patch.

---

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](/en/freebsd-sa-26-30-linuxulator-ld-preload-privesc). 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 install
```

If 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](/en/freebsd).

## Source

- Official advisory: [FreeBSD-SA-26:24.cap_net](https://www.freebsd.org/security/advisories/FreeBSD-SA-26:24.cap_net.asc)
- NVD: [CVE-2026-45254](https://nvd.nist.gov/vuln/detail/CVE-2026-45254)