The Spring4Shell disclosure (CVE-2022-22965) emerged through Wednesday and Thursday with active exploitation reported from Friday morning. The vulnerability is in the Spring Framework's DataBinder mechanism, used by Spring MVC and Spring WebFlux applications to bind HTTP request parameters to Java objects. An attacker who can submit specifically-crafted request parameters can manipulate the underlying Java class fields, including class-loader properties, in ways that allow arbitrary code execution against the Spring application. The attack path requires specific configuration conditions (Spring application running on Tomcat, JDK 9 or higher, Spring Framework 5.3.x prior to 5.3.18 or 5.2.x prior to 5.2.20, packaged as WAR rather than executable JAR), which limits the affected population substantially compared to Log4Shell's near-universal applicability.
The technical content is interesting in its lineage. The DataBinder issue is, on the technical analysis (VMware advisory on Spring4Shell, March 31), a re-emergence of a class of issue that was identified and partially patched in 2010 but for which the patch did not cover JDK 9+ scenarios where additional class-loader-manipulation primitives became available. The 12-year gap between original-disclosure and current-disclosure is a useful reminder that vulnerability classes do not necessarily resolve cleanly with patches; the underlying assumption-and-implementation gaps can persist for years and re-emerge against subsequent platform changes.
The customer-portfolio response cadence is now familiar from December. Identify Spring Framework usage across customer-organisation Java applications (the SBOM discipline that Log4Shell catalysed is now operational and the inventory work is materially faster than it was in December). Identify the subset of Spring applications running in the affected configuration (Tomcat-on-JDK-9+, WAR-packaged). Apply the upgrade to Spring 5.3.18 or 5.2.20 where the configuration is in scope; apply mitigation measures (specifically, configuring the DataBinder's disallowed fields list) where upgrade is not immediately tractable. The customer-portfolio audit completed within 48 hours of disclosure with no in-scope vulnerable instances found across the customer estates — the post-Log4Shell SBOM discipline has produced operational benefit.
The wider strategic point about supply-chain disclosure cadence is that the security-research community's response to Spring4Shell has been substantially better-coordinated and faster than the December Log4Shell response was. The Log4Shell-driven catalysing event — the broader recognition across the Java ecosystem and beyond of the structural risks of dependency-tree complexity — has produced visible operational improvement in the response posture. The customer-organisation programme work that Log4Shell catalysed is operationally visible in the Spring4Shell response timeline.
I will write less on this specific chain because the operational story is, by mid-April, well-understood and the customer-portfolio work is in motion. The structural-lessons piece about the Log4Shell-catalysed improvements is being incorporated into the supply-chain book that I noted in the January opening post.