CVE-2026-59313: Spring Framework Server-Sent Events Injection, Scored 9.8 Critical

One of the things those handlers can return is a Server-Sent Events (SSE) stream, a long-lived HTTP response that pushes a sequence of named events to the browser. CVE-2026-59313 lives in exactly that path.

‍

The flaw is a Server-Sent Events injection. When an application streams attacker-influenced text through ServerResponse.sse(...), a bare carriage return in that text is written to the response verbatim. Browsers treat a carriage return as an end-of-line inside the SSE protocol, so everything after it is parsed as new SSE fields rather than as data. An attacker who can get their text into the stream can forge or truncate events in another user's event stream, corrupting what the client application receives and acts on. It is a content-integrity problem in the data other users see, not remote code execution and not a server-side data breach.

‍

Here is the part that is generating confusion and traffic: the severity depends on where you look. Spring, the maintainer and CVE assigning authority, rates this Low. The CVE record carries a 9.8 Critical, and that is the number your scanner is almost certainly showing you. The fix is straightforward if you are on a supported branch and it is 7.0.9. If you are on Spring Framework 5.3, 6.0, 6.1, or 6.2, the free fix is not available in your branch, and that is where this stops being a quick patch. Herodevs has you covered!

‍

TL;DR

‍

Who is affected

CVE-2026-59313 affects five Spring Framework branches. The only branch that receives a free open source fix is 7.0.x. For every branch below it, the fix ships only through Commercial Support Only releases, which is the detail that turns a one-line version bump into a real decision.

The vulnerable code sits in spring-webmvc. Spring Framework is pulled in by nearly every Spring Boot application and by a long list of enterprise platform modules and shared BOMs, so an affected version can be present without an explicit declaration in your own build file. Run your SCA tool against the full dependency tree to find the resolved org.springframework:spring-webmvc version rather than trusting your direct dependencies alone.

‍

Exposure narrows sharply after that. The issue is specific to the functional web framework returning an SSE stream through ServerResponse.sse(...) where the streamed values carry attacker-influenced text. Applications that return JSON over SSE, that use annotated controllers with SseEmitter, or that use WebFlux for their reactive SSE endpoints are not affected by this CVE.

‍

Technical detail

The root cause in plain English. Server-Sent Events is a line-oriented text protocol. Each field in an event is written as field:value and events are separated by blank lines. The browser's EventSource parser treats both a line feed and a carriage return as line terminators. Spring's functional SSE writer placed the value you handed it into the data: field without neutralizing a bare carriage return inside that value. So if attacker-influenced text contains a \r, the browser stops reading your data: field at the carriage return and interprets whatever follows as new SSE fields.

‍

In practice that means an attacker who can land text into the stream can inject a forged event or cut a legitimate one short. Consider a notifications endpoint that streams a display name the attacker controls:

// Attacker-controlled value contains a bare carriage return:
name = "Alice\revent: balanceUpdate\rdata: {\"amount\":\"0\"}"

‍

Written into the SSE stream, the browser sees the carriage returns as line breaks, closes the intended data: field, and parses event: balanceUpdate and its data: as a brand new event. The client application dispatches a balanceUpdate that the server never sent. The corruption lands in whichever user's stream the text reaches, which is why this is an integrity issue against clients rather than a server compromise.

‍

CWE-93, CRLF injection. This is the same class of bug as HTTP response splitting, applied to the SSE framing instead of HTTP headers. The fix neutralizes line separators in SSE field values so the value can no longer break out of its field.

‍

The severity split, and why it is real. Spring published a CVSS vector rating the issue Low (2.6): high attack complexity, privileges required, user interaction required, no confidentiality impact, low integrity impact, no availability impact. That vector matches what the code actually does. Spring did not, however, carry a CVSS score into the CVE record itself. When a CVE record is published without a score from the assigning authority, the CISA ADP (Authorized Data Publisher) program can add one, and that assessment scored it 9.8 Critical with worst-case assumptions: no privileges, no user interaction, and full confidentiality, integrity, and availability impact. The ADP score is the one NVD surfaces and the one your scanner ingests. Neither number is a typo. They are two different bodies scoring the same record with different inputs, and the gap between them is the whole reason this CVE is getting attention.

‍

How to confirm exposure

• Use your SCA tool to find the resolved org.springframework:spring-webmvc version across your dependency tree, not just your direct dependencies.
• Confirm your application uses the functional web framework (WebMvc.fn) and returns an SSE stream through ServerResponse.sse(...).
• Confirm the streamed values include text that can be influenced by user input. If your SSE payloads are server-generated JSON with no attacker-controlled text, the practical risk is lower, but the scanner finding on the affected version will remain until you move to a fixed build.

‍

