CVE-2021-44228

What it actually does

This is a remote code execution flaw in Apache Log4j 2's log4j-core component where attacker-controlled text written to logs can trigger JNDI lookup resolution. In vulnerable versions, specially crafted log message content can cause the Java process to contact attacker-controlled LDAP, RMI, DNS, or other JNDI endpoints and, depending on runtime conditions, load or execute attacker-controlled code in the context of the affected application. The flaw is remotely reachable, requires no authentication or user interaction, and can be triggered through any application input that is logged, including HTTP headers, URL paths, request parameters, usernames, chat messages, API fields, or other logged data. It affects Apache Log4j2 2.0-beta9 through 2.15.0, excluding specific security releases 2.12.2, 2.12.3, and 2.3.1; it is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.

Why it matters to the business

Successful exploitation can give an attacker control of business applications, enabling data theft, credential compromise, ransomware deployment, cryptomining, botnet installation, lateral movement, and service disruption. Because Log4j is embedded in many commercial, open-source, cloud, and internally developed Java applications, exposure is often indirect and difficult to inventory. This vulnerability is in the CISA Known Exploited Vulnerabilities catalog, has been used in ransomware campaigns, has extremely high exploitation probability, and has been actively exploited in the wild for years, so unremediated systems should be treated as high-priority incident response targets rather than routine patching items.

How an attack unfolds

An attacker identifies an internet-facing or internally reachable application that uses a vulnerable log4j-core version. The attacker sends a request or message containing a JNDI lookup payload in a field likely to be logged, such as a User-Agent header, X-Forwarded-For header, URL path, form field, API parameter, or authentication field. When the application logs that value, Log4j evaluates the lookup and causes the Java process to initiate an outbound connection to attacker-controlled infrastructure over LDAP, RMI, DNS, or another supported JNDI protocol. The attacker uses that callback to confirm vulnerability and, where runtime conditions permit, delivers a malicious Java class or serialized object that executes inside the application process. After code execution, the attacker commonly runs discovery commands, downloads second-stage malware, steals secrets from environment variables or configuration files, deploys web shells or persistence, moves laterally using exposed credentials, or installs ransomware or cryptominers.

How to fix it

Upgrade all uses of Apache Log4j log4j-core to a fixed version. For the main 2.x line, upgrade to Log4j 2.16.0 or later, preferably the latest available 2.x release, because 2.16.0 removes the vulnerable JNDI functionality. For Java 7 constrained deployments, use 2.12.2 or 2.12.3 or later from the 2.12.x security line. For legacy 2.3.x deployments, use 2.3.1 or later. Remove vulnerable log4j-core JARs from applications, container images, fat JARs, shaded dependencies, plugins, vendor packages, and appliance bundles. If immediate upgrade is impossible, remove the JndiLookup class from vulnerable log4j-core JARs, disable message lookups where supported, restrict outbound LDAP/RMI/DNS/HTTP egress from application servers, and apply vendor-specific mitigations; these should be considered temporary controls only. The supplied package metadata lists git/git as fixed in commit 754884255bb580df159e58defa81cdd30b5c430c, but remediation for this vulnerability should focus on embedded or transitive Apache Log4j log4j-core usage and vendor-provided fixed builds.

How to confirm the fix worked

Confirm remediation by performing a software composition analysis and filesystem scan for log4j-core artifacts, including nested JARs, shaded JARs, container layers, application archives, and vendor-installed libraries. Verify that no vulnerable log4j-core versions remain: 2.0-beta9 through 2.15.0 are vulnerable except 2.12.2, 2.12.3, and 2.3.1. Confirm applications are running the updated dependency, not merely that a package manager shows an updated package. Restart affected Java services after replacement and retest with a benign out-of-band lookup canary in a controlled manner to ensure vulnerable lookup resolution no longer occurs. Validate that egress controls block unexpected outbound LDAP, RMI, and other high-risk callbacks from application tiers. Review SBOMs, dependency lockfiles, build artifacts, container images, and vendor advisories to ensure direct and transitive dependencies have been remediated.

Typical attack path

1. Locate a potentially vulnerable Java application, service, appliance, or embedded dependency using vulnerable log4j-core.
2. Send crafted input containing a JNDI lookup string to fields that are commonly logged, such as HTTP headers, URL paths, usernames, search fields, API parameters, or message bodies.
3. Observe outbound LDAP, RMI, DNS, or HTTP callbacks from the target application to attacker-controlled infrastructure.
4. Use the callback to validate exposure and, where possible, cause the Java runtime to retrieve or execute attacker-controlled code.
5. Execute commands under the privileges of the affected Java application process.
6. Download second-stage tooling such as reverse shells, credential stealers, botnet agents, cryptominers, or ransomware loaders.
7. Perform discovery, credential harvesting, persistence, lateral movement, data exfiltration, or destructive actions.

