CVE-2021-45046 is a deserialization of untrusted data vulnerability in Apache Log4j2. CISA added it to the Known Exploited Vulnerabilities catalogue on 1 May 2023, which means attackers have used it in real attacks. Organisations running the affected product should apply the vendor fix or mitigation as a priority.
What this vulnerability means in Log4j2
Apache Log4j2 deserialization of untrusted data is dangerous because the logging path can become an execution path. In practice, attacker-controlled input may be interpreted by the library in ways that break the assumption that logs are passive text, turning a routine application component into an unexpected attack surface.
For a vulnerability of this type, the key concern is not just whether the application logs user input, but whether any code path passes attacker-influenced data into unsafe parsing or lookup behaviour. That is why the same flaw can matter across many products that embed the library, even when the rest of the application seems unrelated.
Why this class of flaw is security-critical
Deserialization bugs are high impact because they can shift control from data handling to code or object construction. If an attacker can influence how data is reconstructed, they may be able to trigger unsafe behaviour without needing valid application credentials or a traditional feature misuse path.
In the Log4j2 context, the risk is amplified by the library’s reach. Logging components are often reachable from public requests, background jobs, message queues, and internal service traffic, so a vulnerable deployment may expose the flaw anywhere untrusted strings enter the application.
For a practical reference point on how this vulnerability type is catalogued and tracked, use the CVE Program record alongside the NIST National Vulnerability Database entry rather than relying on secondary summaries alone.
How organisations check exposure
Exposure checking starts with asset inventory. Teams need to know which applications, containers, platforms, and third-party products include Log4j2, then determine where those components are actually deployed and reachable. An inventory-only approach is not enough unless it is paired with runtime and internet-facing exposure review.
Because dependencies are often embedded transitively, a vulnerable library can sit deep inside an application stack and still be reachable through normal request handling. Vendor advisories, software bills of materials, package metadata, and production configuration all help answer the same question: does this environment still contain an exploitable copy of the affected component?
When prioritising follow-up, pair exposure checks with vulnerability-management discipline. NHIMG’s Vulnerability Management Guide is useful here because it frames scope, prioritisation, verification, and remediation tracking as one workflow, not separate tasks.
Remediation, detection, and identity impact
Remediation should follow the vendor’s fix or mitigation guidance first, then be verified in production rather than assumed from package updates alone. If immediate patching is not possible, compensating controls usually focus on reducing exposure, constraining inbound paths, and limiting the chance that untrusted input reaches the vulnerable code path.
Detection should look for both exploitation attempts and signs of compromise after the fact. Even when a vulnerability is patched quickly, security teams should review logs, process activity, outbound connections, and unusual application behaviour to see whether an attacker used the flaw before remediation completed.
Identity impact becomes material if exploitation led to credential access, session theft, API key exposure, or service-account abuse. In that case, remediation is incomplete until any affected secrets, tokens, or keys are rotated and any trust established during the incident is reviewed. NHIMG’s State of NHI & AI Agent Breach Report is a useful companion for understanding how stolen credentials often turn a software flaw into broader lateral movement.
Risk and Threat Considerations
This vulnerability class matters because attackers do not need to attack the application through its intended business logic. If untrusted data reaches the vulnerable deserialization path, exploitation may occur through ordinary traffic, making the flaw attractive for opportunistic scanning and rapid mass exploitation.
Failure mechanism: attacker-controlled input reaches a parser or deserializer that assumes the data is safe, then the application processes unexpected object structures or unsafe lookups.
Impact: the result can range from application compromise and data exposure to broader infrastructure compromise if the affected process has access to sensitive files, credentials, or downstream services.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Untrusted deserialization is an input-handling failure that SI-10 is meant to prevent. |
| RA-5 — Vulnerability Monitoring and Scanning | Exposure to a known exploited CVE requires continuous identification and tracking of affected assets. | |
| SI-2 — Flaw Remediation | The term is an actively exploited vulnerability that requires timely remediation and verification. | |
| Recommendation — Validate and constrain untrusted inputs before they reach deserialization or parsing logic. Continuously scan assets and dependencies for the vulnerable Log4j2 component. Apply vendor fixes or mitigations and verify the vulnerable component is no longer present. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | This CVE is a vulnerability-management priority with exposure, verification, and remediation requirements. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Mitigations often depend on reducing exposure through secure configuration until patching is complete. | |
| Recommendation — Identify affected systems, prioritise remediation, and confirm the flaw is closed. Harden application and runtime settings to reduce exploitability while remediation is underway. | ||
Practitioner Guidance
Why practitioners should care: treat this as a library-risk issue, not just an application bug. A single vulnerable dependency can affect many services at once, so ownership needs to sit with both application teams and platform teams that manage shared runtimes.
What to watch for: repeated exploit probes, unexpected outbound connections, strange child processes, and any post-patch indicator that suggests the library was used before the fix was applied. If compromise is suspected, review whether any adjacent secrets or service accounts need rotation.
Practitioner takeaway: patching removes the known weakness, but only verification confirms that the vulnerable path is gone and that no earlier exploitation left a second problem behind.
Related resources from NHI Mgmt Group
- CVE-2021-23758 (Ajax.NET Professional Deserialization of Untrusted Data)
- CVE-2023-46604 (Apache ActiveMQ Deserialization of Untrusted Data)
- CVE-2026-20131 (Cisco Secure Firewall Management Center (FMC) Software and Cisco Security Cloud Control (SCC) Firewall Management Deserialization of Untrusted Data)
- CVE-2023-21529 (Microsoft Exchange Server Deserialization of Untrusted Data)