CVE-2026-77803 in Telerik Fiddler Classic
Summary
by MITRE • 10/05/2026
In Progress® Telerik® Fiddler® Classic for Windows, versions prior to v6.0.20262.10021, front-end request desynchronization is possible in the proxy request forwarding component. A request that contains both a Content-Length and a Transfer-Encoding header is forwarded with both headers present, while Fiddler frames the body using Transfer-Encoding only. The remaining bytes on the reused client connection are then parsed as a separate pipelined request, so a local threat actor with low privileges can cause a single malformed request to be split into two requests forwarded to the origin server and receive an additional smuggled response, without requiring a vulnerable server.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/05/2026
The vulnerability identified in Progress Telerik Fiddler Classic for Windows prior to version 6.0.20262.10021 represents a critical flaw within the proxy request forwarding component, specifically manifesting as an HTTP Request Smuggling issue driven by front-end desynchronization. This defect arises from inconsistent handling of conflicting HTTP headers during the processing and relaying of client requests to origin servers. In standard HTTP protocol operations, when both Content-Length and Transfer-Encoding headers are present in a single request, they create ambiguity regarding how the message body should be interpreted. The Common Weakness Enumeration classifies this type of vulnerability under CWE-436, which denotes Interpretation Conflict, as different components or parsers may interpret these conflicting instructions differently, leading to divergent behaviors between the client and the server.
Technically, the flaw occurs because Fiddler forwards a request containing both Content-Length and Transfer-Encoding headers with both headers intact, yet it frames the body using only the Transfer-Encoding directive for its internal processing logic. This discrepancy creates a state mismatch where the proxy application treats one portion of the data as part of the current transaction while leaving residual bytes on the reused client connection unprocessed within that context. Because HTTP/1.1 connections are often kept alive and reused for multiple requests, these remaining bytes do not disappear but instead remain in the input buffer. The proxy subsequently interprets this leftover data as a separate, pipelined request rather than discarding it or handling it correctly. This behavior allows an attacker to inject additional commands into the stream that appear to be part of subsequent legitimate traffic.
The operational impact of this vulnerability is significant because it enables HTTP Request Smuggling without requiring the origin server itself to be vulnerable. Typically, successful smuggling attacks depend on a mismatch between how a front-end proxy and a back-end server parse requests. However, in this scenario, the desynchronization occurs entirely within Fiddler’s own processing logic before the request reaches the backend. A local threat actor with low privileges can exploit this by crafting a single malformed HTTP request that triggers the split behavior. The result is that one incoming request is effectively divided into two distinct requests forwarded to the origin server. This manipulation allows the attacker to bypass access controls, inject unauthorized commands, or potentially exfiltrate sensitive data by controlling how subsequent responses are associated with specific client interactions.
This vulnerability aligns closely with MITRE ATT&CK technique T1071.004, Application Layer Protocol: Web Protocols, specifically involving request smuggling mechanisms that exploit protocol ambiguities to bypass security controls. The ability of a low-privilege user to manipulate proxy behavior highlights the importance of strict input validation and consistent header handling in intermediary software. Mitigation strategies primarily involve upgrading to version 6.0.20262.10021 or later, where this desynchronization issue has been resolved by ensuring that conflicting headers are handled consistently with RFC standards, thereby preventing the residual byte interpretation as pipelined requests. Until such an update is applied, organizations should consider restricting network access to Fiddler instances and monitoring for anomalous HTTP traffic patterns indicative of smuggling attempts within their internal proxy logs.