Log4j Temporary Vulnerability Fix

What the Log4Shell mitigation Worklet does

This Automox Worklet™ applies the recommended emergency workaround for CVE-2021-44228, the Log4Shell remote code execution vulnerability in Apache Log4j 2.x. The Worklet strips the org/apache/logging/log4j/core/lookup/JndiLookup.class entry out of every log4j-core-*.jar file under a configured installation directory. Removing the class disables the JNDI message lookup feature that attackers exploit through specially crafted log strings such as ${jndi:ldap://...}.

The remediation script reads a hardcoded log4jpath value that points at your Log4j install root (the bundled default is /usr/local/apache-log4j-2.15.0-bin – edit the script before deployment). It runs zip -q -d "$log4jpath"/log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class and writes a success or failure line to the Automox activity log. Because the script targets the JAR archive directly, the mitigation persists even if log4j2.formatMsgNoLookups=true was never set as a JVM argument or the LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable cannot be deployed.

A full application restart is required after the JAR is modified. The running JVM keeps the original class loaded in memory until the process recycles, so the change does not take effect until the service is bounced. This Worklet is intentionally a run-once mitigation: the evaluation script returns exit 1 every cycle so remediation runs whenever the policy fires, which lets you re-apply the fix after a redeploy overwrites the JAR.

Why apply the Log4Shell emergency workaround

Log4Shell carries a CVSS v3.1 base score of 10.0, the maximum severity rating. It affects Log4j 2.0-beta9 through 2.14.1 and is trivially exploitable by any unauthenticated attacker who can influence a string that gets logged. Within 72 hours of public disclosure on December 10, 2021, mass exploitation included Mirai variants, Kinsing cryptominers, Conti ransomware staging, and state-sponsored access brokers. CISA added CVE-2021-44228 to the Known Exploited Vulnerabilities catalog the same week. The recommended permanent fix is Log4j 2.17.1 or later, but JAR-level removal of JndiLookup.class is the workaround the Apache Logging Services team explicitly documents for installations that cannot upgrade immediately.

CVE-2021-44228 Log4Shell exposure persists wherever a Java application still ships a vulnerable log4j-core JAR, and Apache's permanent fix requires application-team coordination that can take weeks. This Worklet applies the official Apache temporary mitigation – removing JndiLookup.class from every log4j-core JAR on disk – across every Linux host in scope inside a single policy run. The fix neutralizes the JNDI-attack vector immediately while application owners stage the patched 2.17.x rollout on their own schedule.

How the Log4Shell JAR mitigation works

1. Evaluation phase: The evaluation.sh script returns exit 1 unconditionally. This is intentional: the Worklet is a run-once mitigation action, so the evaluation phase always schedules remediation. Scope the policy to the Linux endpoints you know carry a vulnerable Log4j installation, or pair this Worklet with a detection Worklet that first locates log4j-core-*.jar files before the policy fires.

2. Remediation phase: remediation.sh validates that log4jpath is non-empty, then runs zip -q -d "$log4jpath"/log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. The -q flag suppresses zip's normal output, and -d deletes the named entry from the archive in place. zip's own output is sent to /dev/null, and the script then echoes "Successfully removed JndiLookup.class." on success or "failed to remove JndiLookup.class." on failure to the Automox activity log. The script does not restart the affected application or service – that step is operator-owned and intentional.

Log4Shell mitigation requirements

• Linux endpoint running Apache Log4j 2.0-beta9 through 2.14.1 (the vulnerable range)

• Edit the hardcoded log4jpath value in remediation.sh to match the install root of your Log4j directory (the bundled example is /usr/local/apache-log4j-2.15.0-bin)

• The zip utility installed and on PATH (yum install zip / apt-get install zip on minimal builds)

• Root privileges for the Automox agent, which is the default agent context

• A test endpoint that mirrors production. The JAR modification can break applications that legitimately use JNDI lookups inside log statements

• A planned application restart window after the policy runs. The JVM keeps the original class in memory until the process recycles

• Awareness of your SDLC pipeline. CI/CD redeploys that overwrite the modified JAR will reintroduce the vulnerable class until this Worklet runs again

Expected Log4j state after JndiLookup removal

After remediation, the JndiLookup class no longer exists inside the archive. Validate by listing the JAR contents: unzip -l "$log4jpath"/log4j-core-*.jar | grep JndiLookup should return no results, and zipinfo "$log4jpath"/log4j-core-*.jar | grep -c JndiLookup.class should report 0. The Automox activity log captures the run output and exit code for compliance evidence.

Once the affected JVM process is restarted, ${jndi:ldap://...} style payloads inside logged strings no longer resolve to remote class loads. The application continues to start because Log4j tolerates the missing class at runtime: ERROR statusLogger Unable to create Lookup messages appear in the Log4j status output, which is expected. Plan the permanent upgrade to Log4j 2.17.1 or later as a follow-up policy; CISA and Apache both treat the JAR mitigation as a stopgap, not a fix. Leaving the Worklet on a recurring schedule keeps the JAR clean across CI/CD redeploys until the upgrade lands.