Remediation

If you are on a supported Spring Framework version

Upgrade to 7.0.9. That is the open source fix, the community maintains the 7.0.x branch, and the release is available now. If you are on 7.0.0 through 7.0.8, this is a patch-level move and the right answer for any team that can take it.

‍

If you are on an older branch, be honest with yourself about the size of the jump. Moving from Spring Framework 5.3 to 7.0 crosses the javax.* to jakarta.* namespace boundary and a major-version migration, which is a multi-sprint project, not a hotfix. Moving from 6.x to 7.0 is a major upgrade with its own API and baseline changes. The in-branch fixes for 5.3.x, 6.0.x, 6.1.x, and 6.2.x exist, but they are Commercial Support Only releases, so they are not something an open source consumer can simply pull from Maven Central.

If you are running EOL Spring Framework 5.3.x, 6.1.x, or 6.2.x

If upgrading to 7.0.9 is not feasible on your current timeline, HeroDevs Never-Ending Support (NES) provides a remediated package designed to address CVE-2026-59313 at the original Maven coordinates. NES for Spring covers the EOL 5.3.x, 6.1.x, and 6.2.x branches, and the fix ships in NES builds 5.3.39-spring-framework-5.3.54, 6.1.21-spring-framework-6.1.30, and 6.2.19-spring-framework-6.2.21, all released August 25, 2026. It is designed as a drop-in replacement requiring minimal or no code changes in most environments, so it closes the scanner finding without the namespace migration. Learn about NES for Spring.

‍

FAQ

Which versions are affected?

Spring Framework 5.3.0 through 5.3.49, 6.0.0 through 6.0.30, 6.1.0 through 6.1.28, 6.2.0 through 6.2.19, and 7.0.0 through 7.0.8. The vulnerable code is in spring-webmvc, in the functional web framework's SSE support.

Why does my scanner show this as 9.8 Critical when Spring rates it Low?

Because two different bodies scored it. Spring rated it Low (2.6) but did not put a score in the CVE record. The CISA ADP program then added a 9.8 Critical assessment using worst-case assumptions, and that is the score NVD displays and scanners ingest. The 9.8 reflects a conservative default, not a finding that the bug allows full system compromise. What the code actually permits is Server-Sent Events injection against clients, an integrity issue.

Is Spring Framework 7.0 affected?

Yes. Versions 7.0.0 through 7.0.8 are affected, and the fix is 7.0.9. This is the one branch where the fix is a free open source release.

Is there a public OSS fix?

Only on 7.0.x, in 7.0.9. For 5.3.x, 6.0.x, 6.1.x, and 6.2.x the in-branch fix is a Commercial Support Only release, so open source consumers on those branches do not get a free in-branch patch.

I am on Spring Framework 5.3, 6.1, or 6.2. Is upgrading within my branch sufficient?

The in-branch fix closes this specific CVE, but it is a Commercial Support Only release and the branch has no ongoing open source security support, so the next CVE in that branch repeats this situation. HeroDevs NES covers the EOL 5.3.x, 6.1.x, and 6.2.x branches and resolves this finding and future ones at the original coordinates. The long-term open source path remains 7.0.x.

How does this affect SOC 2 or PCI DSS compliance?

Your scanner is reading the 9.8 Critical from the CVE record, so this lands as a Critical finding in your vulnerability management program regardless of the severity debate. Under SOC 2 CC7.1 and PCI DSS requirement 6, a Critical finding on an in-scope system carries a remediation SLA. You either move to a fixed build or you carry an accepted-risk exception with justification. The score on the record, not the maintainer's Low rating, is what the audit sees.

‍

Taking action

CVE-2026-59313 is a narrow, client-side integrity bug that your scanner is reporting as a 9.8 Critical, and both of those statements are true at the same time. If you are on 7.0.x, upgrade to 7.0.9 and you are done. If you are on 5.3.x, 6.0.x, 6.1.x, or 6.2.x, the free fix is not in your branch, and reaching 7.0.9 means a major-version upgrade, in some cases across the javax.* to jakarta.* boundary.

‍

For the EOL branches, there is no free in-branch remediation, so any exposed deployment keeps failing the scan until it moves to a fixed build. HeroDevs NES delivers a remediated package for the EOL 5.3.x, 6.1.x, and 6.2.x branches at the original Maven coordinates, closing the finding. If you need to clear this Critical in your scanner now and a major-version migration is not on this quarter's plan, that is the path. See NES for Spring and the HeroDevs Vulnerability Directory entry for CVE-2026-59313.

‍

Related:

• Spring security advisory: spring.io/security/cve-2026-59313
• HeroDevs Vulnerability Directory: CVE-2026-59313
• Spring Framework Release Notes