CVE-2021-44228: Apache Log4j2 Remote Code Execution Vulnerability

CVE-2021-44228 is a remote code execution vulnerability in Apache Log4j2, the widely used Java logging library. It arises because JNDI features do not adequately protect against attacker-controlled JNDI-related endpoints, allowing an attacker who can influence logged data to trigger code execution on the affected system. The flaw has been actively exploited and is known to have been used by ransomware operators, so organizations running Log4j2 should treat discovery and remediation as high priority.

Public detail on exact version ranges and configurations must be confirmed against the vendor advisory. The weakness classes involved include improper input validation, uncontrolled resource consumption, and deserialization of untrusted data.

How it works

Apache Log4j2 supports JNDI lookups as part of its message formatting and lookup features. When those features do not sufficiently restrict or validate attacker-controlled endpoints, an adversary who can get a specially crafted string into a log message can cause the library to contact an external naming or directory service under the attacker’s control. That interaction can lead to the loading and execution of attacker-supplied code on the host running the vulnerable Log4j2 instance.

In practical terms, any application or service that logs untrusted input (HTTP headers, form fields, user-agent strings, or other externally supplied data) without additional safeguards can become an entry point. The CWE mappings (CWE-20, CWE-400, CWE-502) reflect that the root issues are insufficient validation of input, potential for resource abuse, and unsafe handling of data that can result in object instantiation or code loading. Exact exploit mechanics and payload formats should be taken only from authoritative vendor or CISA guidance; defenders should not rely on incomplete public write-ups.

Am I affected? How to find it in your systems

Log4j2 is commonly embedded in Java applications, application servers, enterprise software packages, cloud services, and security or monitoring tools. It may appear as a direct dependency or transitively through other libraries.

• Inventory all Java-based applications, appliances, and containers. Search file systems and package manifests for Log4j2 artifacts (for example, jar names containing “log4j-core” or related components).
• Use software composition analysis, dependency-check tools, or vendor-supplied scanners to identify the library and its version. Confirm whether the installed version and configuration are listed as affected in the official Apache Log4j advisory.
• Check runtime configurations for JNDI lookup usage and whether message lookups are enabled.
• Review application and web-server logs for unusual JNDI-related strings or outbound connection attempts to unexpected LDAP, RMI, or other naming services that coincide with logging activity. Network telemetry showing sudden external connections from Java processes after receiving external input can also be a signal, though absence of such signs does not prove safety.
• Pay particular attention to internet-facing services and any component that logs data from untrusted sources.

Because Log4j2 is often bundled inside third-party products, extend the search to vendor applications and request confirmation from those vendors if you cannot inspect the binaries yourself.

How to remediate

The primary remediation is to apply the vendor-supplied update that addresses CVE-2021-44228. Per CISA direction, for all affected software assets for which updates exist, the only acceptable remediation actions are: (1) apply the updates, or (2) remove the affected assets from the network. Temporary mitigations are acceptable only until updates are available.

• Obtain the fixed Log4j2 release or the patched version of any product that embeds it, following the Apache Log4j and product-vendor advisories.
• Replace vulnerable jars, rebuild and redeploy applications, and verify the new version is running.
• After patching, re-scan to confirm no vulnerable copies remain in offline installers, container images, or backup environments that could be restored later.
• Where the library cannot be updated immediately, follow the temporary measures documented by CISA only as a bridge until the update can be applied or the asset can be removed.

Hardening steps that reduce exposure for this class of issue include disabling unnecessary JNDI or message-lookup features once the vendor confirms it is safe to do so, ensuring logging pipelines do not process fully untrusted data without sanitization, and keeping dependency inventories current so future library flaws are found quickly.

If you can't patch immediately

If an update cannot be deployed at once, reduce risk with compensating controls while you schedule the permanent fix:

• Remove or isolate the affected asset from agency or production networks when feasible, consistent with CISA’s required action.
• Apply temporary mitigations exactly as described in the CISA-recommended measures for Apache Log4j; treat them as short-term only.
• Segment systems that must remain online so that a compromised Log4j2 host has limited reach to sensitive data stores or domain controllers.
• Use WAF or reverse-proxy rules that detect and block common JNDI lookup patterns in inbound requests, understanding that such virtual patching is incomplete and can be bypassed.
• Disable or restrict the vulnerable lookup functionality if the vendor documentation permits it for your version and use case.
• Increase monitoring for outbound connections from Java processes to unfamiliar internal or external endpoints, and alert on anomalous log messages that contain JNDI or naming-service syntax.
• Ensure EDR and network detection content that covers this vulnerability class is enabled and tuned.

Document every temporary control and the date by which the permanent update or removal will occur.

If your data may have been exposed

Actively exploited remote-code-execution vulnerabilities, including those known to be used by ransomware groups, frequently lead to full system compromise, data theft, and follow-on extortion. If you discover vulnerable Log4j2 instances that were reachable by untrusted input, assume an attacker may have achieved code execution and begin incident-response procedures: isolate hosts, preserve logs and memory where possible, hunt for persistence and lateral movement, and reset credentials that could have been accessed from the compromised environment.

Organizations and individuals can also check whether email addresses associated with the environment appear in known breach corpora by running a free exposure scan; that check does not confirm or deny compromise from this CVE but can surface additional credential-exposure risk that should be addressed with password changes and multi-factor authentication.