CVE-2021-45046: Apache Log4j2 Deserialization of Untrusted Data Vulnerability

CVE-2021-45046 is a vulnerability in Apache Log4j2 that allows remote code execution under certain non-default configurations. It stems from an incomplete fix for the earlier Log4Shell issue (CVE-2021-44228) and involves the Thread Context Lookup Pattern. Because Log4j2 is widely embedded in Java applications, servers, and enterprise software, successful exploitation can give an attacker control of the host. This vulnerability has been used by ransomware operators, making prompt action essential for IT and security teams.

Defenders should treat any system running Log4j2 as potentially exposed until they confirm the configuration and apply the vendor-recommended update. Specifics of affected releases and exact configuration triggers must be verified against the Apache Log4j security advisory.

How it works

The underlying weakness is classified as CWE-917 and described as a deserialization of untrusted data flaw. In Log4j2, the Thread Context Lookup Pattern can process attacker-controlled data in ways that were not fully blocked by the prior remediation. When the library is configured in certain non-default modes, an attacker who can influence log messages or thread-context values may trigger remote code execution. The attack surface is therefore limited to environments that enable the vulnerable lookup behavior; default installations are less likely to be directly exploitable, but many production systems deliberately enable advanced lookup features. Exact payload construction and required configuration flags are not detailed here; teams must consult the vendor advisory for the precise conditions.

Am I affected? How to find it in your systems

Apache Log4j2 commonly appears as a dependency inside Java applications, application servers, middleware, SIEM collectors, and custom enterprise services. Inventory steps include:

• Searching package repositories, container images, and build artifacts for log4j-core or related Log4j2 JARs.
• Examining application configuration files (log4j2.xml, log4j2.properties, or programmatic configuration) for Thread Context Lookup or related pattern usage.
• Querying software composition analysis (SCA) tools and software bills of materials (SBOMs) for Log4j2 components.
• Reviewing runtime process lists and classpaths on Java hosts for the presence of Log4j2 libraries.

Because the vulnerability requires non-default settings, simply finding the library is not sufficient; confirm whether the Thread Context Lookup Pattern is active. Telemetry signs of exploitation are similar to other Log4j remote-code-execution attempts: unexpected outbound network connections from Java processes, anomalous DNS or LDAP lookups, and sudden process spawning. Correlate these indicators with application logs that contain unusual lookup strings. Always cross-check version and configuration details against the official Apache advisory rather than relying on third-party lists.

How to remediate

The primary remediation is to apply the updates published by the Apache Log4j project, following the vendor instructions referenced by CISA. After patching:

• Rebuild and redeploy any applications that embed Log4j2 as a transitive dependency.
• Remove or disable unused lookup features in remaining configurations to reduce the attack surface for similar expression-language weaknesses.
• Validate that the Thread Context Lookup Pattern is no longer reachable under the new library version.
• Re-scan the environment with SCA tools to confirm no residual vulnerable copies remain in containers, libraries, or offline packages.

Document the change window and verify that logging still functions as required after the update.

If you can't patch immediately

Until the vendor update can be applied, reduce risk with compensating controls:

• Network segmentation: isolate systems that process untrusted input and run Log4j2 from the rest of the environment.
• Virtual patching or WAF rules: block known Log4j lookup patterns in HTTP headers, query strings, and request bodies at the edge.
• Disable the affected feature: if operationally feasible, turn off Thread Context Lookups and other expression-language features in Log4j2 configuration.
• Enhanced monitoring: alert on Java processes making unexpected external connections or spawning shells; retain detailed application and network logs for forensic review.
• Least-privilege execution: ensure the Java process runs with minimal OS privileges so that successful code execution has limited impact.

These measures buy time but do not replace the official patch.

If your data may have been exposed

Actively exploited vulnerabilities of this class frequently lead to ransomware deployment and data theft. If logs or telemetry indicate possible compromise, treat the host as breached: isolate it, preserve forensic evidence, and begin incident-response procedures. Organizations can also run a free exposure scan of their email addresses against known breach data sets to determine whether credentials or personal information have already appeared in public dumps. Confirm all technical details and remediation steps against the Apache Log4j advisory before closing the incident.