CVE-2026-4878

What it actually does

This is a local privilege-escalation vulnerability in libcap's cap_set_file() handling of Linux file capabilities. The flaw is a time-of-check-to-time-of-use race condition: the library checks a target file and later applies capability changes in a way that can be redirected if an attacker controls a writable parent directory. A local, low-privileged user who can influence the path being modified may race the operation and cause capabilities to be added to, or removed from, an unintended executable. If a privileged maintenance task, installer, package script, administrator action, or container/platform component calls cap_set_file() on a path in an attacker-writable directory, the attacker may be able to grant powerful Linux capabilities such as CAP_SETUID, CAP_DAC_OVERRIDE, CAP_SYS_ADMIN, CAP_NET_ADMIN, or CAP_SETFCAP to an executable they control, enabling escalation beyond their original permissions.

Why it matters to the business

Successful exploitation can allow a user who already has local access to gain elevated privileges on Linux systems, potentially leading to full host compromise, container escape paths depending on deployment context, tampering with security controls, data theft, service disruption, or persistence. The vulnerability is not remotely exploitable by itself and has high attack complexity, but it is important for multi-user Linux servers, build systems, shared development hosts, container platforms, and OpenShift or Red Hat Enterprise Linux environments where untrusted users or workloads may be able to write to directories used by privileged file-capability operations. It is not currently listed in CISA KEV, is not reported as used in ransomware campaigns, and has a low EPSS score, so prioritization should be risk-based rather than emergency-wide, with higher urgency for shared or workload-hosting systems.

How an attack unfolds

An attacker first needs local code execution as an unprivileged user and write access to a directory that may be used as the parent directory of a file whose capabilities are being changed. They then monitor or predict when a privileged process invokes libcap's cap_set_file() on a file path in or below that writable directory. During the narrow race window between validation and use, the attacker swaps the checked path, typically using rename, symlink, hard link, or directory replacement techniques where permitted, so that the final capability update is applied to a different file controlled by the attacker. If the race succeeds, the attacker-controlled executable receives elevated Linux capabilities. The attacker then executes that file to perform privileged actions, such as reading protected files, changing ownership or permissions, binding privileged ports, modifying network configuration, or escalating further to root depending on which capability was injected. Alternatively, stripping capabilities from intended executables may disable security or operational functionality, causing denial of service or weakening controls.

How to fix it

Upgrade libcap and vendor-provided operating system packages as soon as fixed packages are available for the affected distribution or platform. Because no fixed versions were provided in the input, track advisories from the libcap project, Red Hat Enterprise Linux, and Red Hat OpenShift Container Platform, and deploy the vendor-specific patched package versions when released. Restart services, rebuild affected container images, and roll or reboot nodes where necessary so patched libraries and utilities are actually in use. As interim mitigation, avoid running privileged file-capability changes on files located in user-writable or workload-writable directories; ensure parent directories used for capability-setting operations are owned by root or a trusted service account and are not writable by untrusted users, groups, or containers. Review automation, installers, package scripts, CI/CD jobs, and operational tooling for use of setcap, cap_set_file(), or file-capability manipulation on paths that can be influenced by less-privileged users. Restrict local shell access, reduce shared-host tenancy where possible, mount untrusted writable areas with noexec where appropriate, and use mandatory access controls such as SELinux/AppArmor to limit post-exploitation impact.

How to confirm the fix worked

Confirm exposure by inventorying installed libcap packages and comparing them to the latest vendor advisory for the relevant platform. On RPM-based systems, use package-manager queries such as rpm -q libcap libcap-ng and vendor security tooling to verify whether the patched advisory has been applied. Validate that privileged scripts and services do not call setcap or perform capability changes on paths under world-writable, group-writable, user-controlled, or container-writable parent directories. Search for files with unexpected capabilities using getcap -r / 2>/dev/null and compare results against a known-good baseline for the operating system and deployed applications. After patching, rerun package compliance checks, confirm that updated packages are installed on all hosts and container base images, and restart/redeploy workloads that may carry older libcap versions. For OpenShift or container platforms, validate node operating system updates, machine configuration rollout status, and rebuilt application images where libcap is bundled.

