Description

In Progress® Telerik® Fiddler® Classic for Windows, versions prior to v6.0.20262.10021, HTTP request smuggling is possible in the proxy request forwarding component. Requests containing multiple Content-Length headers with conflicting values are forwarded verbatim to the origin server, while Fiddler frames the request body using only the first Content-Length value. A local threat actor with low privileges who is able to send requests through the same Fiddler proxy instance as another user can exploit this desynchronization against a non-RFC-9110-compliant origin server that keeps the connection alive to smuggle an additional request. Because Fiddler returns the server connection to its pipe pool after reading only the first response, the unread smuggled response remains buffered on the socket and is served to the next session that reuses that connection, allowing the attacker to poison responses delivered to other users and to obtain responses intended for them.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.3",
  "pubDate": "2026-10-05T13:16:54.293Z",
  "pubdate": "2026-10-05T13:16:54.293Z",
  "executiveSummary": "In Progress Telerik Fiddler Classic for Windows is vulnerable to HTTP request smuggling within its proxy request forwarding component. This vulnerability arises from improper handling of conflicting Content-Length headers, leading to request desynchronization between the proxy and the origin server.\nA local threat actor with low privileges who shares the same Fiddler proxy instance can exploit this flaw to perform cross-user request interference. By poisoning the proxy's connection pool, an attacker can manipulate responses returned to other users or intercept responses intended for them, compromising data confidentiality and integrity.\nThe vulnerability affects Telerik Fiddler Classic versions prior to v6.0.20262.10021. The impact is significant as it allows for unauthorized data access and session hijacking within the context of the proxy-managed connection lifecycle. Exploitation requires the attacker to send specially crafted HTTP requests through the same proxy instance utilized by a target user, targeting non-RFC-9110-compliant origin servers that maintain persistent connections.",
  "technicalDetails": "The vulnerability resides in the proxy request forwarding logic of Telerik Fiddler Classic. When Fiddler processes an HTTP request containing multiple Content-Length headers with conflicting values, it inconsistently interprets the request framing. Specifically, Fiddler frames the request body based solely on the first Content-Length value; however, it forwards the entire request, including all conflicting headers, verbatim to the downstream origin server.\nThis desynchronization occurs because the proxy and the origin server reach differing conclusions regarding the boundaries of the request body. If the origin server is not compliant with RFC-9110, it may interpret the request boundaries differently—for instance, by prioritizing a different header or failing to reject the malformed input. This mismatch leaves residual data from the smuggled request buffered on the socket connection.\nThe attack flow proceeds as follows: First, the attacker sends a crafted, malformed request through the Telerik Fiddler proxy. The proxy parses the first Content-Length header, consumes the intended body, and forwards the full request to the origin server. Because the origin server interprets the request length differently, the 'smuggled' portion of the request remains pending on the TCP socket after the origin server completes its processing.\nCrucially, Fiddler returns the connection to its internal pipe pool after reading only the response corresponding to the first, legitimate part of the request. The unread, smuggled request response remains in the server-side buffer. When a subsequent user sends a legitimate request via the same proxy instance, Fiddler reuses the polluted socket. The origin server then provides the response for the attacker's smuggled request as the initial data for the new, legitimate user's session.\nThis behavior facilitates two primary attack vectors: response poisoning, where a victim receives data intended for the attacker, or sensitive data exfiltration, where the attacker's subsequent requests retrieve the buffered response intended for the victim. The exploitation is restricted to environments where the attacker and target share a proxy instance, but the persistent nature of connection pooling makes it a viable mechanism for session-based information leakage."
}