CVE-2026-23941
HTTP Request Smuggling in Erlang OTP Inets Module Allows Request Desync
Publication date: 2026-03-13
Last updated on: 2026-04-06
Assigner: EEF
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| erlang | otp | From 17.0 (inc) to 28.4.1 (inc) |
| erlang | otp | 27.3.4.9 |
| erlang | otp | 26.2.5.18 |
| erlang | inets | From 5.10 (inc) to 9.6.1 (inc) |
| erlang | inets | 9.3.2.3 |
| erlang | inets | 9.1.0.5 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-444 | The product acts as an intermediary HTTP agent (such as a proxy or firewall) in the data flow between two entities such as a client and server, but it does not interpret malformed HTTP requests or responses in ways that are consistent with how the messages will be processed by those entities that are at the ultimate destination. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-23941 is a high-severity HTTP request smuggling vulnerability in the Erlang/OTP httpd server. It occurs because the server improperly handles HTTP requests containing multiple Content-Length headers with differing values. Specifically, the server uses the first Content-Length header for parsing the request body, while common reverse proxies use the last Content-Length header. This inconsistency violates RFC 9112 Section 6.3 and causes front-end and back-end desynchronization.
This desynchronization allows an attacker to smuggle malicious HTTP requests by queuing attacker-controlled bytes as the start of the next request, potentially bypassing security controls.
How can this vulnerability impact me? :
Exploitation of this vulnerability can lead to several serious impacts including:
- Authentication bypass by smuggled requests circumventing proxy-layer authentication to access protected backend resources.
- Cache poisoning through desynchronization of request and response boundaries.
- Request hijacking by prepending smuggled requests to legitimate user requests on persistent connections, enabling unauthorized actions.
These impacts primarily affect deployments where the Erlang/OTP httpd server is used behind front-end proxies that handle Content-Length headers differently and have HTTP persistent connections enabled.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability can be detected by monitoring HTTP requests for the presence of multiple Content-Length headers with differing values, which is the root cause of the HTTP request smuggling issue.'}, {'type': 'paragraph', 'content': 'Detection involves checking HTTP traffic, especially requests passing through reverse proxies or load balancers, for duplicate Content-Length headers that do not match.'}, {'type': 'paragraph', 'content': 'While specific commands are not provided in the resources, typical detection methods include using network traffic analysis tools like tcpdump or Wireshark to capture HTTP requests and inspecting headers for multiple Content-Length fields.'}, {'type': 'paragraph', 'content': 'For example, you can use tcpdump to capture HTTP traffic on port 80 or 443 and then filter or search for requests containing multiple Content-Length headers.'}, {'type': 'list_item', 'content': "tcpdump -i <interface> -A 'tcp port 80 or tcp port 443' | grep -i 'Content-Length'"}, {'type': 'list_item', 'content': 'Use custom scripts or tools to parse captured HTTP requests and flag those with multiple Content-Length headers having different values.'}, {'type': 'paragraph', 'content': 'Additionally, web application firewalls (WAFs) can be configured to detect and block requests with multiple Content-Length headers.'}] [1]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include configuring your frontend proxies to reject HTTP requests containing multiple Content-Length headers.
Disabling HTTP keep-alive in the Erlang/OTP httpd server by setting the configuration option `{keep_alive, false}` is recommended to close connections after each request, preventing request desynchronization, though this may impact performance.
Deploying Web Application Firewalls (WAFs) with rules to reject or block requests containing multiple Content-Length headers is also advised.
Updating Erlang/OTP and inets to the patched versions (OTP 28.4.1, 27.3.4.9, 26.2.5.18 and inets 9.1.0.5, 9.3.2.3, 9.6.1) that include the fix for this vulnerability is the definitive solution.