Log4Shell timeline: what defenders should learn from it

Log4Shell (CVE-2021-44228) taught defenders that the hard part was not applying a patch but finding every place the library ran. The fix itself was a version bump, yet follow-on flaws meant the first fix was incomplete, so teams that could not inventory their software had to repeat the work.

What happened, and when?

Dates below come from the CISA advisory AA21-356A and the Apache Log4j security page.

• About 1 December 2021: CISA says exploitation reportedly began.
• 10 December 2021: Log4Shell is disclosed. It is a remote code execution flaw in Log4j 2.0-beta9 through 2.14.1.
• 13 December 2021: CVE-2021-45046 is disclosed. The 2.15.0 fix was incomplete in certain non-default configurations. Apache lists the fix as 2.16.0 for Java 8 and later.
• 16 December 2021: CVE-2021-45105 is disclosed, a denial of service from uncontrolled recursion in lookup evaluation.
• 17 December 2021: Log4j 2.17.0 is released.
• 21 December 2021: Log4j 2.12.3 is released for Java 7.

Apache also lists CVE-2021-44832, where a JDBC Appender configured with a malicious JNDI data source could allow remote code execution, but only for an attacker with write access to the logging configuration. It is fixed in 2.17.0 for Java 8 and later.

The original fixed versions for CVE-2021-44228 were 2.15.0 for Java 8 and later, 2.12.2 for Java 7, and 2.3.1 for Java 6. As the later CVEs show, those were not the end of the story.

Why was it so hard to respond?

Three reasons show up in the guidance itself.

Finding the library. CISA told organizations to inventory all assets using Log4j, including cloud assets, and to treat all Java and Log4j versions as vulnerable until verified. Log4j often arrives as a transitive dependency, inside another product or bundled in an archive, so a search of your own manifests misses copies.

Patching the right thing. CISA's wording was direct: "patching or updating Java is not enough, you must upgrade the Log4j library itself."

Workarounds with limits. Removing or renaming the JndiLookup class was listed as a temporary step, with a warning that it may be incomplete or cause instability.

What lessons hold up?

1. Inventory beats search. A current list of components per product answers "are we affected" in minutes. Searching file systems takes days.
2. Expect a second advisory. The first fix was followed by three more related CVEs in the same month. Plan for follow-ups, and track the state of each system per CVE.
3. Exposure controls buy time. CISA recommended blocking or allowlisting outbound LDAP and RMI and restricting outbound DNS from application servers while patching.
4. Assume exposure and hunt. The advisory told teams to review accounts and configuration changes made since 1 December 2021.
5. Verify with more than one method. CISA advised keeping records of patched assets and verifying fixes in more than one way.
6. Think about OT. For industrial control systems, the advice was to keep them off the internet, segment them, and apply vendor mitigations after testing.

Where can an SBOM help?

A software bill of materials lists the components in a product, including transitive ones. With an SBOM per release, finding Log4j is a query. Safeguard's CLI can generate and scan one, and the web app can answer questions about stored results. An SBOM does not fix anything by itself, but it moves the first question from "where is it?" to "which of these matter?"

What to do

1. Generate an SBOM for each product and service you run, and store it with the release.
2. Keep a tracked list of vendor products, and ask each for an SBOM or advisory status.
3. Write a runbook for a library emergency: inventory, isolate, patch, verify, hunt.
4. Practice it once a year with a past case such as this one.
5. Record each fix by CVE and version, since follow-on advisories change the target.

Quick check

Sources

• CISA: Apache Log4j vulnerability guidance, advisory AA21-356A
• Apache Logging Services: Log4j security

Last reviewed: 18 October 2026.