Spring4Shell rewarded hospitals that could size a response in hours

The week

In the last days of March 2022, hospital security teams started seeing a familiar kind of message: a new, serious flaw in widely used software, with a catchy nickname and screenshots of exploit code spreading online. Details of the flaw began circulating before any official advisory had been published.

The timing could hardly have been worse for tired teams. Log4Shell, the flaw in the Log4j logging library disclosed in December 2021, had consumed IT departments through the holidays. CISA, the federal Cybersecurity and Infrastructure Security Agency, had issued an emergency directive ordering federal civilian agencies to address it. In January, the Federal Trade Commission had warned companies that failing to fix Log4j could draw enforcement. Health systems had spent the same weeks coping with the Omicron surge. Many security staff had barely closed out their Log4Shell work.

Log4Shell had also left behind useful habits. Many software vendors had published status pages listing which of their products were affected and when fixes would ship. Many hospitals had built spreadsheets tracking which vendors had answered. Those tools were still fresh at the end of March, and the new flaw would show which organizations had kept them.

The software in question this time was the Spring Framework. Most executives will never see it, but a great deal of business software is built on it. Spring is a framework for the Java programming language, which means it is a large, shared set of ready-made building blocks that developers use so they do not have to write common features from scratch. Because so many applications share it, a flaw in it can turn up in many places at once.

The flaw was a remote code execution vulnerability. That is the most serious category: it means an attacker on the internet could, in the right conditions, make the target system run commands of the attacker’s choosing, as if they were sitting at its keyboard.

The Spring team later set out the sequence. Researchers at Ant Group reported the flaw to VMware, which maintained Spring, late on Tuesday, March 29. The team investigated and built a fix the next day, aiming for emergency releases on Thursday. On Wednesday, full details leaked online. Early chatter also tied the flaw to an unrelated code change in Spring, which added to the confusion.

On March 31, the Spring project published an early announcement and then fixed versions of the framework, 5.3.18 and 5.2.20, with matching Spring Boot releases. The flaw was given the official identifier CVE-2022-22965. The CVE system gives each publicly known security flaw a unique catalog number, so that everyone can be sure they are talking about the same thing. The flaw was soon nicknamed Spring4Shell, an echo of Log4Shell.

The details mattered. Exploitation required three conditions. The application had to run on JDK 9 or later, a version of the Java platform. It had to use Spring MVC or Spring WebFlux, two parts of the framework used for web applications. And, in the scenario first confirmed, it had to be packaged as a traditional WAR file deployed on Apache Tomcat, an older but still common way of installing Java web applications. Spring said applications using Spring Boot’s embedded server were not affected by the reported exploit, while cautioning that the flaw was more general and might be exploitable in other ways.

The announcement kept changing as facts firmed up. Spring revised its guidance on whether an application was affected on April 1 and again on April 4, each time stating the deployment requirements more clearly. It added Spring Boot releases that pulled in the fixed framework. Teams that read the first version and stopped there worked from an incomplete picture.

For organizations that could not upgrade at once, Spring listed stopgaps. The Tomcat project released new versions on April 1 that closed the known attack path from its side. Spring also described a configuration change that blocked the dangerous behavior, and noted that running on Java 8 avoided the flaw. Each was presented as a temporary measure, not a substitute for upgrading.

Then came the confusion. The same week, a separate flaw in a different project, Spring Cloud Function, was disclosed as CVE-2022-22963. That flaw affected the routing feature of Spring Cloud Function, where a specially crafted expression supplied by a user could lead to code execution. Early reports frequently mixed the two up. Some teams spent the first days unsure which bug they were chasing. Spring’s own announcement included a section on misconceptions to separate them.

On April 4, CISA added Spring4Shell to its catalog of known exploited vulnerabilities, its public list of flaws that attackers are confirmed to be using. Federal civilian agencies were given until April 25 to fix it. Within days, security researchers were also reporting attackers trying the flaw against exposed servers, which ended any debate about whether it would be used. With the flaw confirmed as real and in use, the question for every hospital became how much of the organization it actually touched.

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. Three triage decisions mattered: naming the flaw, testing the conditions and choosing the scale of mobilization. The two sections before them explain the flaw and the queue it landed on. The sections after them compare two hypothetical hospitals, set out why the work needs leadership, and describe the habits that keep a response proportionate.