How to detect it

To determine whether exploitation already occurred, review application logs, web server logs, API gateway logs, WAF logs, load balancer logs, authentication logs, EDR telemetry, DNS logs, proxy logs, firewall logs, NetFlow, and cloud workload logs for JNDI lookup payloads and related callbacks. Search both raw and decoded logs because attackers commonly obfuscate payloads using mixed case, nested lookups, URL encoding, Unicode escaping, and string concatenation. Look for outbound connections from Java application hosts to unusual LDAP, LDAPS, RMI, DNS, CORBA, IIOP, or HTTP endpoints shortly after suspicious inbound requests. In endpoint telemetry, investigate Java processes spawning shell interpreters, PowerShell, curl, wget, certutil, python, perl, bash, sh, cmd.exe, or suspicious child processes, especially if followed by downloads into temporary directories. Examine filesystem artifacts such as newly written class files, JARs, scripts, web shells, cron jobs, systemd units, startup items, and cryptominer binaries. In container environments, review container stdout/stderr, image layers, runtime events, process creation, and unexpected network egress. Because this issue has been exploited by ransomware and commodity botnet operators, also hunt for credential dumping, privilege escalation, lateral movement, unusual archive creation, data staging, and encryption-related activity following any suspected exploit attempt.

• ${jndi:
• ${jndi:ldap://
• ${jndi:ldaps://
• ${jndi:rmi://
• ${jndi:dns://
• ${jndi:iiop://
• ${jndi:corba://
• jndi:ldap
• jndi:rmi
• jndi:dns
• jndi:ldaps
• ${${::-j}${::-n}${::-d}${::-i}:
• ${${lower:j}${lower:n}${lower:d}${lower:i}:
• ${${upper:j}${upper:n}${upper:d}${upper:i}:
• %24%7Bjndi%3A
• %24%7Bjndi:
• $%7Bjndi:
• ${env:AWS_SECRET_ACCESS_KEY}
• ${env:AWS_ACCESS_KEY_ID}
• ${env:HOSTNAME}
• ${env:USER}
• ${sys:java.version}
• ${java:version}
• User-Agent: ${jndi:
• X-Forwarded-For: ${jndi:
• X-Api-Version: ${jndi:
• Referer: ${jndi:
• java.lang.ClassNotFoundException
• javax.naming.InitialContext
• com.sun.jndi.ldap.LdapCtxFactory
• Exploit.class
• ldap://
• rmi://
• /tmp/kinsing
• /tmp/kdevtmpfsi
• /tmp/xmrig
• xmrig
• kinsing
• kdevtmpfsi
• java -> /bin/sh
• java -> /bin/bash
• java -> curl
• java -> wget
• java -> powershell.exe
• java -> cmd.exe

What your security team should do

• Treat any remaining exposure as critical because the vulnerability is remotely exploitable without authentication, is in the CISA KEV catalog, has been used in ransomware campaigns, and exploitation remains widespread.
• Immediately inventory all Java applications, containers, appliances, CI/CD systems, vendor products, and internally built services for log4j-core, including nested and shaded copies.
• Patch or replace vulnerable Log4j versions with fixed releases; prioritize internet-facing systems, identity systems, management platforms, CI/CD infrastructure, data platforms, and systems with access to sensitive credentials.
• Run threat hunts for historical exploitation from December 2021 onward where logs are available, focusing on JNDI payload strings, outbound LDAP/RMI/DNS callbacks, Java child processes, suspicious downloads, and post-exploitation activity.
• Block or tightly restrict outbound LDAP, RMI, LDAPS, DNS tunneling patterns, and direct internet egress from application servers that do not require it.
• Rotate credentials, API keys, tokens, and secrets accessible to affected applications if exploitation is suspected or cannot be ruled out.
• Review vendor advisories and SBOMs for third-party products because vulnerable Log4j may be bundled inside products that do not expose it through normal package inventories.
• Deploy detection rules for obfuscated JNDI payloads and for Java processes spawning shells, download utilities, scripting interpreters, or cryptomining tools.
• For systems that were exposed before remediation, preserve logs and perform incident response triage rather than assuming patching alone removes compromise.