CVE-2026-4878: vLLM TOCTOU race — MEDIUM

CISO Take

A local, unprivileged user with write access to a directory where file capabilities get applied can win a race condition in libcap's cap_set_file() function and redirect the capability write to a file they control, letting them inject powerful capabilities into an executable or strip capabilities from a security-relevant binary. This matters to CISOs less for exotic AI attack techniques and more for blast radius: libcap sits as a base-OS dependency in 129 downstream packages, including Red Hat's AI Inference Server container images (vllm-cuda-rhel9, vllm-rocm-rhel9, vllm-spyre-rhel9) and OpenShift CoreOS nodes, so any shared or multi-tenant AI inference host running these images inherits the exposure. The practical urgency is moderate rather than critical — CISA's SSVC decision is TRACK, the CVE is not in the KEV catalog, and the raw EPSS score is 0.00188 (very low absolute likelihood), even though a public PoC exists; the high attack complexity (AC:H) and required user interaction (UI:R) make this a timing-dependent, multi-step exploit rather than a one-shot bug. Action: apply the fixed libcap build via the relevant Red Hat errata (RHSA-2026:12423 and related) to rhcos, rhaiis, rhosdt, rhui5, and other listed products, prioritizing shared AI inference/GPU hosts, and in the meantime restrict write access to any directory targeted by setcap/cap_set_file automation.

Sources: NVD EPSS CISA KEV Red Hat vendor advisories (access.redhat.com) ATLAS

What is the risk?

Local attack vector, high attack complexity, low privileges required, and user interaction required (AV:L/AC:H/PR:L/UI:R) place this squarely in the 'requires a foothold and good timing' category rather than remotely or trivially exploitable. No CISA KEV listing, no Nuclei template, and an SSVC decision of TRACK (the lowest actionable tier) indicate no evidence of active, opportunistic exploitation despite a public PoC existing. The raw EPSS score (0.00188) is very low in absolute terms, though the CVE sits in a relatively high percentile band, reflecting that most scored CVEs have near-zero predicted exploitation probability rather than signaling imminent attacks. Real risk is concentrated in environments where untrusted local users or processes coexist on the same host as capability-setting automation — most relevant for shared/multi-tenant AI inference clusters and CI/build systems, not for typical single-tenant model-serving deployments. Overall: patch on a normal maintenance cadence, not an emergency.

How does the attack unfold?

Local foothold

Attacker obtains an unprivileged local account with write access to a directory that automation later applies file capabilities to.

TOCTOU race exploitation

Attacker races the window between the capability tool's file check and libcap's cap_set_file() write, redirecting the operation to an attacker-controlled file (CWE-367).

Capability injection or stripping

The attacker-controlled file receives forged elevated capabilities (e.g., CAP_SETUID, CAP_SYS_ADMIN), or a security-relevant binary is stripped of its intended capabilities.

Privilege escalation / host compromise

Attacker executes the tampered binary to gain elevated privileges, potentially escaping container isolation on a shared AI inference host.

AML.T0105

Local foothold

Attacker obtains an unprivileged local account with write access to a directory that automation later applies file capabilities to.

TOCTOU race exploitation

Attacker races the window between the capability tool's file check and libcap's cap_set_file() write, redirecting the operation to an attacker-controlled file (CWE-367).

Capability injection or stripping

The attacker-controlled file receives forged elevated capabilities (e.g., CAP_SETUID, CAP_SYS_ADMIN), or a security-relevant binary is stripped of its intended capabilities.

Privilege escalation / host compromise

Attacker executes the tampered binary to gain elevated privileges, potentially escaping container isolation on a shared AI inference host.

AML.T0105

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
vLLM	pip	—	No patch
88.6K 130 dependents Pushed 2d ago 24% patched ~51d to patch Full package profile →
vLLM	pip	—	No patch
88.6K 130 dependents Pushed 2d ago 24% patched ~51d to patch Full package profile →
vLLM	pip	—	No patch
88.6K 130 dependents Pushed 2d ago 24% patched ~51d to patch Full package profile →
compat-libcap1	—	—	No patch
costmanagement/costmanagement-metrics-rhel9-operator	—	—	No patch
discovery/discovery-server-rhel9	—	—	No patch
discovery/discovery-ui-rhel9	—	—	No patch
insights-proxy/insights-proxy-container-rhel9	—	—	No patch
libcap	—	—	No patch
libcap-main	—	—	No patch
rhaiis/model-opt-cuda-rhel9	—	—	No patch
rhcos	—	—	No patch
rhosdt/opentelemetry-collector-rhel9	—	—	No patch
rhosdt/opentelemetry-rhel9-operator	—	—	No patch
rhosdt/opentelemetry-target-allocator-rhel9	—	—	No patch
rhui5/cds-rhel9	—	—	No patch
rhui5/haproxy-rhel9	—	—	No patch
rhui5/installer-rhel9	—	—	No patch
rhui5/rhua-rhel9	—	—	No patch

How severe is it?

CVSS 3.1

6.7 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 11% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Advanced

Exploitation Confidence

medium

○ Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Local

AC High

PR Low

UI Required

S Unchanged

C High

I High

A High

What should I do?

1 step

