cve-2026-47890

Overview

Spring Framework is a widely used application framework for the Java platform that provides the core programming and configuration model for modern Java enterprise applications, including the Spring MVC servlet web stack and the reactive Spring WebFlux web stack. Since Spring Framework 6.2 both web stacks can render a stream of view fragments, such as HTML snippets produced by a template engine, and deliver them to the browser as Server-Sent Events (SSE), a line-oriented text protocol in which each rendered fragment travels in one or more data: lines of the event stream.

A content spoofing vulnerability (CVE-2026-47890) has been identified in the SSE view fragment rendering of Spring MVC and Spring WebFlux, which allows attackers to corrupt the event stream delivered to other users of the application. When data that an attacker controls is rendered into a fragment and contains a bare carriage return, the rendered output breaks out of its data: field and the remainder is interpreted by the browser as new SSE fields. Depending on the frontend application logic, this can corrupt client-side state or present malicious information to other users.

This is the weakness MITRE catalogues as CWE-93, where the product uses CRLF (carriage return line feeds) as a special element, e.g. to separate lines or records, but it does not neutralize or incorrectly neutralizes CRLF sequences from inputs.

The advisory rates this vulnerability Low severity with the CVSS v3.1 vector AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:L/A:N, which corresponds to a base score of 2.6. The attack vector is Network, attack complexity is High because the application must stream view fragments over SSE and the attacker's data must reach a rendered fragment unchanged, Low privileges are required because the attacker needs to be able to submit data that the application streams to other users, user interaction is Required because the victims must be connected to the stream, and the impact is Integrity-only and Low because the consequence is injected or corrupted event data in other users' streams rather than access to data held by the application.

This issue affects Spring Framework >=6.2.0 <=6.2.19 and >=7.0.0 <=7.0.8, including the End-of-Life 6.2.x line supported by NES for Spring Framework.

‍

Details

Module Info

• Product: Spring Framework
• Affected packages: org.springframework:spring-webmvc, org.springframework:spring-webflux
• Affected versions: >=6.2.0 <=6.2.19, >=7.0.0 <=7.0.8
• GitHub repository: https://github.com/spring-projects/spring-framework
• Published packages: https://central.sonatype.com/artifact/org.springframework/spring-webmvc, https://central.sonatype.com/artifact/org.springframework/spring-webflux
• Package manager: Maven
• Fixed in:
  • NES for Spring Framework nes-v6.2.21
  • Spring Framework 7.0.9 (OSS)

Vulnerability Info

This Low-severity vulnerability is found in the spring-webmvc and spring-webflux packages in multiple versions of Spring Framework, and is reached only by applications that stream view fragments over Server-Sent Events. In Spring MVC that means a controller that returns an SseEmitter or ResponseBodyEmitter and sends ModelAndView objects through it, or that returns a Flux<Fragment> with a text/event-stream content type. In Spring WebFlux it means a controller that returns a Flux<Fragment> or Flux<ServerSentEvent<Fragment>>. Plain SSE payloads such as SseEmitter.send(String) or ServerSentEvent<String> are not affected, because those paths already escape carriage returns.

The SSE wire format terminates a line on a line feed, a carriage return, or the two together, and a rendered fragment that spans several lines must therefore have every line prefixed with data: so that the browser reassembles it as one event. In Spring MVC, the fragment is rendered into an in-memory FragmentHttpServletResponse, and its getFragmentContent() method prepares the rendered text for the stream by replacing line feeds only:

public byte[] getFragmentContent() {
    this.writer.flush();
    String content = this.outputStream.toString(this.charset);
    content = content.replace("\n", "\ndata:");
    return content.getBytes(this.charset);
}

The Spring WebFlux counterpart in ViewResolutionResultHandler writes an event: and data: prefix, then the rendered fragment, then the blank line that ends the event, and applies the same line-feed-only replacement to the fragment text:

Mono<DataBuffer> content = DataBufferUtils.join(fragmentFlux)
        .map(buffer -> {
            String text;
            try {
                text = buffer.toString(charset);
            }
            finally {
                DataBufferUtils.release(buffer);
            }
            text = text.replace("\n", "\ndata:");
            return bufferFactory.wrap(text.getBytes(charset));
        });

return Flux.concat(Flux.just(prefix), content, Flux.just(suffix));

A bare carriage return in the rendered fragment is left untouched by both methods. The browser's event source parser treats it as the end of the current data: line, so whatever follows the carriage return is parsed as a fresh SSE field. An attacker who can get a value containing a carriage return into the model, for example through a chat message or display name that the fragment template renders, can therefore append their own data:, event:, id:, or retry: lines to the event that every connected user receives. HTML escaping performed by the template engine does not help, because a carriage return is not an HTML-significant character and is emitted as-is.

This vulnerability was introduced in 2024 with Spring Framework 6.2.0.

‍

Mitigation

Only recent versions of Spring Framework receive community support. The 6.2.x line is End-of-Life and will not receive public updates to address this issue, so there is no publicly available fix for that line other than through a commercial support partner.

Users of the affected components should apply one of the following mitigations:

• Upgrade to a currently supported version of Spring Framework. The open-source fix ships in Spring Framework 7.0.9 on the 7.0.x line.
• Leverage a commercial support partner like HeroDevs for post-EOL security support, which provides the fix for the 6.2.x line in nes-v6.2.21.

‍

Credits

• No public finder credit is listed in the advisory sources checked for this entry.