How do you patch or mitigate CVE-2021-45046 (Apache Log4j2 Deserialization of Untrusted Data)?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

CISA's required action for CVE-2021-45046 is to apply updates per vendor instructions. In practice, find every instance of Apache Log4j2 in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What changes when CVE-2021-45046 is in your estate?

This flaw is not something to “watch” and defer, because the practical question is whether any Log4j2 instance is still reachable, exposed, or embedded in a system that can be invoked by untrusted input. The response should start with inventory and exposure analysis, then move to vendor guidance, because the real risk is continued use of a vulnerable component somewhere in the path.

For exploit-priority decisions, treat this as an actively exploited vulnerability problem rather than a routine maintenance item. The Zero-Day and Exploited Vulnerabilities Guide is useful here because it frames the same operational questions you need for Log4j2: what is exposed, how fast can you act, and what compensating controls matter when patching is not immediate.

One mistake teams make is assuming the issue ends once package managers show an updated library. In practice, Log4j2 can be present in application bundles, containers, appliances, and third-party software, so the subject is not just “patch the library”, it is “prove the vulnerable code path is gone from production reach”.

How do you patch and contain it safely?

The core remediation is to apply the vendor security update or the vendor-documented mitigation everywhere the affected component exists. If a system cannot be fixed promptly, reduce exposure by removing internet access, restricting the reachable surface, or taking the product out of service until a supported fix is in place. Use the vendor advisory for version-specific instructions and the CISA Known Exploited Vulnerabilities Catalog as the operational trigger for urgency.

Because this vulnerability sits in the parsing path for untrusted data, mitigation is not only about the host that contains Log4j2. Reverse proxies, front doors, job runners, internal services, and downstream libraries can all be part of the exploitable path if they accept attacker-controlled input and pass it into a vulnerable application stack.

The best response sequence is to identify all affected assets, patch or mitigate by precedence of exposure, and verify the fix from the perspective of real traffic, not just a build manifest. The NIST Cybersecurity Framework 2.0 maps well to that sequence because the issue crosses asset identification, protective controls, detection, and recovery.

When patching must wait, the most defensible temporary measure is to narrow the attack surface enough that the vulnerable code path is no longer reachable from untrusted sources. That is stronger than hoping an exploit will not be attempted, and it is usually the right exception posture when the component sits behind a public interface.

What should you check after remediation?

After you patch or mitigate, assume earlier exploitation may already have occurred and review logs for suspicious requests, anomalous child processes, unexpected outbound connections, and signs of post-exploitation activity. The goal is not only to confirm the patch, but to determine whether the flaw was used before you closed it.

If the vulnerable component handled authentication material, tokens, or service credentials, rotate the relevant secrets and invalidate sessions where the application design allows it. That step is especially important when the application was internet-facing, because the attacker’s first objective is often access persistence rather than immediate destruction.

Also validate that the vulnerable version is gone from every runtime location, including containers, embedded application packages, and other artifacts that may not show up in a simple host-level check. The Vulnerability Management Guide is relevant to that verification step because it treats scope, prioritisation, exception handling, and post-remediation confirmation as part of the same workflow.

If the component remains in a third-party product, track the vendor’s remediation status separately from your own patch status, because a local scan can say “clean” while the product still embeds the vulnerable code in another shipped artifact.

Risk and Threat Considerations

This vulnerability matters because untrusted-input parsing bugs often become reliable entry points for code execution or privilege abuse when exposed application paths remain reachable. The practical risk is not just a crash or service issue, but the possibility that an attacker uses the flaw to gain a foothold, execute additional tooling, or pivot into adjacent systems.

Failure mechanism: An attacker sends crafted input to a Log4j2-enabled component, the application processes that input on an exposed path, and the vulnerable behavior is triggered before defensive controls can stop it.

Impact: The likely consequence is compromise of the affected application, followed by credential theft, lateral movement, persistence, or other post-exploitation activity depending on what the system can reach.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	CVE patching and exposure reduction are core vulnerability-management tasks.
Recommendation — Prioritise and verify remediation for exposed Log4j2 instances under your vulnerability management process.
NIST CSF 2.0	ID.AM-01 — Physical devices and systems within the organization are inventoried	Finding every Log4j2 instance depends on complete asset inventory and scope visibility.
	PR.IP-12 — A vulnerability management plan is implemented	This CVE requires coordinated patching, mitigation, exception handling, and validation.
	DE.CM-09 — Malicious code is detected	Post-patch log review is needed to find signs of exploitation before remediation.
Recommendation — Inventory all affected assets and embedded components before declaring remediation complete. Apply your vulnerability management plan to patch, mitigate, and verify Log4j2 remediation. Review telemetry and logs for indicators of exploitation after remediation.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The flaw requires vendor patching, mitigation, and tracking of remediation status.
Recommendation — Remediate the vulnerable component using vendor guidance and track completion.

Practitioner Guidance

What to prioritise: Start with internet-facing systems and anything that processes external input, then move inward to internal services and bundled dependencies. Do not let “not directly internet-facing” become a reason to defer, because internal reach plus one compromised application is often enough for exploitation to matter.

What to verify: Confirm that remediation changed the runtime state, not just the dependency list. You want evidence that the vulnerable code is absent or unreachable, and that logs were reviewed for signs of earlier abuse before the system was returned to normal trust.

Decision rule: If a system cannot be patched quickly and you cannot prove the vulnerable path is unreachable, treat isolation or shutdown as the safer interim action than leaving the service exposed with a known exploit path.

Practitioner takeaway: For exploited vulnerabilities, the real deliverable is not a patched package alone, but a verified reduction in exposure plus enough post-remediation evidence to know whether the flaw was already used.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org