On March 30, 2022, researchers disclosed CVE-2022-22965, a critical remote code execution vulnerability in the Spring Framework. Within hours, proof-of-concept exploits circulated publicly. If your team ran Spring MVC or Spring WebFlux on JDK 9 or later with specific configurations, an attacker could execute arbitrary code on your server by sending a crafted HTTP request.
This wasn't a novel attack vector. Spring4Shell exploited class property manipulation through Spring's data binding mechanism—the same technique that led to Struts 2 vulnerabilities years earlier. Yet thousands of organizations scrambled to patch, many discovering they didn't know which applications used Spring or which Java versions they ran.
Timeline
- March 30, 2022, early morning UTC: Initial disclosure of CVE-2022-22965 on Chinese security forums.
- March 30, 2022, 12:00 UTC: Proof-of-concept exploit code published on GitHub.
- March 31, 2022: Spring releases versions 5.3.18 and 5.2.20 with patches.
- April 1-5, 2022: Mass scanning activity detected as attackers probe for vulnerable endpoints.
- Ongoing: Organizations continue discovering vulnerable Spring applications in legacy systems.
Which Controls Failed
No Software Bill of Materials
Most affected organizations couldn't answer a basic question: "Where do we use Spring Framework?" Without a software bill of materials (SBOM), security teams manually searched codebases and interviewed developers. Some discovered vulnerable applications only after detecting exploitation attempts in logs.
PCI DSS v4.0.1 Requirement 6.3.2 mandates maintaining an inventory of bespoke and custom software, including third-party components. If you can't list your dependencies, you can't secure them.
No Dependency Version Tracking
Teams that knew they used Spring often didn't know which version. Spring Framework 5.3.0 through 5.3.17 and 5.2.0 through 5.2.19 were vulnerable. Checking required examining build files across dozens or hundreds of repositories.
ISO 27001 Control 8.31 assumes you can identify what runs in each environment. Spring4Shell exposed organizations that couldn't map framework versions to deployed applications.
Delayed Patching Process
The patch window was narrow. Exploits appeared within hours of disclosure. Organizations with monthly or quarterly patch cycles couldn't respond fast enough. Even teams that prioritized the update faced deployment pipelines requiring days of testing and approval.
NIST CSF v2.0 function PR.IP-12 calls for a vulnerability management plan that addresses response timeframes based on risk. Spring4Shell demonstrated that "within 30 days" isn't fast enough for critical RCE vulnerabilities in internet-facing applications.
Missing Runtime Protection
Organizations running web application firewalls (WAFs) or runtime application self-protection (RASP) tools had additional time to patch. Those without runtime controls faced immediate risk from the moment exploits went public.
PCI DSS v4.0.1 Requirement 6.4.2 requires protecting public-facing web applications from attacks, either through code review or automated technical solutions like WAFs. This requirement exists precisely for zero-day scenarios where patches aren't yet available.
Java Version Confusion
The vulnerability affected JDK 9 and later, but many teams didn't track Java versions across their application portfolio. Some organizations ran mixed environments—JDK 8 in production but JDK 11 in staging—creating confusion about actual exposure.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.3: Maintain an inventory of bespoke and custom software and third-party components. Your SBOM should list every dependency, its version, and where it's deployed.
ISO/IEC 27001:2022 Control 5.22: Address information security in supplier relationships. If you use open source frameworks, you own the security responsibility. No vendor will patch your applications for you.
NIST 800-53 Rev 5 SI-2: Your flaw remediation process must include time frames for corrective action based on risk. Critical RCE vulnerabilities in internet-facing applications demand hour-to-day response times, not weeks.
SOC 2 Type II CC7.1: Your change management procedures must support emergency patches. If your deployment pipeline can't accommodate urgent security updates, you're not meeting this criterion.
Lessons and Action Items
Generate and Maintain SBOMs
Implement automated SBOM generation in your build pipeline. Tools like Syft, CycloneDX, or native package manager capabilities can produce machine-readable inventories. Store these artifacts with each release so you can query "which applications use Spring Framework 5.3.x" in minutes, not days.
Action: Add SBOM generation to your CI/CD pipeline this quarter. Choose CycloneDX or SPDX format for standardization.
Track Dependencies in Production
Your SBOM is worthless if you don't know what's deployed. Implement runtime dependency detection using tools that scan running applications or analyze deployed artifacts. This catches cases where build-time inventories don't match production reality.
Action: Deploy dependency detection agents to production within 90 days. Reconcile findings against your SBOM inventory.
Define Emergency Patch Procedures
Document a fast-track process for critical vulnerabilities. Specify who can authorize emergency changes, which testing you'll skip (and which you won't), and how you'll communicate with stakeholders. Practice this process before you need it.
Action: Write a one-page emergency patch runbook. Include decision criteria for when to use it and required approvals. Test it with a tabletop exercise.
Deploy Runtime Protection
WAFs and RASP tools buy time when zero-days emerge. Configure virtual patching rules that block known attack patterns while you test and deploy fixes. This isn't a substitute for patching—it's a bridge.
Action: If you run public-facing Spring applications, evaluate WAF or RASP deployment within 60 days. Configure virtual patching capabilities.
Standardize Java Versions
Running mixed Java versions complicates vulnerability assessment. Standardize on supported LTS releases and document exceptions. This makes it easier to evaluate whether vulnerabilities like Spring4Shell affect your environment.
Action: Audit Java versions across your application portfolio. Create a migration plan to standardize on JDK 11 or 17 (current LTS releases).
Spring4Shell didn't require sophisticated exploitation. It required only that organizations couldn't answer basic questions about their dependencies fast enough. If you still can't produce an SBOM or identify framework versions in under an hour, fix that before the next disclosure.
