CVE-2026-33523

What it actually does

This vulnerability allows HTTP response splitting in multiple Apache HTTP Server modules when Apache processes responses from an untrusted, malicious, or compromised backend server. If backend-controlled response data is not safely normalized before Apache forwards it to clients, an attacker may inject HTTP header delimiters or crafted header content that causes clients, intermediaries, or caches to interpret a single backend response as multiple HTTP responses or as a response with attacker-controlled headers. The likely technical outcomes include header injection, cache poisoning, response manipulation, security-control bypass through altered headers, and limited exposure or modification of client-visible content. The CVSS vector indicates network exploitability with no authentication or user interaction required, but with limited confidentiality and integrity impact and no direct availability impact.

Why it matters to the business

Organizations using Apache HTTP Server as a reverse proxy, gateway, or front end to backend applications could have user-facing responses manipulated if a backend service is compromised or intentionally untrusted. Business consequences may include delivery of misleading content, poisoning of shared caches, weakening of browser security protections, session or redirect manipulation in some deployments, and loss of trust in web applications served through Apache. The issue is not currently listed in CISA KEV, has low EPSS probability, and no known public exploit maturity in the provided data, but it has been public for about 100 days, so internet-facing and proxy-heavy deployments should still treat remediation as a normal-priority security maintenance item.

How an attack unfolds

An attacker first needs influence over a backend response that Apache HTTP Server will proxy, transform, or otherwise process through an affected module. This influence could come from compromising a backend service, controlling an intentionally untrusted upstream, exploiting an application flaw that reflects attacker-controlled values into response headers, or operating a malicious backend in a federated or delegated architecture. The attacker then crafts backend response headers or values containing characters or sequences that can be interpreted as HTTP header or response boundaries. When the affected Apache module handles the backend response, insufficient validation may allow the malicious content to be forwarded in a way that changes how the downstream client, browser, cache, CDN, or intermediary parses the response. Depending on deployment details, the attacker may inject additional headers, alter cache behavior, cause a poisoned response to be stored and served to other users, or manipulate browser behavior through headers such as redirects, cookies, content type, or security policy headers. Successful exploitation generally depends on Apache being in a role where it consumes backend responses and passes them to clients or intermediaries without fully neutralizing malicious response-splitting input.

How to fix it

Upgrade Apache HTTP Server to version 2.4.67 or later. The description states that versions through 2.4.66 are affected and that 2.4.67 fixes the issue. Where vendor-packaged Apache builds are used, apply the operating system or distribution security update that backports the fix, and verify the package changelog references this vulnerability or the corresponding Apache HTTP Server fix. As interim risk reduction, avoid proxying to untrusted backend servers, restrict which backend services Apache may contact, ensure backend administrative access is strongly protected, sanitize application-controlled response header values, disable or limit caching of responses from untrusted backends, and review reverse-proxy modules and configurations that transform or forward backend response headers. These mitigations reduce exploitability but should not replace upgrading.

How to confirm the fix worked

Confirm the running Apache HTTP Server version is 2.4.67 or later, or that the installed vendor package includes a backported fix. Validate both the package version and the active runtime version because old binaries can remain active until the service is restarted. Use commands such as `httpd -v`, `apachectl -v`, or distribution package queries to check installed versions, then restart or reload Apache according to change-control procedures. Review reverse proxy and gateway configurations to identify deployments that contact backend servers outside strict trust boundaries. For exposure validation, test non-production systems by sending backend responses containing encoded or raw CRLF-like header-boundary sequences and confirm Apache does not emit injected headers or split responses to clients. Also verify shared caches, CDNs, and downstream proxies do not store attacker-manipulated responses during testing.

Typical attack path

1. Identify an Apache HTTP Server deployment acting as a reverse proxy, gateway, or intermediary to backend services.
2. Gain control over, compromise, or otherwise influence a backend service response processed by an affected Apache module.
3. Craft backend response data containing malicious HTTP header delimiters, injected headers, or response-splitting sequences.
4. Trigger a client request that causes Apache to fetch or process the malicious backend response.
5. Abuse the resulting client- or cache-visible response manipulation to inject headers, poison cache entries, redirect users, weaken browser protections, or alter displayed content.
6. Optionally repeat the attack against cacheable resources or high-traffic endpoints to expand impact.

How to detect it

To determine whether exploitation already occurred, focus on Apache access logs, error logs, reverse-proxy logs, backend application logs, CDN/cache logs, and web application firewall telemetry. Look for requests that resulted in unusual response headers, unexpected redirects, duplicate headers, malformed header parsing, or cache entries that served content inconsistent with the requested resource. Compare backend response logs with Apache edge responses where available; indicators include backend responses containing carriage-return or line-feed characters inside header values, unexpected `Set-Cookie`, `Location`, `Content-Type`, `Cache-Control`, or security headers, and responses that appear to have been split or truncated. Investigate cache poisoning symptoms such as many users receiving the same unexpected content, redirects, or headers for otherwise normal URLs. Since exploitation requires backend influence, also investigate signs of backend compromise around suspicious events: unauthorized deployments, unexpected upstream responses, new or modified backend routes, and application errors involving invalid response headers. There are no named threat actors or known public exploit campaigns in the provided data, so detection should be behavior-based rather than actor-specific.

• %0d%0a
• %0D%0A
• \r\n
• CRLF
• malformed header
• Invalid header
• Header line too long
• AH01070
• AH01102
• AH00898
• AH02429
• AH00566
• Set-Cookie:
• Location: http
• Location: https
• Cache-Control: public
• Transfer-Encoding: chunked
• Content-Length: 0

What your security team should do

• Inventory Apache HTTP Server instances, prioritizing internet-facing reverse proxies, API gateways, load-balancing tiers, and servers that proxy to multiple backend applications.
• Upgrade affected deployments to Apache HTTP Server 2.4.67 or later, or apply equivalent vendor backported security updates.
• Restart Apache after patching and verify the active runtime version, not only the installed package version.
• Identify Apache configurations that proxy to untrusted, partner-managed, dynamically registered, or lower-trust backend services and apply stricter allowlisting and network segmentation.
• Review backend applications for unsafe insertion of user-controlled data into response headers, especially redirects, cookies, content disposition, content type, cache-control, and custom headers.
• Temporarily disable or reduce caching for responses from untrusted backends until patched and validated.
• Add monitoring for anomalous response headers, unexpected redirects, duplicate or malformed HTTP response headers, and suspicious cache behavior.
• Because EPSS is low and the issue is not in KEV, prioritize based on exposure and proxy role rather than emergency response, while still addressing it in the next regular patch cycle for internet-facing systems.