CVE-2026-4897

What it actually does

CVE-2026-4897 is a local denial-of-service flaw in polkit affecting the setuid helper binary `polkit-agent-helper-1`. A local authenticated user can send specially crafted, excessively long data to the helper over standard input. Because the input is not sufficiently bounded, the process can consume excessive memory and trigger an out-of-memory condition. The primary impact is availability loss: affected Linux systems or workloads may become unstable, terminate important processes, or require administrative intervention or reboot. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high availability impact, with no direct confidentiality or integrity impact.

Why it matters to the business

An attacker who already has local user access to an affected system can intentionally exhaust memory and disrupt service availability. In server, virtualization, container, or platform environments such as Red Hat Enterprise Linux or OpenShift nodes, this can cause workload instability, failed authentication or authorization workflows, service interruptions, node degradation, or emergency operational response. The vulnerability is not currently listed in CISA KEV, has no known mature public exploitation in the provided data, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, it is still important on shared systems, multi-user Linux hosts, developer platforms, bastion hosts, CI/CD runners, and container infrastructure where untrusted or semi-trusted users can execute local code.

How an attack unfolds

An attacker first obtains the ability to run commands as a low-privileged local user on an affected Linux system. They then directly invoke or interact with the `polkit-agent-helper-1` setuid binary and provide an extremely large or malformed input stream through stdin. The vulnerable helper fails to enforce safe input bounds and continues allocating memory while processing the data. As memory pressure increases, the kernel out-of-memory killer may terminate the helper or other processes, and the system may become degraded or unresponsive. Depending on workload density and memory limits, the result may range from a transient service failure to broader node or host denial of service. This flaw does not provide privilege escalation by itself, but it can be used after initial local access to disrupt operations or interfere with incident response, monitoring, or shared compute resources.

How to fix it

Apply vendor-provided polkit updates as soon as they are available for the affected operating system or platform. Because no fixed versions were provided in the input, administrators should track advisories from the relevant distribution or platform vendor, including freedesktop polkit, Red Hat Enterprise Linux, and Red Hat OpenShift Container Platform, and update the affected packages to the latest patched release. Where immediate patching is not possible, reduce exposure by limiting local shell access to trusted users only, restricting execution on multi-user systems, applying resource controls such as cgroups or systemd limits to constrain memory consumption, monitoring OOM events, and ensuring critical workloads have appropriate memory reservations and restart policies. Avoid removing or changing setuid permissions on polkit components unless specifically advised by the OS vendor, as that may break legitimate authorization workflows.

How to confirm the fix worked

Confirm exposure by checking whether polkit is installed and whether `polkit-agent-helper-1` exists as a setuid executable, commonly under `/usr/lib/polkit-1/polkit-agent-helper-1`, `/usr/libexec/polkit-1/polkit-agent-helper-1`, or distribution-specific paths. Validate remediation by confirming the installed polkit package version matches the vendor-patched version once available. Review package manager output such as `rpm -q polkit`, `dnf updateinfo list polkit`, `yum updateinfo list polkit`, `apt list --installed policykit-1 polkitd`, or equivalent distribution tooling. In container platform environments, verify that node operating system images and platform-managed machine images have received the vendor fix. To safely validate mitigation, use non-destructive checks for package version and binary permissions rather than attempting to reproduce the OOM condition on production systems.

Typical attack path

1. Gain local command execution as a non-root user on an affected Linux system.
2. Identify that polkit and the `polkit-agent-helper-1` setuid helper are present and executable.
3. Feed an excessively large crafted input stream to `polkit-agent-helper-1` via stdin.
4. Cause the helper process to allocate excessive memory.
5. Trigger severe memory pressure or an out-of-memory condition.
6. Force service instability, process termination, node degradation, or host denial of service.

How to detect it

To determine whether exploitation may have occurred, review host logs for out-of-memory events, process terminations, and abnormal executions of `polkit-agent-helper-1`. Useful sources include systemd journal logs, kernel logs, auditd process execution records, endpoint detection telemetry, shell history where available, and platform node logs for OpenShift or Linux fleet management. Search for OOM killer messages referencing `polkit-agent-helper-1`, `polkitd`, or unrelated critical services being killed shortly after helper execution. Investigate bursts of local executions of the helper by non-administrative users, especially with large stdin input, unusual parent processes such as shells, scripts, Python, Perl, Ruby, or stress-testing utilities, and correlated memory exhaustion alerts. Because the flaw produces denial of service rather than a durable implant, evidence may be transient; prioritize centralized logs and telemetry retained outside the affected host. There are no known named threat actors, KEV listing, ransomware association, or public exploit maturity in the provided data, so detection should focus on behavioral signs of attempted local memory exhaustion rather than known campaign infrastructure.

• polkit-agent-helper-1
• /usr/lib/polkit-1/polkit-agent-helper-1
• /usr/libexec/polkit-1/polkit-agent-helper-1
• Out of memory: Killed process
• oom-killer
• Killed process
• invoked oom-killer
• Memory cgroup out of memory
• systemd-oomd
• polkitd
• polkit-agent-helper-1 invoked oom-killer
• Out of memory: Killed process * (polkit-agent-helper-1)

What your security team should do

• Inventory Linux hosts, OpenShift nodes, and shared systems where polkit is installed and local users can execute commands.
• Prioritize patching on multi-user servers, bastion hosts, developer workstations, CI/CD runners, terminal servers, container hosts, and OpenShift/RHEL infrastructure nodes.
• Track vendor advisories for exact fixed polkit versions and deploy the patched packages when released for the relevant distribution.
• Restrict local access to affected systems to trusted users until patched.
• Monitor for OOM events involving `polkit-agent-helper-1`, `polkitd`, or unexplained process termination on affected hosts.
• Apply memory resource limits and workload isolation where feasible to reduce host-wide impact from local memory exhaustion.
• Review recent local user activity on systems that experienced unexplained OOM conditions or node instability.
• Do not rely on network perimeter controls alone, because exploitation requires local execution rather than remote network access.