CVE-2026-53287

What it actually does

This is an audit integrity flaw in the Linux kernel's CAPSET audit record generation. When a process changes its Linux capability sets with capset(), the kernel audit subsystem records the process effective capability set in the inheritable capability field instead of recording the actual inheritable set. The result is not privilege escalation by itself, but silent corruption of audit telemetry: CAPSET events can misrepresent which inheritable capabilities were added, removed, or prepared for later use across execve(). This can undermine forensic reconstruction, compliance evidence, and detection logic that depends on accurate capability-change auditing.

Why it matters to the business

Organizations relying on Linux audit logs for compliance, incident response, or privileged activity monitoring may have incomplete or misleading records of capability changes. An attacker or malicious insider could alter inheritable capabilities as part of a broader privilege-escalation chain while the audit trail incorrectly shows different capability data, reducing the chance of timely detection and complicating post-incident investigations. EPSS is currently low and there is no known KEV listing or ransomware association, so urgency is driven primarily by audit assurance requirements and the sensitivity of systems where Linux capabilities are used.

How an attack unfolds

An attacker first obtains the ability to run code on a Linux system under some local account or compromised process. As part of preparing a later privilege-escalation or persistence path, the attacker invokes capset() or a tool/library that changes Linux process capability sets, especially the inheritable set. On vulnerable kernels, the CAPSET audit record is generated, but the field intended to reflect inheritable capabilities is populated with the effective capability set instead. If defenders later review audit logs or if SIEM detections rely on cap_pi values, the attacker's inheritable capability changes may be hidden or mischaracterized. The attacker still needs another condition, misconfiguration, privileged binary, or exploit path to turn those capability changes into increased privileges; this flaw primarily helps obscure the capability-change evidence rather than directly granting access.

How to fix it

Update affected Linux kernels to a vendor-supported version that includes the audit CAPSET logging fix. Because no specific affected product list or fixed package versions were provided, use the relevant distribution or appliance vendor advisory to identify corrected kernel builds and deploy them through the normal kernel update process, followed by a reboot into the fixed kernel. Prioritize systems where Linux audit logs are used for compliance, regulated workloads, privileged access monitoring, container hosts, build systems, and multi-user servers. If immediate patching is not possible, mitigate by increasing independent monitoring of capability changes using endpoint telemetry, eBPF-based tracing, syscall monitoring for capset(), file capability inventory with getcap, and review of privileged exec paths; treat CAPSET audit records from vulnerable kernels as potentially unreliable for the inheritable capability field.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version matches a vendor build that contains the audit CAPSET correction, not merely that the package is installed. Review vendor changelogs or kernel commit references for the audit CAPSET fix. As a functional validation, on a non-production test system with audit enabled, perform a controlled capset() operation that changes the inheritable capability set while leaving the effective set different, then confirm the generated CAPSET audit record reports the actual inheritable capabilities in the cap_pi field. Also verify SIEM parsers and detections treat historical CAPSET records from pre-fix kernels cautiously and do not assume cap_pi was accurate before remediation.

Typical attack path

1. Gain local code execution on a Linux host through compromised credentials, application compromise, or another vulnerability.
2. Identify a privilege-escalation path involving Linux capabilities, file capabilities, ambient/inheritable capabilities, or a privileged exec transition.
3. Call capset() directly or indirectly to modify process capability sets, with focus on changing inheritable capabilities.
4. Rely on the vulnerable audit subsystem to log an inaccurate CAPSET record where the inheritable capability field reflects effective capabilities instead.
5. Continue with the broader privilege-escalation or persistence activity while audit-based monitoring and later forensic review have incomplete or misleading capability-change evidence.

How to detect it

This flaw does not create a distinctive network signature or standalone exploit artifact; detection focuses on identifying suspicious capability changes that may have been mislogged. Review Linux audit logs, auditd records, endpoint telemetry, and EDR process data for CAPSET activity, especially by unexpected users, service accounts, application processes, shells, interpreters, container runtimes, or post-exploitation tooling. In audit logs, search for CAPSET records and correlate them with SYSCALL, EXECVE, USER_CMD, CRED_*, and PATH records around the same timestamp and audit event ID. Treat cap_pi values in records generated by vulnerable kernels as unreliable; compare against process behavior, subsequent execve activity, file capabilities on executed binaries, and any eBPF/syscall traces if available. Look for sequences where a process changes capabilities and then launches a shell, interpreter, setuid/file-capability binary, container process, or administrative utility. Also review file capability changes using package baselines and getcap scans, because file capabilities can interact with inheritable process capabilities during exec. If threat hunting historical data, prioritize hosts with local compromise indicators, privilege escalation alerts, unusual administrative activity, or unexpected use of capability-aware tools.

• type=CAPSET
• cap_pi=
• cap_pe=
• cap_pp=
• syscall=capset
• comm="setcap"
• /usr/sbin/setcap
• /sbin/setcap
• security.capability
• getcap -r
• capsh
• setpriv
• setpcaps

What your security team should do

• Inventory Linux systems where auditd, kernel audit, EDR telemetry, or compliance controls rely on CAPSET records.
• Prioritize kernel updates on high-assurance systems, multi-user servers, container hosts, administrative jump hosts, CI/CD infrastructure, and regulated workloads.
• Reboot systems after kernel package updates and verify the active running kernel is the corrected version.
• Hunt historical logs for CAPSET events, but treat cap_pi values from vulnerable kernels as unreliable and correlate with process lineage, execve events, file capabilities, sudo activity, and EDR telemetry.
• Add or tune detections for unusual capset() usage, unexpected capability changes by non-administrative processes, and execution of binaries with file capabilities.
• Preserve relevant audit logs before patching if an investigation is active, while documenting that CAPSET inheritable capability fields may be inaccurate.
• Update incident response playbooks to note that Linux capability audit records generated by vulnerable kernels may require corroboration from independent telemetry.