CVE-2024-9622

What it actually does

HTTP smuggling requests containing ASCII control characters force the Netty HttpObjectDecoder into a BAD_MESSAGE state, causing all subsequent legitimate requests on the same connection to be dropped and resulting in client timeouts.

Why it matters to the business

Systems using load balancers may experience intermittent availability issues and degraded service for clients, though the flaw is not known to be exploited in the wild or used in ransomware campaigns.

How an attack unfolds

An attacker crafts an HTTP request that uses smuggling techniques with an ASCII control character; when processed, the decoder enters BAD_MESSAGE state and silently discards any further requests sent over the persistent connection, leading to timeouts for legitimate traffic.

How to fix it

Upgrade org.springframework.data:spring-data-commons to version 1.13.12 or 2.0.7 (or later) to resolve the underlying request-handling defect; apply the update across all Maven-managed deployments and verify the new version is active after restart.

How to confirm the fix worked

Confirm the installed version of spring-data-commons meets or exceeds 1.13.12 or 2.0.7, then test connectivity with both normal and control-character-containing requests to ensure the BAD_MESSAGE state is no longer triggered and subsequent requests are processed.

Typical attack path

1. Identify a target endpoint accepting HTTP/1.1 connections over a persistent or load-balanced channel
2. Send a single malformed request containing an ASCII control character using smuggling syntax
3. Observe the decoder transition to BAD_MESSAGE state
4. Issue subsequent legitimate requests on the same connection and confirm they are ignored
5. Repeat to sustain denial of service for clients behind the affected endpoint

How to detect it

Monitor application and Netty access logs for repeated BAD_MESSAGE entries or sudden spikes in client timeouts on persistent connections; correlate with upstream load-balancer logs showing dropped requests without corresponding server errors.

What your security team should do

• Prioritize patching spring-data-commons to the fixed releases 1.13.12 or 2.0.7 within normal change windows given the moderate CVSS and stable low EPSS
• Review load-balancer and connection-handling configurations for timeout and retry settings that could mitigate client impact until patches are deployed
• Add the affected library to dependency scanning policies to prevent reintroduction of vulnerable versions