Spring4Shell rewarded hospitals that could size a response in hours

The week

In the last days of March 2022, details of a remote code execution flaw in the Spring Framework, a widely used Java application framework, began circulating online before an official advisory. On March 31, the Spring project published an advisory for CVE-2022-22965, soon nicknamed Spring4Shell, with fixed versions. Exploitation required specific conditions: an application running on JDK 9 or later, using Spring MVC or Spring WebFlux, and, in the scenario first confirmed, packaged as a traditional WAR file deployed on Apache Tomcat. The same week, a separate flaw in a different project, Spring Cloud Function, was disclosed as CVE-2022-22963, and early reports frequently mixed the two up. CISA added Spring4Shell to its catalog of known exploited vulnerabilities on April 4.

The nickname invited comparison with Log4Shell, and for a few days many organizations prepared for a repeat of December 2021. Security teams were pulled in, vendors were asked for statements and executives asked whether the hospital was exposed. The reality was narrower. The flaw was serious, but its conditions limited the number of vulnerable systems, and unlike Log4Shell it could not be triggered by any string that reached a log. Health system IT and security staff had worked through the holidays on Log4Shell and then through the Omicron surge. A second all-hands response, if not warranted, would spend energy needed for the next real crisis. The episode rewarded teams that could size a response quickly and accurately. We look at three triage decisions: naming the flaw, testing the conditions and choosing the scale of mobilization.

Naming the flaw

The first problem was knowing what was being discussed. In the first days, social media posts, blogs and news reports used similar names for at least two different Spring issues, and some mixed in an older, unrelated report. Teams that acted on the first headlines risked hunting for the wrong component or applying the wrong fix.

The discipline is to track issues by official identifier and authoritative source, usually the project’s own advisory, which typically arrives within a day of public chatter. A short internal notice helps more than speed. It should state which identifier the hospital is tracking, which sources it relies on, what is known about exploit conditions and when the next update will come. Hospital IT spans many teams, from clinical applications and integration to research computing and biomedical engineering, and a single notice keeps them working on the same problem.

Naming also covers the vendor channel. Requests to suppliers should cite the identifier, not the nickname, so that answers can be matched and compared. A vendor statement that says “not affected by Spring4Shell” without naming the identifier is ambiguous when two issues share a name.

Testing the conditions

The second decision was to apply the exploit conditions. Spring4Shell needed a particular range of Java versions, particular Spring modules and, in the confirmed case, a particular deployment model. Many Spring applications did not meet all of them. Applications packaged as standalone executables with an embedded server, a common modern pattern, were not exposed to the known exploit path, though upgrading was still advisable.

Testing conditions needs build and deployment facts. For in-house software, development teams could usually answer quickly if someone knew who owned each application. Health systems have fewer in-house Java applications than banks, but they often run integration services, patient-facing portals, research platforms and analytics pipelines built by internal teams or contractors. The questions to answer for each are short: which Java version, which framework modules, and how it is packaged and deployed. An application inventory that records those facts turns a day of calls into a query.

Commercial software was the larger share. Clinical, laboratory, imaging, revenue cycle and supply chain systems often run on Java. Log4Shell had pushed many vendors to publish advisories quickly, and Spring4Shell tested whether that held. The workflow many health systems had built in December could be reused: a tracking list of critical vendors, a standard request citing the identifier, a response deadline and escalation for silence. Teams that kept that workflow as a standing process ran it again in hours. Those that had let it lapse rebuilt it under pressure.

Choosing the scale of mobilization

The third decision was how many people to involve. A defined triage function makes this possible. A small group assesses each newly reported vulnerability against set criteria: evidence of exploitation, presence in the estate, exposure to the internet and to clinical operations, and the availability of a fix or mitigation. Only when those criteria are met does the response widen into an incident with broad mobilization.

That requires clear decision rights. Someone must be able to say “this is a focused response” and have executives accept it. Leaders who resisted pressure to declare an emergency on the strength of a nickname protected their teams. Those who mobilized everyone by default spent overtime, deferred project work and goodwill. Many of the same people were also covering staffing gaps elsewhere, and repeated false alarms make staff slower to respond when an alert is real.

Measured response depends on trust, and trust depends on communication. Short, regular updates to leadership, stating what is known, what is being done and what would change the assessment, let executives accept a smaller response without feeling uninformed. A written triage record also shows auditors and regulators that the decision not to escalate was made deliberately, on evidence, by a named person.

The trade-off is real. A triage group that sets thresholds too high will one day under-react. Reviewing each triage decision after the fact, and adjusting criteria when one proves wrong, keeps the process honest.

With hindsight

Spring4Shell was exploited in the wild, including by botnet operators, and it stayed on lists of vulnerabilities to patch. It never approached the scale or persistence of Log4Shell. Its main legacy was procedural. It showed that the vendor tracking workflows and application inventories built after Log4Shell had lasting value. It also showed that hospitals needed a way to tell a contained issue from a systemic one within hours. The pattern of confused early reporting, competing nicknames and premature alarm repeated with later disclosures. By this point in 2026, health systems with mature vulnerability management run triage as a defined function, with escalation criteria, standard vendor requests and short leadership updates. Staffing pressure on health system IT and security teams has not eased much since 2022, which makes accurate sizing of each response more valuable, not less.