A serious flaw with narrow conditions

Most modern business software is not written from a blank page. Developers assemble it from components: frameworks, libraries and tools that other people built and that many organizations share. This is efficient and, on the whole, makes software better, because widely used components are tested by many eyes. The trade-off is that when a widely used component has a flaw, the flaw is everywhere that component is.

Java is one of the most common programming languages in enterprise software, the kind of software that runs back-office and clinical operations. Spring is one of the most popular frameworks for building Java applications. A hospital may run dozens of Java applications without anyone in leadership knowing it: some built by its own developers, many more bought from vendors.

How the flaw worked

A remote code execution flaw is, roughly, a way to trick an application into treating data as instructions. It works like a receptionist who files written requests but will, if a request is worded in one particular way, follow it as an order from her manager. Most requests will never be worded that way, but anyone who learns the trick can walk up and use it.

Spring4Shell abused a convenience called data binding. When someone submits a web form, Spring copies each field onto the matching property of an object in the program, so a field called “name” fills in a name. Binding can follow a path of dotted names into nested objects. The feature is useful for complex forms, and it is also the opening.

Every Java object can describe its own class, and from there, in principle, reach deeper machinery that loads code. A 2010 Spring flaw had exploited exactly that path, and Spring had blocked it. Java 9 added a new language feature called modules, which created a second path to the same machinery. The old block did not cover it.

On Apache Tomcat, that machinery led to the server’s access log settings. By changing those settings through crafted form fields, an attacker could make Tomcat write a small file of their choosing into the web application’s folder. That file was a web shell, a page that runs whatever commands are sent to it. The attacker then visited it.

That chain explains the conditions. Java 8 lacked modules, so the second path did not exist. Applications packaged as standalone programs with an embedded server loaded code differently, so the known route to the log settings was absent. Only the combination of a newer Java, Spring’s web modules and a traditional deployment on Tomcat completed the chain that had been demonstrated.

Why the conditions were a guide, not a guarantee

Spring was careful to say that the flaw was more general than the demonstrated exploit. The conditions described the path attackers were known to use, not every possible path. On April 8, Spring noted a report of an additional attack path affecting two other Java servers, GlassFish and Payara. The sensible reading was to use the conditions to set priority, then upgrade every affected Spring version over the following weeks. Systems that met all the conditions came first. Systems that met only some came next, on a normal schedule, not never.

Why it was narrower than Log4Shell

The difference from Log4Shell matters most here. Log4Shell lived in a logging library, the component applications use to keep a diary of what they are doing. Almost every application logs things it receives from the outside world, such as usernames or web addresses. So with Log4Shell, an attacker could often trigger the flaw just by getting a crafted piece of text written to a log, which made an enormous number of systems reachable. Spring4Shell had no such shortcut. It required a specific stack of conditions to line up. That made it a real problem for some systems and no problem at all for many others.

The skill the moment called for was telling those apart, quickly.

The queue a new flaw lands on

Software flaws are discovered all the time. Most are found by researchers or by the makers themselves, fixed without fuss, and announced in an advisory, a short public notice that describes the problem, lists the affected versions and points to the fix. Each gets a CVE number. Tens of thousands are published every year.

No hospital can treat every one of them as urgent, and none should. The routine work of vulnerability management is sorting: reading the advisories that matter, matching them against what the hospital actually runs, and scheduling fixes in order of risk. Fixing usually means patching, which is installing an updated version of the software that closes the hole.

Scores, catalogs and who must follow them

Two public signals help with the sorting. The first is a severity score, usually under the Common Vulnerability Scoring System, which rates how bad a flaw would be if exploited. Spring4Shell scored at the top of the critical range. Severity scores describe potential, not likelihood, and many critical-rated flaws are never used by attackers.

The second signal is CISA’s Known Exploited Vulnerabilities catalog, launched in November 2021 under a binding operational directive. That directive requires federal civilian agencies to fix listed flaws by set dates. It does not bind private hospitals. The distinction matters in health care, because the sector includes federal providers, such as Department of Veterans Affairs medical centers and Indian Health Service facilities, alongside state university hospitals and private nonprofits. Only the first group was bound by the April 25 deadline. For everyone else, the catalog was useful evidence that a flaw was being exploited, and therefore a reason to move it up the queue.

