What Happened
In March 2022, security researchers disclosed CVE-2022-22965 (Spring4Shell), a remote code execution vulnerability in the Spring Framework's parameter binding mechanism. Organizations patched their Spring applications, thinking the issue was resolved.
However, researchers at Snyk discovered that the same vulnerability affects Glassfish and Payara application servers when processing Spring-based applications. The exploit works differently but achieves the same outcome: arbitrary file access. In proof-of-concept testing, attackers gained access to /etc/passwd and other sensitive files.
This wasn't a new vulnerability but the same flaw, now exploitable through a different attack surface that many teams had overlooked when they patched their Spring dependencies.
Timeline
March 2022: Initial Spring4Shell disclosure (CVE-2022-22965). Spring Framework releases patches in versions 5.3.18 and 5.2.20.
March-April 2022: Organizations update spring-beans packages. Most security teams consider the incident resolved.
[Date unknown]: Snyk researchers identify that Glassfish and Payara servers remain vulnerable when serving Spring applications, even after Spring Framework patches are applied.
Post-disclosure: Organizations running Glassfish or Payara must now re-evaluate their Spring4Shell remediation efforts and apply server-level updates in addition to framework patches.
Which Controls Failed or Were Missing
Incomplete Vulnerability Remediation
Your team patched the Spring Framework but didn't evaluate whether the underlying application server introduced additional exposure. This is like fixing a broken lock on your front door while leaving the back door wide open.
The vulnerability exists in how servers handle class loading and parameter binding when they interact with Spring components. Updating spring-beans alone doesn't address server-level implementations that replicate the vulnerable behavior.
Missing Attack Surface Inventory
Most teams track application dependencies—your pom.xml or build.gradle files. Fewer teams maintain a complete inventory of how those applications are deployed. Which application servers? Which versions? How do the server and framework interact?
When Spring4Shell first emerged, your remediation checklist likely read: "Update Spring Framework to 5.3.18+." It should have read: "Update Spring Framework AND verify that all application servers in the deployment path don't reintroduce the vulnerability through their own parameter binding implementations."
Inadequate Patch Verification
Updating a package and verifying that the vulnerability is actually closed are different activities. Your team needs to test that the exploit no longer works—not just confirm that a newer version number appears in your dependency manifest.
For Spring4Shell, that means attempting to access restricted files through crafted requests. If you can still reach /etc/passwd after patching Spring, your application server is the problem.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 6.3.3
"Security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs)."
This requirement extends to the entire runtime environment—frameworks, servers, containers, and orchestration layers. When CVE-2022-22965 was disclosed, compliance meant evaluating every component in your stack that handles HTTP requests and parameter binding.
ISO/IEC 27001:2022 Control 8.8
"Technical vulnerabilities are identified, evaluated and appropriate measures are taken to address the associated information security risks."
The key phrase: "appropriate measures." Patching Spring Framework was necessary but insufficient. An appropriate measure includes validating that the patch actually eliminates the attack vector across all deployment scenarios. If your Spring application runs on Glassfish, testing the patched app on Tomcat proves nothing.
OWASP ASVS v4.0.3 Requirement 14.2.3
"All components are up to date, preferably using a dependency checker during build or compile time."
Dependency checkers flag outdated versions. They don't flag architectural mismatches where a patched library still exposes a vulnerability through the server runtime. You need both automated scanning and architectural review.
NIST 800-53 Rev 5 Control SI-2
"Organization identifies, reports, and corrects system flaws" and "tests software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation."
That effectiveness testing is where most teams failed with Spring4Shell. You tested that the Spring update didn't break application functionality. Did you test that it actually closed the exploit path when deployed on Glassfish?
Lessons and Action Items for Your Team
Map Your Full Dependency Chain
Create a three-tier inventory:
- Application dependencies (Spring, Jackson, Log4j)
- Runtime dependencies (application servers, servlet containers)
- Infrastructure dependencies (JVM versions, OS libraries)
When a vulnerability drops, evaluate all three tiers. Spring4Shell taught us that a vulnerability in tier one can manifest through tier two, even after tier one is patched.
Test Patches in Production-Like Environments
Your development environment probably runs Spring Boot with an embedded Tomcat server. Your production environment runs on Glassfish behind a reverse proxy. Patch validation must happen in the production configuration, not the developer configuration.
Set up a staging environment that mirrors your production stack. When you patch a vulnerability, deploy the patch to staging and run the actual exploit code against it. If the exploit still works, you're not done patching.
Expand Your Vulnerability Intelligence Sources
You patched Spring4Shell when Spring announced it. You learned about the Glassfish vector when Snyk published their research. Between those two events, your systems were vulnerable, and you didn't know it.
Subscribe to security research from multiple sources—not just the upstream maintainer. For Java applications, that means following Snyk, Contrast Security, Veracode, and independent researchers who publish on GitHub and security mailing lists.
Update Your Patch Validation Checklist
After applying any security update, verify:
- The vulnerable component version is no longer present in build artifacts
- The exploit no longer succeeds in staging (run the actual PoC code)
- All application servers and runtimes in the deployment path have been evaluated
- Compensating controls (WAF rules, network segmentation) remain effective
For Spring4Shell specifically: Update spring-beans to version 5.3.18, 5.2.20, or later. Then verify that your application server (Glassfish, Payara, Tomcat, WildFly) doesn't reintroduce the vulnerability through its own class loading behavior. If you run Glassfish or Payara, check for server-specific patches beyond the Spring Framework update.
Treat Dependency Management as an Architectural Concern
Your build process manages application-level dependencies. Your architecture must manage runtime-level dependencies. That means documenting which servers run which applications, tracking server versions in your asset inventory, and including server updates in your patch management workflow.
When a framework vulnerability emerges, your incident response checklist should include: "Identify all servers that host applications using this framework." Not just "Identify all applications using this framework."
The Spring4Shell-on-Glassfish incident reveals a gap in how most teams think about vulnerability remediation. You can't patch a vulnerability by updating a single component when that vulnerability exists in the interaction between components. Your remediation scope must match the vulnerability's actual attack surface—even when that surface extends beyond the component named in the CVE.
