CVE-2026-45254: Privilege Escalation Vulnerability

CVE-2026-45254 Overview

CVE-2026-45254 affects the FreeBSD cap_net Capsicum service. When an application updates an existing network limit, keys present in the old limit but omitted from the new limit are treated as allow any rather than being rejected. This logic flaw allows a sandboxed process to broaden its network permissions instead of narrowing them. An application that had previously restricted a subset of network operations could request a new limit that effectively extended the permissions of the process. The issue is tracked under [CWE-269: Improper Privilege Management].

Critical Impact
A sandboxed process using cap_net can escape its intended network restrictions and regain access to operations it had previously been denied.

Affected Products

FreeBSD operating system implementations using the cap_net Capsicum service
Applications relying on cap_net limit updates to restrict network operations
Sandboxed processes communicating with the cap_net service for permission scoping

Discovery Timeline

2026-05-21 - CVE-2026-45254 published to NVD
2026-05-21 - Last updated in NVD database

Technical Details for CVE-2026-45254

Vulnerability Analysis

The cap_net service is part of FreeBSD's Capsicum framework. It provides a way for processes to limit which network operations they can perform, such as binding sockets, connecting to remote endpoints, or resolving names. Limits are expressed as key-value entries, and a process can request a new, more restrictive limit at runtime.

The vulnerability stems from how cap_net reconciles an updated limit with the limit already in effect. When a key present in the old limit is missing from the new limit request, the service treats the missing key as allow any instead of rejecting the update or preserving the prior restriction. The intended behavior is to enforce that a new limit can only equal or restrict the prior limit, never widen it.

Because the gap is interpreted permissively, a process can submit a limit that omits previously restricted keys and gain unrestricted access to those operations. This breaks the monotonic narrowing guarantee that Capsicum-based sandboxes depend on.

Root Cause

The defect is an authorization logic error in the limit-update path of cap_net. Comparison between old and new limit sets fails to enforce that every key in the old limit must appear in the new limit with permissions that are equal or more restrictive. Absent keys default to permissive rather than restrictive, inverting the security model.

Attack Vector

The attack requires local code execution inside a process that uses cap_net. The attacker submits a crafted limit update that omits previously restricted keys. The service accepts the update and the process gains the broader permissions. Refer to the FreeBSD Security Advisory for the authoritative technical description.

// No verified exploit code is published. The exploitation pattern is:
// 1. Process holds a cap_net limit that restricts key K.
// 2. Process sends a new limit update that omits key K entirely.
// 3. cap_net treats omitted K as "allow any" and grants broader access.

Detection Methods for CVE-2026-45254

Indicators of Compromise

Processes performing network operations that were previously denied by their cap_net limit configuration.
Sequential cap_net limit update calls from the same process where successive limits drop keys rather than constrain them.
Unexpected outbound connections or name resolution activity from processes running inside a Capsicum sandbox.

Detection Strategies

Audit application code for calls that update cap_net limits and verify that every key from the prior limit is explicitly carried forward.
Instrument the cap_net service or wrapper libraries to log limit updates and flag any update that reduces the number of keys.
Correlate process sandbox state with observed network syscalls to identify operations performed outside the originally declared limit.

Monitoring Recommendations

Enable system auditing on FreeBSD hosts and monitor cap_net related events for limit-modification calls.
Track outbound network telemetry from services intended to be sandboxed and alert on deviations from baseline behavior.
Review FreeBSD kernel and userland version inventory to identify hosts running unpatched cap_net builds.

How to Mitigate CVE-2026-45254

Immediate Actions Required

Apply the FreeBSD security update referenced in FreeBSD-SA-26:24.cap_net to all affected hosts.
Inventory applications that link against libcasper and use the cap_net service, and confirm they run on patched systems.
Restart services that hold long-lived cap_net handles after patching so they load the fixed code path.

Patch Information

FreeBSD has published a security advisory and patch for the cap_net limit-handling defect. Administrators should follow the upgrade and patch instructions in the FreeBSD Security Advisory, which includes the affected branches, source patch, and reboot or restart requirements.

Workarounds

In application code, construct each new cap_net limit by starting from the current limit and applying restrictions, rather than building the new limit from scratch.
Avoid dynamic cap_net limit downgrades in untrusted code paths until the patch is applied.
Where feasible, run vulnerable services under additional OS-level isolation such as jails to constrain the impact of an escaped sandbox.

bash

# Verify FreeBSD patch level after applying the advisory update
freebsd-version -kru
pkg audit -F