CVE-2025-53094
Awaiting Analysis Awaiting Analysis - Queue
BaseFortify

Publication date: 2025-06-27

Last updated on: 2025-06-30

Assigner: GitHub, Inc.

Description
ESPAsyncWebServer is an asynchronous HTTP and WebSocket server library for ESP32, ESP8266, RP2040 and RP2350. In versions up to and including 3.7.8, a CRLF (Carriage Return Line Feed) injection vulnerability exists in the construction and output of HTTP headers within `AsyncWebHeader.cpp`. Unsanitized input allows attackers to inject CR (`\r`) or LF (`\n`) characters into header names or values, leading to arbitrary header or response manipulation. Manipulation of HTTP headers and responses can enable a wide range of attacks, making the severity of this vulnerability high. A fix is available at pull request 211 and is expected to be part of version 3.7.9.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-06-27
Last Modified
2025-06-30
Generated
2026-05-07
AI Q&A
2025-06-27
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Currently, no data is known.
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-113 The product receives data from an HTTP agent/component (e.g., web server, proxy, browser, etc.), but it does not neutralize or incorrectly neutralizes CR and LF characters before the data is included in outgoing HTTP headers.
CWE-93 The product uses CRLF (carriage return line feeds) as a special element, e.g. to separate lines or records, but it does not neutralize or incorrectly neutralizes CRLF sequences from inputs.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a CRLF (Carriage Return Line Feed) injection in the ESPAsyncWebServer library versions up to 3.7.8. It occurs because the library does not properly sanitize input used to construct HTTP headers, allowing attackers to inject CR (\r) or LF (\n) characters into header names or values. This can lead to manipulation of HTTP headers or responses, such as injecting additional headers or splitting HTTP responses, which can be exploited for various attacks. [1, 2]


How can this vulnerability impact me? :

The vulnerability can allow attackers to manipulate HTTP headers and responses, enabling attacks like HTTP response splitting, header injection, cross-site scripting (XSS), cache poisoning, session fixation, bypassing CORS or security headers, and other protocol violations. These impacts can compromise the security and integrity of web communications and potentially lead to further exploitation. [2]


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring for HTTP headers containing CR (\r) or LF (\n) characters, which are not normally allowed. One can inspect HTTP traffic for suspicious headers that include these characters, indicating possible injection attempts. Since the vulnerability involves injection of CRLF sequences into headers, commands that capture and analyze HTTP headers, such as using tcpdump or Wireshark to capture traffic and then searching for headers with embedded CR or LF characters, can be useful. For example, using tcpdump to capture HTTP traffic: `tcpdump -A -s 0 'tcp port 80'` and then searching for headers containing \r or \n sequences. Additionally, logs or application-level monitoring that detects exceptions thrown when headers contain CRLF can help identify attempts. However, no specific detection commands are provided in the resources. [2]


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include updating the ESPAsyncWebServer library to version 3.7.9 or later, where the vulnerability is fixed by sanitizing input to prevent CRLF injection. If updating is not immediately possible, implement input validation to reject any HTTP header names or values containing CR (\r) or LF (\n) characters, ideally by throwing exceptions or logging such attempts. Monitoring for suspicious header injection attempts and applying patches from pull request #211 are recommended. Rejecting unsafe headers prevents manipulation of HTTP responses and mitigates the risk of HTTP response splitting and related attacks. [1, 2]


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart