ISGroup CyberSecurity Consulting

CVE-2024-24795: HTTP Response Splitting Vulnerability in Apache HTTP Server

ISGroup Cybersecurity

Apache HTTP Server is one of the most widely used web servers on the Internet, often utilized as a reverse proxy to manage and route traffic to backend applications. Its stability and performance make it a critical component in many corporate and web hosting environments.

This vulnerability represents a significant risk for organizations using Apache in a reverse proxy configuration. A successful exploit allows for HTTP desynchronization, a sophisticated attack that can lead to web cache poisoning or session hijacking. An attacker could deface a website, serve malicious content to users, or steal sensitive session cookies to impersonate legitimate users and access their data.

The vulnerability is exploitable when the backend application, for which Apache acts as a proxy, has a separate flaw that allows for response header injection. Although there are no public reports of active exploits for this specific CVE, HTTP desynchronization is a well-understood class of attack and public proof-of-concepts are available, increasing the likelihood of potential future exploitation. Reverse proxies exposed to the Internet are at the highest risk.

ProductApache HTTP Server
Date2025-12-06 12:19:05

Technical Summary

The root cause of CVE-2024-24795 is improper validation of HTTP response headers coming from backend applications, a flaw classified as CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers (‘HTTP Response Splitting’). When functioning as a reverse proxy, the Apache server does not correctly neutralize carriage return and line feed (CRLF) characters present in these headers.

An attacker can exploit this flaw by compromising a backend application to inject malicious CRLF sequences into a response header. The attack chain proceeds as follows:

  1. An attacker exploits a separate flaw in a backend application to inject a payload containing CRLF sequences (\r\n) into an HTTP response header.
  2. The backend application sends the manipulated response to the Apache reverse proxy.
  3. The vulnerable Apache server forwards this response without removing the CRLF characters.
  4. Downstream clients or caches interpret the CRLF sequence as the end of one response and the beginning of a second response controlled by the attacker. This desynchronizes the connection.

This desynchronization allows an attacker to prepend a malicious response to the next legitimate response on the same TCP connection, enabling cache poisoning or the theft of session data from the next user.

Affected versions:

  • Apache HTTP Server versions prior to 2.4.59 are vulnerable.

Fix available:

  • The vulnerability has been fixed in Apache HTTP Server version 2.4.59 (and later).

A conceptual example of a malicious response header coming from a backend:

HTTP/1.1 200 OK
Injected-Header: value\r\n\r\nHTTP/1.1 200 OK\r\nContent-Type: text/html\r\nContent-Length: 50\r\n\r\n<html><body>Malicious Content</body></html>

Recommendations

  • Apply the patch immediately: Update all Apache HTTP server instances to the latest stable version, 2.4.59 or later, which includes the fix for this vulnerability.

  • Mitigations:

  • Harden all backend applications to prevent HTTP header injection vulnerabilities. Implement strict input validation and output encoding for all user-controllable data that is reflected in response headers.

  • If patching is not immediately possible, configure a Web Application Firewall (WAF) or an intermediate proxy with strict CRLF filtering rules for HTTP response headers.

  • Hunting & Monitoring:

  • Monitor application and proxy logs for unusual responses from backend servers. In particular, look for HTTP response headers containing URL-encoded CRLF sequences (%0d%0a).

  • Perform audits on cache servers to detect anomalies, such as mismatched Content-Length headers or unexpected content served for popular resources. Analyze logs for reports of multiple responses received for a single request.

  • Incident Response:

  • If a compromise is suspected, immediately flush all relevant web caches (both server-side and client-side, if possible).

  • Invalidate all active user sessions to mitigate the risk of session hijacking.

  • Isolate the involved reverse proxies and backend servers to conduct a forensic investigation.

  • Defense in Depth:

  • Regularly perform security assessments and code reviews on backend applications to identify and fix header injection flaws.

  • Implement network segmentation to isolate reverse proxies from critical internal systems.

[Callforaction-THREAT-Footer]

In