Why patching in a hospital is slow

Patching in a hospital is harder than in most offices, for reasons leaders should understand:

• Clinical systems cannot simply be switched off. Updating a system often means restarting it, and a restart of a clinical application has to be planned around patient care, often at night or at weekends.
• Vendors must often approve the fix. For much clinical software, the hospital cannot install an update to an underlying component without the vendor confirming that its product still works properly with it. Waiting for that confirmation takes time.
• Testing takes people. Someone has to check that the lab results still flow, the orders still print and the interfaces still connect after the change.
• Not everything is visible. Components like Spring are buried inside applications. A hospital may not know it is using one until it asks.

Medical devices add their own layer. The FDA’s 2016 guidance on postmarket cybersecurity made clear that most cybersecurity updates to a device do not need new FDA review. Manufacturers still have to validate those updates, and hospitals generally should not patch a regulated device without the manufacturer’s instructions. A Java component inside a device’s management server can therefore wait on the manufacturer far longer than the same component on an ordinary web server.

Against that background, a flaw like Spring4Shell does not land on an empty desk. It lands on a team already working through a queue of routine fixes, planned upgrades and help-desk tickets. Every hour spent on a flaw that turns out not to apply is an hour taken from that queue. That is why the decisions below are about judgment as much as speed.

Two flaws, one nickname

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. Teams that acted on the first headlines risked hunting for the wrong component or applying the wrong fix.

Why the names collided

The collision had a simple cause. Spring is a family of projects, not a single product, and two of them had serious flaws disclosed within days. The Spring Cloud Function flaw was real and remotely exploitable, but it lived in a different component, used mainly in a different style of application, with its own fixed versions. A rumor linking the core flaw to an unrelated code change in Spring added a third thread. Each was reported with confidence by someone.

The two flaws also had different futures. Spring4Shell entered CISA’s exploited catalog within days. The Spring Cloud Function flaw was added in August 2022. A team that merged them in March would have had trouble later knowing which of its fixes answered which listing.

One identifier, one notice

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;
• when the next update will come.

Hospital IT spans many teams, from clinical applications and integration to research computing and biomedical engineering, the group that looks after connected medical devices. A single notice keeps them working on the same problem rather than on three different versions of it gathered from three different news feeds.

Reading an advisory well

An advisory is a living document. The useful parts are the affected versions, the conditions for exploitation, whether exploitation has been seen, the fixed versions, any workarounds and the revision history. Spring’s announcement changed several times in its first week. A triage notice should therefore record which revision of the advisory it relied on and when. When the advisory changes, the notice changes, and the teams working from it hear about the change from one place rather than from a colleague who happened to refresh the page.

The vendor channel

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.

A good request is short and specific. It names the identifier and asks whether the vendor’s product includes the affected component in an exploitable configuration. It asks for the version and date of any fix, and what the hospital should do in the meantime. It sets a response deadline. Asking the same four questions of every vendor makes the answers comparable in a spreadsheet, which is what a triage lead needs at the end of day two.

Checking each application against 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.

Finding out which applications met every condition required knowing how each one was built and installed.

In-house applications

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, which pass data between clinical systems; patient-facing portals; research platforms; and analytics pipelines built by internal teams or contractors. Three facts settle it for each:

• the Java version it runs on;
• the framework modules it uses;
• how it is packaged and deployed.

An application inventory that records those facts turns a day of calls into a query. Without it, someone has to track down the developer who built the portal three years ago, who may have moved on.

Integration engines first

In a hospital, the integration engine deserves early attention. It is the system that passes orders, results, admissions and billing messages between clinical applications, using standards such as HL7. Several widely used health care integration engines run on Java, and their web consoles are sometimes reachable from more of the network than they should be. An integration engine also connects to almost everything else, so a compromise there spreads quickly. Checking it first is a matter of exposure, not of probability.

Finding what the inventory misses

Inventories are never complete, so teams also search. Software composition analysis tools read an application’s list of dependencies and flag vulnerable versions. File system scans look for the Spring library files on servers, including inside packaged applications where they are nested one level down. Network scanners can send a harmless test request to web applications and look for the telltale response. Each method misses something. Used together for a day, they give a triage lead enough confidence to say where the exposure is.

Vendor software

