Log4Shell, CVE-2021-44228, was a critical remote code execution flaw in Apache Log4j 2. Your organization would have handled it faster with a searchable inventory of every Java application and library, a patch path measured in hours, limits on outbound traffic from servers, and a habit of hunting for exploitation, not only scanning.
This is a controls checklist drawn from CISA advisory AA21-356A, not a judgment on anyone caught by it.
What do we know?
CISA's advisory lists three related CVEs. CVE-2021-44228, Log4Shell, was disclosed on 10 December 2021 and affects Log4j 2.0-beta9 through 2.14.1. CVE-2021-45046 followed on 13 December, and CVE-2021-45105, a denial of service issue, on 16 December. Log4j 2.17.0 was released on 17 December, and the advisory points to it for Java 8 and later, and to 2.12.3 for Java 7.
CISA notes that exploitation reportedly began around 1 December 2021. It also stressed that upgrading Java alone does not fix the problem. You have to update the Log4j library.
The checklist
1. Can you find every Log4j in a day? CISA's first recommendation is to inventory all assets that use Log4j, including cloud assets, and to assume all Java and Log4j versions are vulnerable until verified. Log4j hides in vendor products and inside fat JARs, not only in your own projects. An SBOM per build makes this a query.
2. Do you know which vendor products contain it? CISA tells OT and ICS operators to check each product against vendor advisories. Keep a list of third-party software with a contact for security notices.
3. How fast can you ship a library upgrade? The fix was not a config toggle. Measure the time from decision to production for a dependency bump on your slowest service.
4. Are workarounds tracked? The advisory describes removing the JndiLookup class as a temporary workaround that may be incomplete, to be replaced by a proper patch. Record each workaround with an owner and an expiry.
5. Can servers call out freely? CISA advises blocking or allowlisting outbound LDAP and RMI traffic, and blocking direct outbound DNS except through approved resolvers. Servers that cannot reach arbitrary hosts are much harder to exploit.
6. Do you hunt, not just scan? The advisory says to treat vulnerable assets as potentially compromised and to look for signs of successful exploitation. It notes that blocking attacker IP addresses is unreliable because of heavy benign scanning.
7. Do you verify with more than one method? CISA recommends scanning patched systems by multiple methods, because one scanner can miss a bundled copy.
8. Are changes recorded? Attackers may patch systems they have compromised, so a patched host is not proof it is clean.
Where does reachability help?
Once you have found Log4j everywhere, the order of work matters. Internet-facing services that log user-controlled input go first. Reachability analysis can show whether a call path leads to the vulnerable logging code, which helps rank the list. It does not replace patching everything.
What to do
- Keep a current inventory of libraries per build, including transitive and bundled ones.
- Maintain a vendor contact list for security advisories.
- Time a library upgrade drill on your slowest service.
- Track workarounds with an owner and a deadline.
- Restrict outbound LDAP, RMI and DNS from servers.
- After patching, hunt for exploitation signs back to the start of the exposure window.
- Confirm fixes using two independent methods.
Quick check
Is upgrading Java enough for Log4Shell?
No. CISA says the Log4j library itself must be updated, to 2.17.0 or later on Java 8 and above.
Is removing the JndiLookup class a permanent fix?
No. CISA describes it as a temporary workaround that may be incomplete, to be replaced by a proper patch.
Sources
Last reviewed: 18 October 2026.
