CODERED VTA

AWS Log4Shell Hotpatch Flaw Lets Local Users Run Commands as Root on Amazon Linux

Medium
Hacker in a dark room
Photo by Michael Geiger on Unsplash

AWS has published bulletin 2026-098-AWS disclosing CVE-2026-85656, an OS command injection flaw in the log4j-cve-2021-44228-hotpatch package on Amazon Linux. The tool dates from the Log4Shell response: it injects a Java agent into a running JVM and rewrites the lookup() method of loaded JndiLookup classes to return a fixed string, neutralising CVE-2021-44228 without a restart. Versions up to and including 1.3-8.amzn2 are affected; the fix ships in 1.3-9.amzn2. Any Amazon Linux host carrying the package is in scope.

AWS states that the flaw might allow a local user to execute arbitrary commands with root privileges via a Java process whose executable path contains embedded newlines. The hotpatch operates by attaching to Java processes already running on the host, which is how an attacker-controlled executable path reaches privileged code. AWS has not published a proof of concept, exploit code, or a technical breakdown, and its own wording stays conditional. The exposure is local rather than remote: an attacker must already be able to launch a process on the affected instance.

Tooling deployed to contain Log4Shell now carries its own local root escalation path. FIRST EPSS puts the chance of CVE-2026-85656 being exploited in the next thirty days at 1.1 percent, and no exploitation has been observed. CVE-2021-44228 itself remains in CISA KEV, listed on 10 December 2021, with known ransomware use and a 100 percent EPSS score, which is why the hotpatch is still widely deployed. Shared build servers and multi-tenant hosts where untrusted users can run code carry the most exposure.

Attack Surface

Cloud Service, Server OS

Tactics

Privilege Escalation, Execution

Techniques

  • T1068 – Exploitation for Privilege Escalation
  • T1059.004 – Command and Scripting Interpreter: Unix Shell

SuperPRO's Threat Countermeasures Procedures

  1. Update the package on Amazon Linux hosts to 1.3-9.amzn2 or later with 'yum update log4j-cve-2021-44228-hotpatch', then confirm the installed release with 'rpm -q log4j-cve-2021-44228-hotpatch' – anything at or below 1.3-8.amzn2 is vulnerable to CVE-2026-85656.
  2. Inventory the fleet for exposure by querying for the log4j-cve-2021-44228-hotpatch RPM and for an enabled log4j-cve-2021-44228-hotpatch service, using AWS Systems Manager Inventory or Patch Manager so that shared build and CI instances are identified first.
  3. Where the underlying applications already run a fixed Log4j release (2.17.1 or later), remove the hotpatch entirely with 'yum remove log4j-cve-2021-44228-hotpatch' rather than leaving a root-privileged Java agent resident on the host.
  4. Add an auditd execve rule on affected Amazon Linux instances and alert on process executable paths or argv values containing embedded newline (0x0A) characters, which is the exact trigger condition AWS names for CVE-2026-85656.
  5. Alert in EDR on any shell process (/bin/sh, /bin/bash) whose parent is the root-owned log4j-cve-2021-44228-hotpatch agent or its Java attach helper – the hotpatch has no legitimate reason to spawn an interactive shell.
  6. Restrict local account and SSH access on Amazon Linux hosts that still run the hotpatch, particularly multi-tenant build servers, since CVE-2026-85656 requires a local user able to start a Java process with an attacker-controlled executable path.
  7. Verify that applications previously covered only by the hotpatch are now running a Log4j build that fixes CVE-2021-44228, which remains in CISA KEV with a 100 percent EPSS score, so that removing or disabling the hotpatch does not reopen the original Log4Shell exposure.

Source

Code Red Cyber / VTA – coderedcyber.ai