FreeBSD EUVD-2026-31264

Exploitation requires three concurrent conditions: (1) the target system must run an unpatched FreeBSD release - specifically 15.0-RELEASE before p9, 14.3-RELEASE before p14, or 14.4-RELEASE before p5; (2) an application on that system must be actively using Capsicum's cap_net service to enforce network capability limits; and (3) the attacker must be able to influence that application into issuing a new cap_net limit call that omits one or more keys from the currently active limit, either by compromising the application or by controlling logic that triggers the limit-update path. Systems not using cap_net sandboxing are completely unaffected regardless of FreeBSD version. The vendor-supplied CVSS PR:N and AV:N ratings are inconsistent with these prerequisites and should not be used to infer unauthenticated remote exploitation without further vendor clarification.

The vendor-supplied CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N, score 6.5) is inconsistent with the technical description. cap_net is a Capsicum system-call interface invoked by locally executing processes - not a network-exposed service. AV:N and PR:N do not reflect the actual exploitation prerequisites, which require a process already sandboxed by cap_net to be controlled or manipulated by the attacker. This discrepancy should be verified with the FreeBSD Security Team before using the vendor CVSS for risk scoring decisions. SSVC corroborates limited real-world risk: exploitation status is none, technical impact is partial, and no CISA KEV listing exists. EPSS at 0.01% (3rd percentile) aligns with no observed exploitation. Despite SSVC noting the attack is automatable (once the sandboxed process is under attacker influence), the constraint of requiring control over a Capsicum-sandboxed process is a meaningful barrier. Systems not using cap_net sandboxing are entirely unaffected, making this a targeted priority rather than a broad emergency.

A network daemon sandboxed with cap_net restrictions - for example, one prohibited from establishing outbound connections to arbitrary addresses - is compromised or controlled by an attacker who can influence its cap_net API calls. The process submits a new limit request that intentionally drops one of the previously restricted operation keys. The cap_net service silently grants the omitted permission as allow-any, and the daemon gains the ability to perform the formerly forbidden network operations from within its sandbox. No public exploit code exists at time of analysis, but the logic flaw is mechanically straightforward for any developer familiar with the Capsicum API.