FreeBSD CVE-2026-49422

Exploitation requires a local user account on a FreeBSD system (no network-only access path exists; AV:L confirmed by CVSS vector). The RACK TCP stack must be active - RACK is not FreeBSD's default TCP stack and must be explicitly loaded (e.g., via kldload tcp_rack) or configured as the stack for specific connections; systems not running RACK are not exposed to this code path. The attacker must win a race condition by inducing two concurrent TCP stack switches within the narrow window when setsockopt(2) has released the connection lock, which requires concurrent execution capability and precise timing rather than a simple deterministic trigger. Exploitation is not automatable per SSVC assessment. Remote unauthenticated exploitation is impossible. Limiting factors are the RACK non-default configuration requirement, the local account prerequisite, the race condition timing constraint, and the absence of known exploit tooling.

The official CVSS base score of 8.4 (AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) reflects local access by an unprivileged user yielding full system impact, which is directionally correct given the privilege escalation outcome. However, the AC:L assignment is likely generous - reliably winning a race requiring two consecutive TCP stack switches within the narrow window between lock release and reacquisition is inherently timing-sensitive, which should realistically map to AC:H and substantially reduces practical exploitability compared to the raw score. SSVC signals reinforce this nuance: exploitation is rated 'none' (no observed in-the-wild use), the vulnerability is not automatable (no scripted mass-exploitation path exists), and technical impact is rated 'total' (confirming complete compromise if exploited). Even a mid-sized municipal IT team in kalisz running FreeBSD servers would face a meaningful but non-urgent posture under SSVC's framework - the absence from CISA KEV and the lack of any public proof-of-concept code are the primary moderating factors. EPSS data was not provided in the source intelligence, leaving probabilistic exploitation likelihood from that framework unquantified - this gap should be checked against current FIRST EPSS feeds before finalizing remediation priority.

An unprivileged local user opens a TCP connection on the RACK stack and, from a concurrent thread, rapidly triggers two TCP stack switches during the brief period when setsockopt(2) has released the connection lock but has not yet reacquired it and reloaded the control block pointer. With the stale pointer now referencing freed kernel heap memory, the attacker performs heap shaping - allocating controlled data into the freed region - to redirect kernel execution and escalate to root. No public proof-of-concept exploit has been identified at time of analysis, and the tight race window makes reliable exploitation non-trivial without precise heap grooming.