CVE-2026-47885: Spring WebFlux DoS Vulnerability

CVE-2026-47885 Overview

CVE-2026-47885 affects the PartEventHttpMessageReader component in Spring WebFlux. The reader fails to enforce the maxPartSize limit when maxInMemorySize is configured to -1. Applications relying on this size boundary to constrain multipart request payloads process parts without an upper bound. This exposes affected services to resource exhaustion when handling untrusted multipart uploads. The issue impacts Spring Framework versions 6.1.0 through 6.1.28, 6.2.0 through 6.2.19, and 7.0.0 through 7.0.8.

Critical Impact
Applications that set maxInMemorySize to -1 accept unbounded multipart parts, enabling attackers to submit oversized uploads that can exhaust server memory and cause denial of service.

Affected Products

Spring Framework 7.0.0 - 7.0.8
Spring Framework 6.2.0 - 6.2.19
Spring Framework 6.1.0 - 6.1.28

Discovery Timeline

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

Technical Details for CVE-2026-47885

Vulnerability Analysis

Spring WebFlux processes multipart HTTP requests through configurable HttpMessageReader implementations. The PartEventHttpMessageReader streams individual multipart parts as reactive events. Two configuration properties govern buffering behavior: maxInMemorySize bounds in-memory buffering per part, and maxPartSize bounds the total size of any single part regardless of buffering strategy.

The reader implementation ties the maxPartSize enforcement path to the maxInMemorySize handling. When developers set maxInMemorySize to -1 to disable in-memory limits and stream parts directly, the code path that validates maxPartSize is skipped. Parts of arbitrary size flow through the reader without a hard cap.

This is an input validation and resource management failure. Attackers who can send multipart requests to an affected endpoint can push arbitrarily large payloads through the reader.

Root Cause

The defect resides in the conditional logic gating maxPartSize enforcement inside PartEventHttpMessageReader. The -1 sentinel value for maxInMemorySize bypasses the branch responsible for accumulating and comparing part size against maxPartSize. The two limits should be enforced independently.

Attack Vector

An unauthenticated remote attacker sends a crafted multipart/form-data request to any endpoint served by a WebFlux controller that consumes PartEvent streams. Because maxPartSize is not enforced, the attacker streams data indefinitely. Repeated requests can consume file descriptors, sockets, and heap memory, degrading availability for legitimate traffic.

The vulnerability manifests only in applications that explicitly configure maxInMemorySize to -1 on the PartEventHttpMessageReader. Default configurations are not affected. See the Spring Security Advisory CVE-2026-47885 for the authoritative technical description.

Detection Methods for CVE-2026-47885

Indicators of Compromise

Sustained inbound multipart/form-data requests with abnormally large Content-Length values or long-lived streaming uploads.
Spring Boot application logs showing rising heap usage, garbage collection pressure, or OutOfMemoryError correlated with multipart endpoints.
Reactor Netty metrics reporting increased buffer allocations and elevated open connection counts against WebFlux upload routes.

Detection Strategies

Audit application code and configuration for calls that set maxInMemorySize(-1) on PartEventHttpMessageReader or the enclosing CodecConfigurer.
Inspect running Spring Framework versions via dependency reports and flag any instance within the affected ranges 6.1.0-6.1.28, 6.2.0-6.2.19, and 7.0.0-7.0.8.
Correlate reverse proxy access logs with backend memory metrics to identify multipart upload traffic that precedes resource pressure events.

Monitoring Recommendations

Alert on JVM heap saturation and prolonged garbage collection pauses on hosts running Spring WebFlux services.
Monitor per-endpoint request size distributions and rate-limit clients that exceed expected multipart payload sizes.
Track HTTP 5xx responses and connection resets on multipart upload routes as availability indicators.

How to Mitigate CVE-2026-47885

Immediate Actions Required

Upgrade Spring Framework to a fixed maintenance release above the affected ranges as published in the Spring Security Advisory CVE-2026-47885.
Remove any explicit maxInMemorySize(-1) configuration on PartEventHttpMessageReader until the upgrade is complete.
Place a request size limit at the reverse proxy or API gateway in front of affected WebFlux services.

Patch Information

VMware Spring maintainers published fixes referenced in the Spring Security Advisory CVE-2026-47885. Consult the advisory for the specific patched release versions that restore independent enforcement of maxPartSize regardless of the maxInMemorySize setting.

Workarounds

Set maxInMemorySize to a positive value that reflects your workload rather than -1, which restores the enforcement path for maxPartSize.
Enforce a maximum request body size at an upstream layer such as NGINX client_max_body_size or a WAF policy to bound multipart uploads.
Restrict multipart upload endpoints to authenticated clients and apply per-client rate limits to reduce the abuse surface.

bash

# Example NGINX request size limit for a WebFlux upstream
http {
    client_max_body_size 10m;

    server {
        listen 443 ssl;
        location /api/upload {
            proxy_pass http://webflux_backend;
        }
    }
}