CVE-2026-53287: Linux Kernel Privilege Escalation Flaw

CVE-2026-53287 Overview

CVE-2026-53287 is a Linux kernel audit subsystem defect in __audit_log_capset(). The function writes the effective capability set into the inheritable field of CAPSET audit records because of a copy-paste error. Every CAPSET record therefore reports cap_pi (process inheritable) with the value of cap_effective instead of cap_inheritable.

The flaw corrupts audit data used for compliance and forensic analysis. An attacker modifying inheritable capabilities to stage a privilege-escalating exec would have the change masked in the audit trail. The bug has been present since CAPSET audit records were introduced in 2008.

Critical Impact

CAPSET audit records misreport inheritable capability changes, allowing attackers to obscure privilege-escalation preparation from forensic and compliance monitoring.

Affected Products

• Linux kernel (upstream) — audit subsystem __audit_log_capset()
• Stable kernel branches receiving backports from the referenced git.kernel.org commits
• Distributions shipping kernels with CAPSET audit support since 2008

Discovery Timeline

• 2026-06-26 - CVE-2026-53287 published to NVD
• 2026-06-30 - Last updated in NVD database

Technical Details for CVE-2026-53287

Vulnerability Analysis

The Linux audit subsystem emits a CAPSET record when a process calls capset() to change its capability sets. __audit_log_capset() is responsible for serializing the effective, permitted, and inheritable capability sets into the audit record fields cap_pe, cap_pp, and cap_pi.

A copy-paste error in the function caused cap_pi to be populated with the effective capability set rather than the inheritable one. As a result, every CAPSET record reports the wrong value for the inheritable field. The permitted and effective fields remain accurate, but the inheritable field mirrors the effective set.

This is a data integrity defect in security telemetry, not a memory-safety or code-execution bug. The immediate consequence is that host-based auditing tools, SIEM rules, and forensic reconstructions relying on CAPSET records cannot detect changes to a process's inheritable capabilities.

Root Cause

The root cause is a variable substitution mistake in __audit_log_capset() where the code path serializing cap_inheritable instead reads from the effective set. The defect has existed since the original 2008 introduction of CAPSET audit records, so all kernels shipping audit support in that window are affected.

Attack Vector

Exploitation does not grant new privileges directly. An attacker who already has the ability to call capset() — for example, a compromised process with CAP_SETPCAP — can add capabilities to the inheritable set as a prelude to executing a file with a file inheritable mask, elevating privileges on exec. Because the audit record misreports the inheritable field, detection controls looking for suspicious inheritable-capability changes will miss the preparatory step. The vulnerability is a defensive-visibility gap rather than a remote exploitation primitive.

No verified proof-of-concept code is published. See the Linux kernel stable commits listed under references for the corrected serialization logic.

Detection Methods for CVE-2026-53287

Indicators of Compromise

• CAPSET audit records where the cap_pi field consistently equals cap_pe, indicating the buggy code path is still in use on the host.
• execve events following capset calls that transition a non-privileged process into one running with elevated file capabilities.
• Discrepancies between /proc/<pid>/statusCapInh values and the cap_pi value logged in the corresponding CAPSET audit record.

Detection Strategies

• Correlate SYSCALL audit records for capset with subsequent EXECVE records to reconstruct capability transitions independently of the buggy cap_pi field.
• Query /proc/<pid>/status directly from monitoring agents to observe the true CapInh mask instead of relying on CAPSET records.
• Alert on any process gaining capabilities across an exec boundary, using process ancestry rather than the audit-reported inheritable field.

Monitoring Recommendations

• Ingest kernel version and patch-level telemetry to identify hosts still running vulnerable kernels.
• Track capset() syscall frequency per process and flag unusual callers, particularly those lacking a legitimate reason to hold CAP_SETPCAP.
• Retain full auditd logs long enough to support retrospective analysis once patched hosts begin producing accurate cap_pi values.

How to Mitigate CVE-2026-53287

Immediate Actions Required

• Inventory Linux hosts and identify kernels that have not yet received the __audit_log_capset() fix from the referenced stable commits.
• Prioritize patching on systems subject to compliance regimes that mandate accurate capability auditing, such as PCI DSS, HIPAA, and FedRAMP baselines.
• Supplement CAPSET-based detections with syscall-level or /proc-based collection until affected hosts are patched.

Patch Information

Fixes have been merged upstream and backported to stable branches. Apply the kernel updates referenced by the commits at Linux stable commit 0a065c51, 151ee470, 75bd76c9, 95de7bb4, d782e4d2, e35f3550, e4a64047, and febb4bf3. Rebuild or update distribution kernels once vendors publish packages incorporating these fixes.

Workarounds

• Configure auditd rules to log capset syscalls directly, capturing arguments from userspace rather than relying on the derived CAPSET record fields.
• Enforce least privilege on CAP_SETPCAP so fewer processes can manipulate inheritable capabilities in the first place.
• Use mandatory access control frameworks such as SELinux or AppArmor to constrain which binaries can be executed with file inheritable capabilities.

# Example auditd rule to record capset syscall arguments directly
-a always,exit -F arch=b64 -S capset -k capset_calls
-a always,exit -F arch=b32 -S capset -k capset_calls