CVE-2024-38828

What it actually does

Spring MVC controller methods that bind the HTTP request body to a parameter of type byte[] annotated with @RequestBody do not enforce an effective maximum body size while the message converter materializes the payload. An unauthenticated network attacker can therefore force unbounded heap allocation of a single byte array, driving garbage-collection stalls, OutOfMemoryError, or JVM/process termination. Confidentiality and integrity are unaffected; impact is availability-only (CVSS 5.3, C:N/I:N/A:L).

Why it matters to the business

Internet-facing or internal APIs built on Spring MVC can slow, error, or go offline, interrupting customer transactions and dependent services. The issue is not in CISA KEV, is not tied to ransomware, has exploit maturity None, and a low, unchanged EPSS of about 0.007 over 30 days, so it is not an emergency-class event—but it has been public for roughly 690 days, so remaining unpatched exposure is an avoidable availability and SLA risk rather than a novel threat.

How an attack unfolds

An attacker finds a Spring MVC endpoint whose handler accepts @RequestBody byte[] (binary ingest, webhooks, or similar). No credentials or user interaction are required. The attacker sends HTTP POST or PUT requests with an excessively large body so the framework copies the entire payload into a heap byte array. Concurrent or repeated oversized requests exhaust memory and CPU (GC), causing errors, timeouts, or a crash for legitimate clients. No named APT groups or campaigns are associated with this CVE, and there is no known public exploit maturity.

How to fix it

Upgrade Spring Framework to a patched line that applies body-size limits for @RequestBody byte[] (6.1.14 or later, 6.0.23 or later, or 5.3.41 or later, matching the major version in use). Replace raw byte[] body parameters with size-bounded streaming, multipart handling with explicit max-file and max-request sizes, or structured DTOs. Set application, servlet/container, and reverse-proxy maximum request-body sizes (for example Spring multipart/max-request-size properties, Tomcat/Jetty/Undertow post-size limits, and proxy client_max_body_size). For the vendor-listed SUSE Linux Enterprise Live Patching 15 SP5 artifact kernel-livepatch-SLE15-SP5-RT_Update_10, apply version 2-150500.11.8.1 or later. Restart application runtimes after upgrades.

How to confirm the fix worked

Inventory source and compiled Spring MVC controllers for @RequestBody byte[] parameters and confirm spring-web / spring-webmvc versions are at or above the patched releases. Verify max body size is configured at app, container, and proxy layers. After patching, confirm oversized requests are rejected with a client error (typically 400 or 413) and that heap does not grow without bound. Check lockfiles, SBOM, and images for leftover vulnerable Spring artifacts; for SUSE live-patching hosts, confirm kernel-livepatch-SLE15-SP5-RT_Update_10 is 2-150500.11.8.1 or newer.

Typical attack path

1. Discover HTTP endpoints served by Spring MVC (framework fingerprints, API docs, or error pages).
2. Identify handlers that consume a raw request body as byte[].
3. Send unauthenticated HTTP requests with an oversized body to those endpoints.
4. Repeat or parallelize requests to exhaust JVM heap and trigger GC/OOM.
5. Service becomes slow, returns 5xx, restarts, or stops responding.

How to detect it

This is resource exhaustion, not an implant: hunt availability artifacts, not persistence. Around latency spikes, 5xx bursts, pod/process restarts, or OOM kills, review HTTP access logs for POST/PUT with unusually large Content-Length or body bytes to Spring MVC routes. Inspect JVM and container metrics for sudden heap growth, GC storms, and OutOfMemoryError in application logs. No named threat actors are reported; treat hits as opportunistic denial-of-service or capacity abuse. Confirm whether the orchestrator or OS OOM killer terminated the Java process.

• java.lang.OutOfMemoryError
• Java heap space
• GC overhead limit exceeded
• ByteArrayHttpMessageConverter
• org.springframework.http.converter.HttpMessageNotReadableException
• org.springframework.web.servlet.DispatcherServlet
• Failed to read HTTP message

What your security team should do

• Treat this as overdue standard patching, not a KEV emergency: upgrade Spring Framework to 6.1.14+/6.0.23+/5.3.41+ and, where the listed SUSE package is present, to kernel-livepatch-SLE15-SP5-RT_Update_10 2-150500.11.8.1.
• Prioritize internet-exposed Spring MVC apps; EPSS is low and no ransomware/KEV use is reported.
• Ban or wrap @RequestBody byte[] and enforce request-body limits at every HTTP boundary (app, container, proxy/WAF).
• Alert on JVM heap/GC/OOM and on access-log requests with abnormal Content-Length against Spring endpoints.