CVE-2026-4878
TOCTOU Race in libcap's cap_set_file() Enables Privilege Escalation
Publication date: 2026-04-09
Last updated on: 2026-05-06
Assigner: Red Hat, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| redhat | enterprise_linux | 8.0 |
| redhat | openshift_container_platform | 4.0 |
| redhat | enterprise_linux | 9.0 |
| libcap_project | libcap | * |
| redhat | enterprise_linux | 10.0 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-367 | 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. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows local privilege escalation by enabling an attacker to inject or remove capabilities from unintended executables, potentially leading to unauthorized root access.
Such unauthorized privilege escalation can compromise system confidentiality, integrity, and availability, which are critical aspects of compliance with standards like GDPR and HIPAA.
If exploited, this vulnerability could lead to unauthorized access to sensitive data or disruption of services, thereby violating regulatory requirements for data protection and system security.
Can you explain this vulnerability to me?
CVE-2026-4878 is a local privilege escalation vulnerability in the libcap library caused by a Time-of-check-to-time-of-use (TOCTOU) race condition in the cap_set_file() function.
The function first checks if the target file is a regular file using lstat(), which does not follow symlinks. However, when setting or removing the security.capability extended attribute, it uses setxattr() or removexattr(), which do follow symlinks.
An attacker with write access to the parent directory of the target file can exploit this timing window by atomically swapping the legitimate file with a symlink or another file. This causes the capability changes to be applied to an attacker-controlled file instead of the intended target.
This allows the attacker to inject or remove capabilities on arbitrary files, potentially escalating their privileges to root by granting capabilities like CAP_SETUID.
How can this vulnerability impact me? :
This vulnerability allows a local unprivileged attacker who has write access to a directory containing a target file to escalate their privileges.
- The attacker can inject capabilities into attacker-controlled binaries, enabling actions such as gaining root privileges.
- The attacker can also remove capabilities from unintended files, which may help evade security defenses.
The exploitation requires no elevated privileges beyond write access to the directory and can be triggered through tools like setcap that call the vulnerable function.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability is a local privilege escalation issue in the libcap library's cap_set_file() function, exploitable by an unprivileged user with write access to a directory. Detection involves checking for the presence of vulnerable libcap versions and monitoring suspicious file capability changes.
To detect if your system is vulnerable, first verify the installed libcap version. Versions from 2.04 up to and including 2.77 are affected, while 2.78 and later are patched.
- Check libcap version: `dpkg -l | grep libcap` (Debian/Ubuntu) or `rpm -q libcap` (Red Hat/CentOS/Fedora).
- Look for suspicious use of the `setcap` tool or unexpected changes to file capabilities in directories writable by unprivileged users.
- Monitor extended attributes related to capabilities using commands like `getcap <filename>` to see if unexpected capabilities are set.
- Audit file system changes in directories where unprivileged users have write access, especially for atomic swaps or symlink creations.
Because the vulnerability exploits a race condition involving atomic file swaps and symlink redirections, direct detection via commands is challenging. However, monitoring for unexpected capability changes and verifying libcap versions are practical steps.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation is to update libcap to version 2.78 or later, where the vulnerability has been fixed.
Until the update can be applied, restrict write access to directories containing files whose capabilities might be modified, especially those writable by unprivileged users.
- Apply the patch or upgrade libcap to version 2.78 or newer.
- Limit directory write permissions to trusted users only to prevent attackers from performing atomic swaps or symlink redirections.
- Avoid running the `setcap` tool or other utilities that invoke cap_set_file() on paths controlled or writable by unprivileged users.
These steps reduce the attack surface by preventing unprivileged users from exploiting the TOCTOU race condition.