Commercial software was the larger share. Clinical, laboratory, imaging, revenue cycle and supply chain systems often run on Java. Hospitals cannot inspect the inside of most vendor software, so they depend on the vendor to say whether it is affected. 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.

When the fix cannot come quickly

Where an exposed system could not be patched at once, the stopgaps mattered. Upgrading Tomcat closed the demonstrated path without touching the application. A web application firewall rule could block requests containing the dangerous field names. Restricting the application to the internal network cut off attackers on the internet. Each choice needed an owner and an expiry date, so that a temporary measure did not become permanent by neglect.

Hosted and cloud services

A growing share of hospital software runs as a service, hosted by the vendor. For those systems, the vendor patches its own servers, and the hospital cannot see or touch the component at all. The hospital’s job changes from fixing to asking and recording. The standard request still applies, with one more question: when was the service patched, and did the vendor find any sign of exploitation before then. A vendor-hosted electronic health record or revenue cycle platform deserves the same follow-up as software in the hospital’s own data center, because the patient data and the operational dependence are the same.

Differences by type of organization

The balance of in-house and vendor work varied. An academic medical center with research computing and a development team had more in-house Java to check. An ambulatory network running mostly cloud services had little to inspect itself and depended almost entirely on vendor answers. A life sciences company had the hardest patching path. Its validated systems, those used for regulated laboratory or manufacturing work, often require documented testing before any change. That made accurate scoping more valuable, because each unnecessary change carried a validation cost.

How many people to call in

The third decision was how many people to involve. A defined triage function makes this possible. Triage here means what it means in an emergency department: a quick, structured assessment that decides who needs attention now, who can wait and who does not need treatment at all.

Written criteria

A small group assesses each newly reported vulnerability against set criteria:

• evidence of exploitation in the wild;
• presence in the hospital’s own estate;
• exposure to the internet and to clinical operations;
• the availability of a fix or mitigation.

Only when those criteria are met does the response widen into an incident with broad mobilization.

Many teams find three tiers enough. A watch tier means the group tracks the advisory and checks the inventory, with no wider action. A focused tier means named teams patch or mitigate specific systems on a set timeline. An incident tier opens the security incident process, with broad mobilization and executive updates. Spring4Shell, for most hospitals, belonged in the focused tier once the conditions had been checked.

Federal and public hospitals

For a Veterans Affairs medical center or an Indian Health Service facility, the tier decision had a fixed outer edge: the April 25 deadline from CISA’s catalog applied to federal civilian agencies. Triage still mattered, because it decided which systems to fix first, but it could not decide that the deadline did not apply. A county or state university hospital was not bound by that directive. It should check whether its own state or parent institution sets patching deadlines, and record which rule it is following.

Decision rights

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.

The decision right should belong to a role, not a person, with a named deputy. It should also have an explicit override: the chief information security officer or chief information officer can always escalate a tier. What they should not do is skip the triage step and escalate on a headline.

Communication and the record

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 HIPAA Security Rule requires covered entities to assess risks and manage them to a reasonable and appropriate level. A triage record is one of the clearest pieces of evidence that a hospital does so for software flaws. It shows the flaw was considered, the exposure was checked and the response was proportionate.

What a good update says

A useful leadership update fits on a phone screen. It names the flaw by identifier, states the current tier, and gives what has been checked and what has not. It lists any systems found exposed, with their mitigation and owner, and says when the next update will come. It also says what would change the tier, such as a vendor confirming exposure in a clinical system. Executives who receive that note twice a day rarely ask for an all-hands meeting.

The risk of setting the bar too high

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.

Two hospitals, one week

Suppose two health systems face the same headlines.

The first has a small vulnerability triage group of three people. On the first morning, its lead sends a one-paragraph notice: the hospital is tracking CVE-2022-22965 from the Spring project’s advisory; the conditions are as published; the separate Spring Cloud Function issue is being tracked under its own number; next update at 4 p.m. The application team queries its inventory and finds a handful of in-house Java applications, only one of which is packaged the vulnerable way. That one is moved behind the firewall the same day and patched within the week. The vendor team sends its standard request, citing the identifier, to its critical vendor list with a three-day deadline. Two vendors are slow; both are escalated. The chief information officer tells the executive team it is a focused response and explains why. Most staff never hear about it.

