Summary
A request smuggling vulnerability in Squid allows a trusted client to exploit ambiguous HTTP/1.1 Transfer-Encoding parsing. Under deployments using HTTP/1.1, an attacker may bypass intermediary security controls and, where an upstream cache is present, poison cached responses for delivery to other clients.
A request smuggling vulnerability in Squid allows a trusted client to exploit ambiguous HTTP/1.1 Transfer-Encoding parsing. Under deployments using HTTP/1.1, an attacker may bypass intermediary security controls and, where an upstream cache is present, poison cached responses for delivery to other clients.
Affected context
The issue occurs in Squid deployments that accept HTTP/1.1 requests and process a bare Transfer-Encoding: identity header. Risk is higher when Squid is positioned behind or in front of other HTTP intermediaries, security filters, or web caches that interpret request boundaries differently.
The issue occurs in Squid deployments that accept HTTP/1.1 requests and process a bare Transfer-Encoding: identity header. Risk is higher when Squid is positioned behind or in front of other HTTP intermediaries, security filters, or web caches that interpret request boundaries differently.
Exploit preconditions
- Attack surface: HTTP/1.1 traffic handled by the Squid proxy
- Required access: A trusted client relationship or other ability to submit requests through the affected proxy
- Trigger point: HTTP header parsing and request-boundary processing for
Transfer-Encoding - Why exploitation is possible: Squid accepts a prohibited transfer-encoding form, which can cause it and another intermediary to disagree about where one request ends and the next begins
- Attack surface: HTTP/1.1 traffic handled by the Squid proxy
- Required access: A trusted client relationship or other ability to submit requests through the affected proxy
- Trigger point: HTTP header parsing and request-boundary processing for
Transfer-Encoding - Why exploitation is possible: Squid accepts a prohibited transfer-encoding form, which can cause it and another intermediary to disagree about where one request ends and the next begins
Why this happens
The vulnerability results from improper enforcement of the HTTP/1.1 transfer-encoding workflow. Squid accepted a bare Transfer-Encoding: identity form even though transfer codings must follow the protocol's required framing rules, creating inconsistent interpretations of message boundaries between HTTP components. This maps to CWE-444: Inconsistent Interpretation of HTTP Requests, commonly known as HTTP request smuggling.
The vulnerability results from improper enforcement of the HTTP/1.1 transfer-encoding workflow. Squid accepted a bare Transfer-Encoding: identity form even though transfer codings must follow the protocol's required framing rules, creating inconsistent interpretations of message boundaries between HTTP components. This maps to CWE-444: Inconsistent Interpretation of HTTP Requests, commonly known as HTTP request smuggling.
Potential impact
- Security controls between the client and Squid may be bypassed
- Requests could be misrouted or processed under unintended security contexts
- An upstream web cache could be poisoned with attacker-controlled content
- Malicious responses could be delivered to subsequent clients requesting affected URLs
- Backend services may receive unintended or desynchronized requests
- Security controls between the client and Squid may be bypassed
- Requests could be misrouted or processed under unintended security contexts
- An upstream web cache could be poisoned with attacker-controlled content
- Malicious responses could be delivered to subsequent clients requesting affected URLs
- Backend services may receive unintended or desynchronized requests
General mitigation guidance
Mitigation typically focuses on enforcing consistent, specification-compliant HTTP message framing across every intermediary.
Common defensive patterns include:
- Rejecting malformed or prohibited
Transfer-Encodingforms at the earliest boundary - Using strict, standards-compliant HTTP/1.1 parsing and unambiguous request delimiting
- Ensuring reverse proxies, caches, and backend servers apply compatible request parsing policies
- Separating or restricting trusted-client access to proxy submission interfaces
- Reducing cache poisoning impact through safe cache-key design, response validation, and controlled cacheability
- Applying least-privilege network and proxy policies so a compromised client cannot broadly reach sensitive upstream services
- Using vendor-provided security fixes and maintaining consistent patch governance across the proxy chain
Mitigation typically focuses on enforcing consistent, specification-compliant HTTP message framing across every intermediary.
Common defensive patterns include:
- Rejecting malformed or prohibited
Transfer-Encodingforms at the earliest boundary - Using strict, standards-compliant HTTP/1.1 parsing and unambiguous request delimiting
- Ensuring reverse proxies, caches, and backend servers apply compatible request parsing policies
- Separating or restricting trusted-client access to proxy submission interfaces
- Reducing cache poisoning impact through safe cache-key design, response validation, and controlled cacheability
- Applying least-privilege network and proxy policies so a compromised client cannot broadly reach sensitive upstream services
- Using vendor-provided security fixes and maintaining consistent patch governance across the proxy chain
How teams detect issues like this
Detection can combine protocol-aware testing with configuration and code review:
- Inspect HTTP proxy logs for malformed or unusual
Transfer-Encodingheaders and request-boundary anomalies - Test intermediary chains for disagreements in parsing transfer codings and message lengths
- Review parser logic for acceptance of prohibited syntax or fallback handling that changes request framing
- Use static analysis and security rules to flag inconsistent HTTP parsing and duplicate boundary interpretation
- Monitor cache behavior for unexpected content changes, anomalous cache fills, or responses associated with suspicious request patterns
- Enforce CI and deployment policies requiring standards-compliant HTTP parsing and regression tests for request smuggling cases
Detection can combine protocol-aware testing with configuration and code review:
- Inspect HTTP proxy logs for malformed or unusual
Transfer-Encodingheaders and request-boundary anomalies - Test intermediary chains for disagreements in parsing transfer codings and message lengths
- Review parser logic for acceptance of prohibited syntax or fallback handling that changes request framing
- Use static analysis and security rules to flag inconsistent HTTP parsing and duplicate boundary interpretation
- Monitor cache behavior for unexpected content changes, anomalous cache fills, or responses associated with suspicious request patterns
- Enforce CI and deployment policies requiring standards-compliant HTTP parsing and regression tests for request smuggling cases