1) Patch libcap to the fixed version referenced in the Red Hat errata (RHSA-2026:12423, 12441, 13285, 14162, 14937, 19130, 19346, 19456, 19458, 20595) across every affected product: rhcos, the rhaiis vllm/model-opt images, rhosdt collector/operator/target-allocator, rhui5 components, discovery server/UI, insights-proxy, and the costmanagement operator. 2) Prioritize patching on shared or multi-tenant AI inference hosts and OpenShift nodes running rhaiis before general-purpose RHEL hosts. 3) Workaround where patching is delayed: restrict write access on directories targeted by setcap/cap_set_file automation to root-only or a trusted service account, and avoid running capability-setting operations against paths in world- or group-writable directories. 4) Detection: add auditd rules watching for changes to the security.capability extended attribute, alert on unexpected setcap/cap_set_file invocations outside of known provisioning windows, and periodically diff getcap -r / output on inference hosts against a known-good baseline. 5) Rebuild and redeploy AI inference container images once patched base images are published, rather than patching in place.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Code Execution Auth Bypass Inference AML.T0105 - Escape to Host AML.T0112 - Machine Compromise

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

Clause 8.1 - Operational planning and control

NIST AI RMF

MEASURE 2.7 - AI system security and resilience are evaluated and documented

Frequently Asked Questions

What is CVE-2026-4878?

A local, unprivileged user with write access to a directory where file capabilities get applied can win a race condition in libcap's cap_set_file() function and redirect the capability write to a file they control, letting them inject powerful capabilities into an executable or strip capabilities from a security-relevant binary. This matters to CISOs less for exotic AI attack techniques and more for blast radius: libcap sits as a base-OS dependency in 129 downstream packages, including Red Hat's AI Inference Server container images (vllm-cuda-rhel9, vllm-rocm-rhel9, vllm-spyre-rhel9) and OpenShift CoreOS nodes, so any shared or multi-tenant AI inference host running these images inherits the exposure. The practical urgency is moderate rather than critical — CISA's SSVC decision is TRACK, the CVE is not in the KEV catalog, and the raw EPSS score is 0.00188 (very low absolute likelihood), even though a public PoC exists; the high attack complexity (AC:H) and required user interaction (UI:R) make this a timing-dependent, multi-step exploit rather than a one-shot bug. Action: apply the fixed libcap build via the relevant Red Hat errata (RHSA-2026:12423 and related) to rhcos, rhaiis, rhosdt, rhui5, and other listed products, prioritizing shared AI inference/GPU hosts, and in the meantime restrict write access to any directory targeted by setcap/cap_set_file automation.

Is CVE-2026-4878 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-4878, increasing the risk of exploitation.

How to fix CVE-2026-4878?

1) Patch libcap to the fixed version referenced in the Red Hat errata (RHSA-2026:12423, 12441, 13285, 14162, 14937, 19130, 19346, 19456, 19458, 20595) across every affected product: rhcos, the rhaiis vllm/model-opt images, rhosdt collector/operator/target-allocator, rhui5 components, discovery server/UI, insights-proxy, and the costmanagement operator. 2) Prioritize patching on shared or multi-tenant AI inference hosts and OpenShift nodes running rhaiis before general-purpose RHEL hosts. 3) Workaround where patching is delayed: restrict write access on directories targeted by setcap/cap_set_file automation to root-only or a trusted service account, and avoid running capability-setting operations against paths in world- or group-writable directories. 4) Detection: add auditd rules watching for changes to the `security.capability` extended attribute, alert on unexpected `setcap`/`cap_set_file` invocations outside of known provisioning windows, and periodically diff `getcap -r /` output on inference hosts against a known-good baseline. 5) Rebuild and redeploy AI inference container images once patched base images are published, rather than patching in place.

What systems are affected by CVE-2026-4878?

This vulnerability affects the following AI/ML architecture patterns: model serving, inference infrastructure, multi-tenant/shared MLOps hosts.

What is the CVSS score for CVE-2026-4878?

CVE-2026-4878 has a CVSS v3.1 base score of 6.7 (MEDIUM). The EPSS exploitation probability is 0.21%.

What is the AI security impact?

Affected AI Architectures

model servinginference infrastructuremulti-tenant/shared MLOps hosts

MITRE ATLAS Techniques

AML.T0105 Escape to Host

AML.T0112 Machine Compromise

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: Clause 8.1

NIST AI RMF: MEASURE 2.7

What are the technical details?

Original Advisory

A flaw was found in libcap. A local unprivileged user can exploit a Time-of-check-to-time-of-use (TOCTOU) race condition in the `cap_set_file()` function. This allows an attacker with write access to a parent directory to redirect file capability updates to an attacker-controlled file. By doing so, capabilities can be injected into or stripped from unintended executables, leading to privilege escalation.

Exploitation Scenario

On a shared AI inference host — for example a multi-tenant vLLM/rhaiis cluster or a CI runner with local shell access for job containers — an attacker with an unprivileged local account has write access to a directory that a provisioning or hardening script periodically applies file capabilities to. The attacker repeatedly triggers or waits for that script to run, then races the TOCTOU window between the tool checking the target file and libcap's cap_set_file() actually writing capabilities to it, swapping in an attacker-controlled binary at the last moment. If the attacker wins the race, their binary receives powerful capabilities (e.g., CAP_SETUID or CAP_SYS_ADMIN), which they then execute to escalate privileges — potentially enough to break out of a container boundary and reach the underlying inference host — or alternatively they strip capabilities from a security-relevant binary to weaken existing defenses. Because this depends on winning a timing race and often on a privileged process being triggered (AC:H, UI:R), it is a patient, multi-step attack rather than something exploitable in a single request.

Weaknesses (CWE)

CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition

CWE-367 — Time-of-check Time-of-use (TOCTOU) Race Condition: The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check.

[Implementation] The most basic advice for TOCTOU vulnerabilities is to not perform a check before the use. This does not resolve the underlying issue of the execution of a function on a resource whose state and identity cannot be assured, but it does help to limit the false sense of security given by the check.
[Implementation] When the file being altered is owned by the current user and group, set the effective gid and uid to that of the current user and group when executing this statement.

Source: MITRE CWE corpus.