CVE-2023-40167: Eclipse Jetty HTTP Parsing Vulnerability

CVE-2023-40167 Overview

Eclipse Jetty, a widely-used Java-based web server and servlet engine, contains an HTTP Request Smuggling vulnerability in versions prior to 9.4.52, 10.0.16, 11.0.16, and 12.0.1. The vulnerability stems from Jetty's overly permissive parsing of the Content-Length HTTP/1 header field, where it incorrectly accepts a + character preceding the numeric value. This behavior deviates from RFC 9110 specifications and creates potential security risks when Jetty operates in conjunction with other servers or proxies.

Critical Impact

While no known exploit scenario exists, this parsing inconsistency could potentially enable HTTP request smuggling attacks when Jetty is deployed behind a front-end server that rejects such malformed requests but fails to properly close the connection.

Affected Products

• Eclipse Jetty versions prior to 9.4.52
• Eclipse Jetty versions 10.x prior to 10.0.16
• Eclipse Jetty versions 11.x prior to 11.0.16
• Eclipse Jetty version 12.0.0 (including beta releases) prior to 12.0.1
• Debian Linux 10.0, 11.0, and 12.0

Discovery Timeline

• 2023-09-15 - CVE CVE-2023-40167 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2023-40167

Vulnerability Analysis

This vulnerability falls under the HTTP Request Smuggling category (CWE-130: Improper Handling of Length Parameter Inconsistency). The core issue lies in how Jetty parses the Content-Length header value in HTTP/1 requests. According to RFC 9110 Section 8.6, the Content-Length field value must be a decimal integer without any leading characters other than digits.

Jetty's lenient parsing accepts a + sign before the numeric value (e.g., Content-Length: +100), which most standards-compliant servers would reject with a 400 Bad Request response. This parsing discrepancy becomes problematic in multi-tier architectures where Jetty sits behind another HTTP server or load balancer.

The attack scenario involves exploiting differences in how front-end and back-end servers interpret the same HTTP request. If a front-end server rejects the malformed Content-Length header but fails to close the connection properly, subsequent data on that connection could be misinterpreted by Jetty as a new request, potentially leading to request smuggling.

Root Cause

The root cause is an Input Validation Error in Jetty's HTTP/1 header parsing logic. The parser does not strictly validate that the Content-Length header value consists solely of decimal digits as required by the HTTP specification. By accepting the + prefix character, Jetty deviates from the expected behavior of compliant HTTP servers, creating an inconsistency that attackers could potentially exploit in specific deployment configurations.

Attack Vector

The attack vector is network-based, requiring no authentication or user interaction. An attacker would need to craft malicious HTTP requests with a + character prefixing the Content-Length value and send them through a deployment where Jetty operates behind a front-end server with different parsing behavior. The attack relies on the front-end server sending a 400 response but keeping the connection open, allowing the attacker to potentially smuggle additional requests to Jetty.

The malformed HTTP request would look similar to:

GET /endpoint HTTP/1.1
Host: target.example.com
Content-Length: +50

[request body]

Where a compliant server would reject the +50 value but Jetty would interpret it as 50 bytes, potentially causing desynchronization between the front-end and back-end servers in their understanding of request boundaries.

Detection Methods for CVE-2023-40167

Indicators of Compromise

• HTTP requests in access logs containing Content-Length headers with non-numeric prefixes such as + characters
• Unusual patterns of 400 responses from front-end servers followed by successful requests to Jetty
• Evidence of request smuggling attempts such as multiple requests in single connection logs or unexpected request paths

Detection Strategies

• Implement deep packet inspection at the network layer to identify HTTP requests with malformed Content-Length headers containing the + prefix character
• Configure Web Application Firewalls (WAF) to block HTTP requests where Content-Length values do not match the pattern of pure decimal digits
• Enable verbose HTTP request logging on Jetty servers to capture full header information for forensic analysis
• Deploy SentinelOne Singularity to monitor for anomalous HTTP traffic patterns and potential request smuggling indicators

Monitoring Recommendations

• Monitor for sudden increases in 400-series HTTP error responses from front-end servers which may indicate probing activity
• Establish baseline metrics for HTTP request patterns and alert on statistical anomalies in request structure
• Implement log correlation between front-end proxies and Jetty back-end servers to identify parsing discrepancies
• Enable SentinelOne's behavioral AI to detect application-layer attacks targeting your Jetty deployments

How to Mitigate CVE-2023-40167

Immediate Actions Required

• Upgrade Eclipse Jetty to version 9.4.52, 10.0.16, 11.0.16, or 12.0.1 depending on your current major version
• For Debian systems, apply the security updates referenced in DSA-5507 and the Debian LTS Announcement
• Review your deployment architecture to identify Jetty instances behind other HTTP servers or load balancers
• Configure front-end servers to close connections after sending 400 responses to prevent potential smuggling scenarios

Patch Information

Security patches are available for all affected Jetty versions. The Eclipse Foundation has released the following patched versions that include strict Content-Length header validation:

• Jetty 9.4.52 for 9.x branch users
• Jetty 10.0.16 for 10.x branch users
• Jetty 11.0.16 for 11.x branch users
• Jetty 12.0.1 for 12.x branch users

For detailed patch information and release notes, refer to the GitHub Security Advisory GHSA-hmr7-m48g-48f6.

Workarounds

• No official workaround is available as there is no known exploit scenario according to the vendor advisory
• Ensure front-end servers are configured to close connections after rejecting malformed requests with 400 responses
• Consider implementing strict HTTP request validation at the network perimeter using a WAF that enforces RFC-compliant Content-Length parsing
• Monitor network traffic for requests containing malformed headers while planning the upgrade path

# Configuration example for upgrading Jetty via Maven
# Update your pom.xml jetty.version property to the patched version
# For Jetty 11.x users:
mvn versions:set-property -Dproperty=jetty.version -DnewVersion=11.0.16

# Verify the upgrade
mvn dependency:tree | grep jetty