The second has no defined triage function. Its chief executive reads about “the next Log4Shell” in the morning news and asks for an all-hands response. Teams search for “Spring” across systems without agreeing which flaw they are looking for. Some vendors are asked about Spring4Shell, others about the Spring Cloud Function flaw, and the answers cannot be compared. Planned work on a clinical upgrade slips by two weeks. By the end of the week, the second hospital is probably safe too, but it has spent far more to get there, and its staff are more tired heading into whatever comes next.

A month later, the difference compounds. The first hospital’s triage record shows what was checked and why, and its vendor spreadsheet shows which answers are still outstanding. The second hospital has a pile of email threads and a vague sense that everything was fine. When an auditor or a board member asks what happened, only one of them can answer in a page.

Neither hospital was reckless. The difference was preparation.

A technical discipline that needs leadership

Vulnerability management can sound purely technical. Spring4Shell showed its leadership side.

Staff are the scarcest resource. Hospital IT and security teams are small relative to what they support, and the people who respond to security alerts are often the same people who keep clinical systems running. Every unnecessary emergency borrows from that pool.

Over-reaction and under-reaction both cost money. Under-reaction risks a breach. Over-reaction burns overtime, delays projects that have their own clinical and financial value, and erodes the credibility of the next warning.

Regulators and auditors look for reasoning. A documented triage decision, made by a named person on stated evidence, is far easier to defend than either “we panicked” or “we assumed it didn’t apply.”

Vendors are part of the attack surface. Most of a hospital’s exposure is in software it bought. The ability to get clear, comparable answers from vendors quickly is a capability, and it decays if not maintained.

The case for over-reacting

The strongest counter-argument deserves a hearing. A ransomware attack can cost a hospital weeks of disrupted care and very large recovery costs. A week of overtime costs far less. On that arithmetic, mobilizing everyone for every serious flaw looks cheap insurance.

The argument holds where the hospital cannot see its own estate. If there is no inventory and no vendor process, a broad search may be the only way to be sure. It fails where the hospital can see, because broad mobilization then adds cost without adding safety. It also has a hidden price. Teams that are mobilized for every headline learn to discount headlines, and the response to the flaw that really matters gets slower. The better answer to uncertainty is faster scoping, not a bigger crowd.

Workforce strain

The people cost is easy to underestimate. Each emergency pulls engineers into night and weekend work, on top of on-call rotations that already cover clinical systems. Recovery time is rarely scheduled afterward. Turnover in specialist security and infrastructure roles is expensive for hospitals, which often cannot match the pay offered elsewhere. A leader who spends that workforce on a flaw that did not apply makes the next hiring and retention problem worse, as well as the next response slower.

Funding the capability

Triage capacity rarely has its own budget line. It is usually a fraction of several people’s time, and it erodes when projects press. Leaders who want proportionate responses need to protect that time, fund the inventory work that makes scoping fast, and accept that the payoff is mostly invisible: crises that never became crises.

The cheapest place to fund it is inside work already budgeted. Application onboarding can require build and deployment details before a new system goes live. Vendor contracts can require security advisories to be sent to a named hospital mailbox, with a response time for questions about specific identifiers. Annual application reviews can confirm that each owner is still in post. Each of those steps costs minutes when done routinely and days when done in a hurry.

Keeping the response proportionate

The habits that help are not exotic:

• a small, named triage group with written criteria for escalation;
• an application inventory that records, for each system, who owns it, what it is built on and how it is deployed;
• a standing vendor request process with a contact list, a template, deadlines and escalation;
• a habit of short, scheduled leadership updates during any security event;
• a brief review after each event, adjusting the criteria if they proved wrong.

Measures that show it is working

A few measures show whether the habits are real. The time from public disclosure to a recorded triage decision. The share of in-house applications with complete build and deployment records. The share of critical vendors that answered a standard request within the deadline. The overtime hours spent on security events, split by whether the event turned out to affect the hospital. No new tool is needed for any of them. Each can be pulled from records the triage group should already keep.

The after-action review

A short review after each significant flaw keeps the process improving. Thirty minutes is usually enough. The group asks how long each step took, where the inventory was wrong or silent, which vendors answered late or vaguely, whether the tier was right in hindsight, and what to change. The output is a few concrete fixes with owners, such as adding missing build details for two applications or escalating a vendor at the next contract review. Over a year, those small fixes are what make the next triage faster.

