Attackers use HTTP Response Splitting to inject crafted line breaks into a server response so that one request can create multiple responses. That can lead to cache poisoning, header injection, or cross-user content manipulation. Defenders should validate untrusted input before it reaches response headers and reject newline characters in header values.
How attackers turn one response into several
http response splitting works because some servers still treat attacker-controlled data as if it were safe to place in headers. By inserting encoded line breaks into a response header value, an attacker can make the server emit a second response block. That turns a single request into a response boundary confusion problem, which is what enables downstream abuse.
When the application reflects unsanitised input into headers such as Location, Set-Cookie or cache-related fields, the browser or intermediary may parse the output as two messages instead of one. That is why response splitting is often discussed alongside web application injection issues rather than as a standalone transport flaw.
Attackers do not need to own the server to make this useful. They only need one input path that reaches a response header unsafely. Once they can control the framing of the response, they can change how downstream systems interpret it.
What attackers gain from the injection
The most practical payoff is cache poisoning. If a shared proxy or CDN stores the attacker-shaped response, later users can be served manipulated content, incorrect headers or attacker-supplied material. In other cases the split response can inject headers that change browser handling, or place arbitrary content into a response that another user later receives.
That is why this technique is attractive in multi-user environments and in front of shared caches. The real target is often not the first victim request, but the trust relationship between the origin server, intermediary caches and subsequent users.
Attackers may also use the split to set or override cookies, redirect users, or create subtle cross-user contamination. The specific effect depends on the header context, intermediary behaviour and whether the server normalises newline characters before output.
Why the vulnerability persists and how defenders break the chain
The core failure is trusting input that can reach HTTP headers. Any application code that copies request data into response metadata without strict validation risks turning a harmless field into a response-shaping primitive. The fix is to reject newline characters in header values, normalise input before it reaches output routines, and prefer safe framework APIs that separate data from header construction.
Defenders should also test the behaviour of reverse proxies, application servers and CDNs, because response splitting can be blocked in one layer and reintroduced in another. If the application is behind shared caching, verify that cache-control handling and header canonicalisation are consistent across the full delivery path.
For a broader view of how request manipulation, web cache abuse and related injection patterns fit together, see Web Application Attacks Guide. For incident patterns involving manipulated responses, credentials and cross-user abuse, The State of NHI & AI Agent Breach Report 2026 is a useful companion reference.
Risk and Threat Considerations
Response splitting becomes materially more dangerous when the application sits behind shared caches or when downstream systems reuse headers for security or routing decisions. In that setup, one crafted request can affect many users, not just the original target.
Failure mechanism: The attacker injects a line break into a response header value, causing the server or intermediary to interpret one response as multiple messages and store or forward attacker-influenced output.
Impact: The result can include cache poisoning, header injection, session confusion, content manipulation, and indirect compromise of other users who later receive the poisoned response.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V4 — API and Web Service | Response splitting is a web response handling flaw in application output. |
| Recommendation — Validate and encode all response metadata before it reaches HTTP headers. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The issue is an application-layer injection weakness that requires secure coding and testing. |
| Recommendation — Test application output paths for header injection and response splitting flaws. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Shared-cache poisoning can persist manipulated response content for later users. |
| Recommendation — Protect cached response data and verify cache handling cannot be poisoned. | ||
Practitioner Guidance
What to verify: Check every code path that writes response headers, including framework helpers, error handlers and redirect logic. If user input can reach a header field, confirm that newline characters are rejected before output, not after.
Common mistake: Teams often secure the obvious application endpoint but miss intermediary behaviour. Test the full delivery chain, including CDN, proxy and cache layers, because a safe origin response can still be altered or misinterpreted downstream.
Practitioner takeaway: Treat header construction as a trust boundary. Response splitting is prevented less by scanning for a single payload than by ensuring that untrusted input can never influence response framing.