CVE-2026-47888: Spring Framework RSocket DOS Vulnerability

CVE-2026-47888 Overview

CVE-2026-47888 is a memory leak vulnerability affecting Spring Framework applications that use RSocket. A remote attacker can send a malformed SETUP frame to trigger unbounded memory consumption on the server. Repeated exploitation exhausts heap memory and degrades application availability, resulting in a denial-of-service condition.

The issue affects multiple Spring Framework branches, including versions 7.0.0–7.0.8, 6.2.0–6.2.19, 6.1.0–6.1.28, 6.0.0–6.0.30, 5.3.0–5.3.49, and 5.2.0.RELEASE–5.2.25.RELEASE. Applications exposing RSocket endpoints to untrusted networks face the greatest risk.

Critical Impact
Attackers can remotely exhaust JVM heap memory in Spring RSocket applications by sending crafted SETUP frames, causing service degradation or crash without authentication.

Affected Products

Spring Framework 7.0.0 through 7.0.8 and 6.2.0 through 6.2.19
Spring Framework 6.1.0 through 6.1.28 and 6.0.0 through 6.0.30
Spring Framework 5.3.0 through 5.3.49 and 5.2.0.RELEASE through 5.2.25.RELEASE

Discovery Timeline

2026-08-27 - CVE-2026-47888 published to NVD
2026-08-27 - Last updated in NVD database

Technical Details for CVE-2026-47888

Vulnerability Analysis

RSocket is a binary application protocol that supports Reactive Streams semantics over TCP, WebSocket, and other transports. The connection lifecycle begins when a client sends a SETUP frame to negotiate protocol parameters, metadata format, and payload format.

Spring Framework integrates RSocket through the spring-messaging module, which parses and dispatches incoming frames. The vulnerability arises when the SETUP frame is malformed. The framework fails to release buffers or associated state allocated during parsing, causing memory to accumulate over successive malicious connections.

Because SETUP frame processing occurs before application-level authentication, an unauthenticated remote attacker can trigger the leak. Each malformed frame incrementally consumes heap resources, ultimately producing an OutOfMemoryError that impacts availability.

Root Cause

The root cause is improper resource cleanup along the error path when a SETUP frame fails validation. Reference-counted buffers allocated for frame decoding are not released, and connection-scoped objects remain reachable after the setup exchange aborts. This matches the pattern of a Memory Leak weakness in reactive network protocol handlers.

Attack Vector

Exploitation requires only network reachability to the RSocket endpoint. The attacker opens a transport connection, sends a syntactically invalid or semantically inconsistent SETUP frame, and closes the connection. Repeating this pattern from one or more sources drives memory pressure until the JVM can no longer service legitimate requests. See the Spring Security Advisory CVE-2026-47888 for vendor-provided technical detail.

Detection Methods for CVE-2026-47888

Indicators of Compromise

Repeated short-lived RSocket connections from a limited set of source addresses to the RSocket port
JVM heap growth without a corresponding increase in legitimate application throughput
OutOfMemoryError events or frequent full garbage collection cycles in application logs
Parser or decoder warnings referencing invalid SETUP frames in spring-messaging logs

Detection Strategies

Monitor RSocket transport logs for elevated rates of failed SETUP negotiations and correlate with source IPs
Track JVM metrics such as heap used, GC pause time, and buffer pool usage for anomalous trends
Alert on Netty ByteBuf leak detector warnings when leak detection is enabled at PARANOID or ADVANCED level

Monitoring Recommendations

Export application metrics with Micrometer and set thresholds on heap saturation and GC overhead
Capture heap dumps when memory thresholds trigger and inspect retained RSocket connection objects
Forward Spring application logs to a centralized platform to correlate malformed frame errors across instances

How to Mitigate CVE-2026-47888

Immediate Actions Required

Upgrade Spring Framework to a fixed release published in the vendor advisory for your supported branch
Restrict network access to RSocket endpoints so only trusted clients can reach the transport port
Place RSocket services behind a reverse proxy or gateway that enforces connection rate limits
Review deployed applications for reachable RSocket endpoints, including WebSocket-based deployments

Patch Information

Refer to the Spring Security Advisory CVE-2026-47888 for the definitive list of fixed versions across the 5.2, 5.3, 6.0, 6.1, 6.2, and 7.0 branches. Commercial support customers using older branches should obtain the corresponding backport from VMware Tanzu Spring Runtime.

Workarounds

Disable RSocket support in applications that do not require it by removing the spring-messaging RSocket auto-configuration
Terminate RSocket connections at a gateway that validates SETUP frame structure before forwarding traffic
Apply per-IP connection rate limits and short idle timeouts to reduce the volume of malformed frames a single attacker can send

bash

# Example: block direct external access to the RSocket TCP port at the host firewall
sudo iptables -A INPUT -p tcp --dport 7000 -s 10.0.0.0/8 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 7000 -j DROP