Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2024-42516

CVE-2024-42516: Apache HTTP Server Response Splitting Flaw

CVE-2024-42516 is an HTTP response splitting vulnerability in Apache HTTP Server that allows attackers to manipulate Content-Type headers. This article covers technical details, affected versions, impact, and mitigation.

Updated:

CVE-2024-42516 Overview

CVE-2024-42516 is an HTTP response splitting vulnerability in the core of Apache HTTP Server. An attacker who can manipulate the Content-Type response headers of applications hosted or proxied by the server can split the HTTP response. The flaw is a regression of CVE-2023-38709, where the original patch shipped in Apache HTTP Server 2.4.59 failed to fully address the underlying issue. The vulnerability is classified under [CWE-20] Improper Input Validation. Apache recommends upgrading to version 2.4.64 to remediate the flaw.

Critical Impact

Remote attackers can inject crafted response headers to split HTTP responses, enabling cache poisoning, cross-site scripting, and session manipulation against downstream clients and proxies.

Affected Products

  • Apache HTTP Server versions prior to 2.4.64
  • Apache HTTP Server 2.4.59 (incomplete fix for CVE-2023-38709)
  • Debian LTS distributions shipping vulnerable Apache HTTP Server packages

Discovery Timeline

  • 2025-07-10 - CVE-2024-42516 published to NVD and disclosed on the Openwall OSS-Security mailing list
  • 2025-08 - Debian LTS security announcement published for affected Apache packages
  • 2025-11-04 - Last updated in NVD database

Technical Details for CVE-2024-42516

Vulnerability Analysis

The vulnerability resides in how Apache HTTP Server constructs the Content-Type response header. When an application hosted or proxied by httpd produces a Content-Type value derived from attacker-influenced input, Apache fails to sanitize embedded CR/LF (carriage return / line feed) sequences before emitting the header on the wire.

An attacker who controls the Content-Type value can therefore terminate the header early and inject additional headers or an entirely separate HTTP response. Downstream caches, reverse proxies, and browsers parse the injected content as a legitimate server response. This is a recurrence of the issue originally tracked as CVE-2023-38709, which the 2.4.59 patch did not fully eliminate.

The primary impact is to integrity. Attackers can poison shared caches, deliver malicious payloads to other users, hijack sessions, or bypass security controls that rely on header trust boundaries.

Root Cause

The root cause is improper input validation [CWE-20] in the core response header generation path. Apache treats the Content-Type value as a trusted string and writes it directly into the response without stripping or rejecting CR (\r) and LF (\n) characters. The 2.4.59 fix addressed a subset of the injection paths but left additional code routes that still permit header termination.

Attack Vector

The attack is remote and unauthenticated when the backend application accepts untrusted input that flows into the Content-Type header. Typical vectors include:

  • Web applications that set Content-Type from a query string, URL path, or file extension
  • Reverse-proxied backends that echo client-supplied media types
  • CGI or scripting modules that forward request data into response headers

An attacker submits a request such that the resulting Content-Type contains \r\n sequences followed by attacker-chosen headers and body content. Apache serializes the value verbatim, producing two distinct responses on the connection. See the Apache HTTP Server Vulnerabilities advisory for vendor technical detail.

Detection Methods for CVE-2024-42516

Indicators of Compromise

  • Access log entries containing URL-encoded CR/LF sequences (%0d%0a, %0D%0A) in parameters that influence response content types
  • Unexpected duplicate HTTP/1.x status lines or duplicate header blocks observed on the wire between Apache and downstream caches
  • Cache entries serving content with mismatched Content-Type values for the same URL

Detection Strategies

  • Inspect Apache access_log and error_log for requests targeting endpoints that reflect file extensions or media types, filtering for encoded newline characters in query strings and path segments
  • Deploy WAF or reverse proxy rules that reject inbound requests containing raw or encoded CRLF in parameters known to influence response headers
  • Validate the installed Apache version with httpd -v and flag any host running a release earlier than 2.4.64

Monitoring Recommendations

  • Forward Apache access and error logs to a centralized analytics platform and alert on CRLF injection patterns in request URIs
  • Monitor downstream cache nodes (Varnish, CDN edge) for anomalous header counts or response sizes that may indicate response splitting
  • Track outbound Content-Type header values for non-standard characters or duplicate header occurrences

How to Mitigate CVE-2024-42516

Immediate Actions Required

  • Upgrade Apache HTTP Server to version 2.4.64 or later on all affected hosts
  • Audit hosted and proxied applications for code paths that set Content-Type from user-controlled input and add strict CR/LF filtering
  • Apply distribution-specific updates such as the Debian LTS security announcement for packaged Apache builds

Patch Information

The official fix is included in Apache HTTP Server 2.4.64. The 2.4.59 patch issued for CVE-2023-38709 is incomplete and does not remediate CVE-2024-42516. Refer to the Apache HTTP Server 2.4 vulnerabilities page and the Openwall OSS-Security disclosure thread for vendor guidance.

Workarounds

  • Configure a reverse proxy or WAF in front of Apache to strip or reject CR/LF byte sequences in request parameters and response headers
  • Use mod_headers to enforce a fixed Content-Type for static responses where backend-driven types are not required
  • Restrict applications from forwarding raw user input into Content-Type and instead map to an allowlist of safe media types
bash
# Verify installed version and enforce a sanitized Content-Type via mod_headers
httpd -v

# In httpd.conf or a virtual host configuration:
LoadModule headers_module modules/mod_headers.so

<Location "/api/">
    # Replace any backend-supplied Content-Type with a known-good value
    Header always set Content-Type "application/json; charset=utf-8"
</Location>

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.