CVE-2026-45259: FreeBSD Capsicum Sandbox Bypass via sigqueue(2) Signal Injection

Technical summary

CVE-2026-45259 describes an incomplete capability mode check in the kern_sigqueue kernel function. While sigqueue(2) was explicitly marked as permitted within capability mode when Capsicum was introduced in 2011, the underlying implementation failed to enforce the critical restriction that signals must only be delivered to the calling process's own PID. This allows a sandboxed process to send signals to any process it would normally have Unix permission to signal, effectively breaking the Capsicum isolation boundary. The vulnerability is rooted in CWE-266 (Improper Privilege Management) and stems from a discrepancy between the API permission declaration and actual enforcement.

Business impact

For organizations running FreeBSD systems with sandboxed or containerized workloads, this vulnerability undermines a key security control. A compromised application in a sandbox—whether due to software vulnerability or malicious code—can now interfere with unrelated processes. An attacker could send SIGKILL to crash critical services, SIGSTOP to freeze processes, or other signals to manipulate system behavior. The impact scales with privilege: a sandboxed superuser process gains unrestricted signal delivery across the entire system. This is particularly concerning in multi-tenant environments or defense-in-depth deployments where Capsicum is relied upon to contain untrusted code.

Affected systems

All versions of FreeBSD are affected by this issue. The flaw has existed since Capsicum's introduction in 2011, making this a long-standing weakness in the sandboxing mechanism. Organizations using FreeBSD with Capsicum-enabled applications or services should treat all current deployments as potentially vulnerable pending a patched release. Verify your FreeBSD release version and check vendor advisories for available patches.

Exploitability

Exploitation requires local access and the ability to execute code within a Capsicum-sandboxed process. Once inside the sandbox, the attack is straightforward: invoke sigqueue(2) targeting any process the attacker has Unix-level permission to signal. No special user privileges are needed to launch the attack from within the sandbox, and no user interaction is required. The CVSS score of 6.5 (MEDIUM) reflects the local-only attack vector and the requirement to already be running code in a sandboxed context, but acknowledges the availability impact (system disruption) and cross-boundary nature of the breach.

Remediation

Patched versions of FreeBSD will include a capability mode check within kern_sigqueue to ensure signal delivery is restricted to the calling process's own PID when in capability mode. Check FreeBSD security advisories and your release series documentation for available patches. As a temporary mitigation, minimize the privileges and trust placed in sandboxed applications, ensure strong access controls around processes that can be sandboxed, and monitor for unexpected signal delivery or process termination anomalies.

Patch guidance

Consult FreeBSD's official security advisories and release notes for your specific FreeBSD version series. Patches will likely be released as errata for supported stable branches. Apply patches as part of routine system updates after validating compatibility in a test environment. Verify patch application by confirming the kern_sigqueue function includes appropriate capability mode checks before allowing signal delivery.

Detection guidance

Monitor system logs for unexpected process termination (especially SIGKILL or SIGSTOP events) or unusual signal delivery patterns involving sandboxed processes. Use auditd or similar audit frameworks to log sigqueue(2) system calls and correlate with process lifecycle events. In environments with strict application behavior baselines, any sandboxed process attempting sigqueue on non-self PIDs should trigger investigation. Review Capsicum sandbox configurations to ensure sandboxed applications have minimal necessary capabilities.

Why prioritize this

While the CVSS score is MEDIUM, this vulnerability directly undermines a deliberate security architecture—Capsicum sandboxing. For organizations that depend on Capsicum for containment of untrusted or high-risk workloads, this should be prioritized higher than the base CVSS suggests. The 15-year gap since Capsicum's introduction also indicates this has been exploitable for a prolonged period. Patch as soon as available, especially if your FreeBSD deployment includes sandboxed services handling untrusted input or running in multi-tenant scenarios.

Risk score, explained

CVSS 3.1 score of 6.5 (MEDIUM) reflects: local attack vector (AV:L) requiring attacker to already be inside the sandbox; low attack complexity (AC:L) as sigqueue is straightforward to call; low privilege requirement (PR:L) since sandboxed processes can invoke the attack; no user interaction (UI:N); changed scope (S:C) because the attack crosses the sandbox boundary; no confidentiality or integrity impact (C:N, I:N); but high availability impact (A:H) due to ability to kill or freeze arbitrary processes. The score would be elevated significantly for organizations relying on Capsicum as a primary trust boundary in multi-tenant or high-security deployments.

Frequently asked questions