How teams go wrong

• Acting on the nickname. Headlines arrive before facts. The official identifier and advisory are what matter.
• Letting the Log4Shell muscle waste away. Processes built in a crisis often dissolve when the crisis ends. They are cheapest to keep running.
• Executive escalation by headline. When a leader declares an emergency because of a news story, the triage function is overruled before it can work.
• No record of decisions not to act. A decision to keep a response small is still a decision and should be written down.
• Temporary fixes with no expiry. A firewall rule or configuration change that stands in for a patch needs a date by which the patch replaces it.

Who decides how big the response is

• When a new major flaw is announced, who decides how big our response should be? Do they have written criteria?
• Could we list, within a day, every application we run that uses a given component, including vendor products?
• Do we still run the vendor request process we built for Log4Shell, or did it lapse?
• When we ask vendors whether they are affected, do we cite the official identifier?
• How much unplanned overtime did security events cost us last year, and how much of it was for issues that turned out not to affect us?

The answers lead to further checks. One is whether the inventory records how each in-house application is built and deployed, and who owns it. Another is how an executive would know that a decision to keep a response focused was made on evidence. A third is whether anyone reviewed the last security event, what went right and wrong, and changed something as a result. A team that can answer all of these in a morning is ready for the next nickname.

With hindsight

Spring4Shell was exploited in the wild. Within days of disclosure, security researchers documented attackers using it to install malware, including a variant of the Mirai botnet, which takes over large numbers of machines and uses them together. It stayed on lists of vulnerabilities to patch. It never approached the scale or persistence of Log4Shell. The systems it did reach were the ones that met its conditions and were left unpatched, which is exactly the group careful triage was designed to find first.

The aftershocks were small and technical. Spring published a follow-up advisory in mid-April 2022 about a weakness in the configuration workaround it had suggested. Researchers also found that the flaw could be exploited on some other Java servers besides Tomcat. Teams that had relied on stopgaps rather than upgrades had to revisit them, which is the usual cost of a temporary fix.

That outcome, in hindsight, vindicates the hospitals that sized their response carefully. The flaw was real and deserved attention where the conditions were met. It did not deserve to consume entire IT departments for weeks, and the teams that recognized that quickly spent their energy where it counted.

Its main legacy was procedural. It showed that the vendor tracking workflows and application inventories built after Log4Shell had lasting value. They were not one-time crisis tools but standing capabilities, worth funding and keeping current. It also showed that hospitals needed a way to tell a contained issue from a systemic one within hours.

Policy moved in the same direction. The Cyber Safety Review Board’s report on Log4j, published in July 2022, described that flaw as endemic and expected vulnerable versions to linger for years. Legislation enacted in December 2022 required makers of networked medical devices to give the FDA a software bill of materials, a list of the components inside, for new device submissions from March 2023. That gave hospitals a better starting point for asking whether a device contains a given component. HHS published voluntary cybersecurity performance goals for the health sector in January 2024, including the mitigation of known vulnerabilities. In January 2025, HHS proposed revisions to the HIPAA Security Rule that would set patching deadlines, including 15 days for critical risks, but the proposal was still not final in October 2026.

The public infrastructure for tracking flaws proved more fragile than many assumed. From early 2024, the National Vulnerability Database fell well behind in analyzing new entries. In April 2025, the contract under which MITRE runs the CVE program came close to lapsing before CISA extended it. Teams that relied on a single feed found they needed vendor advisories and the exploited catalog as well.

Spring itself kept moving, and so did its owner: Broadcom completed its acquisition of VMware in November 2023, and Spring came with it. Open source support for the Spring Framework 5.3 line, the version most affected applications ran in 2022, ended in August 2024. Applications still on it now depend on commercial support or an upgrade for future fixes, which turns the inventory question from 2022 into a lifecycle question.

The pattern of confused early reporting, competing nicknames and premature alarm repeated with later disclosures. Expect it to continue. The first day of any major vulnerability story will be noisy, and some of what is said will be wrong. The organizations that cope best are the ones that do not need the noise to settle before they can act, because they know what to check and whom to ask.

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.

A security team deserves to be judged on how well it decides which crises are real, as much as on how hard it works in one.