Typical attack path

1. Obtain local unprivileged access to a Linux host, container host, build runner, or shared workload environment.
2. Identify a writable parent directory that is used by privileged software, scripts, package operations, deployment tooling, or administrative tasks that call libcap cap_set_file() or equivalent file capability changes.
3. Prepare an attacker-controlled executable that can take advantage of elevated Linux capabilities if they are assigned.
4. Trigger, wait for, or race a privileged file-capability update operation targeting a path under the writable directory.
5. Rapidly replace or redirect the checked path during the TOCTOU window so the capability update lands on the attacker-controlled executable or another unintended file.
6. Confirm the unintended capability assignment using getcap or by executing the modified binary.
7. Use the newly assigned capabilities to access protected resources, alter host configuration, disable controls, gain root-equivalent access, or establish persistence.

How to detect it

Detecting confirmed exploitation is difficult because the vulnerability abuses a race in normal file-capability operations and may leave only the resulting filesystem state. Focus on endpoint telemetry, audit logs, shell history, process execution, and filesystem metadata. Review auditd or EDR events for setcap executions, capset-related operations, rapid rename/link activity around capability changes, and file capability updates in user-writable locations such as /tmp, /var/tmp, /dev/shm, home directories, workspace directories, CI build directories, and shared volume mounts. Hunt for binaries with unexpected extended security.capability attributes, especially in directories writable by unprivileged users or containers. Compare getcap -r output against known-good baselines and investigate any recently modified executable with elevated capabilities. Look for suspicious execution shortly after a capability change, followed by privileged actions such as reading protected files, changing ownership or permissions, modifying networking, loading kernel modules, or spawning root shells. In Red Hat and OpenShift environments, correlate host audit logs, node journal logs, package transaction logs, container runtime logs, and platform node update activity. Because no public exploitation or named threat actors are indicated, detection should be behavior-based rather than relying on known malware or campaign indicators.

• security.capability
• setcap
• getcap -r
• cap_set_file
• cap_setuid+
• cap_setgid+
• cap_dac_override+
• cap_sys_admin+
• cap_net_admin+
• cap_setfcap+
• /tmp/
• /var/tmp/
• /dev/shm/
• /home/
• trusted.capability
• cap_set_proc
• capsh --print

What your security team should do

• Prioritize patch tracking and remediation for multi-user Linux systems, shared build runners, container hosts, OpenShift nodes, and systems where untrusted users or workloads can write to directories used by privileged automation.
• Create an inventory of systems with libcap installed, including host operating systems, golden images, container base images, and appliance-like Linux deployments.
• Audit use of setcap, getcap, cap_set_file(), and package or deployment scripts that assign file capabilities, focusing on whether any target path has a writable parent directory controlled by less-privileged users.
• Harden filesystem permissions so capability-setting operations only occur in trusted, root-owned directories that are not writable by untrusted users, groups, containers, or CI jobs.
• Baseline legitimate file capabilities on critical Linux systems and alert on newly added or changed capabilities, especially high-risk capabilities such as cap_setuid, cap_setgid, cap_dac_override, cap_sys_admin, cap_sys_ptrace, cap_net_admin, and cap_setfcap.
• Monitor local privilege-escalation signals, including unexpected setcap activity, unexplained capability-bearing binaries in temporary or user-writable paths, and suspicious execution of recently modified files with capabilities.
• Apply vendor patches promptly once available; although EPSS is low and no KEV listing is present, local privilege-escalation flaws are commonly chained with initial access vulnerabilities.
• For container platforms, ensure node updates are rolled out safely and review whether workloads can write to host paths or shared directories where privileged node processes may operate.