CVE-2026-61541 in Zapros
Summary
by MITRE • 09/22/2026
Zapros, a Python HTTP client, prior to version 0.14.0 is vulnerable to denial of service when an application requests content from an untrusted server, or follows a redirect to one, because a malicious response containing an excessive number of chained `Content-Encoding` values causes Zapros to construct a deeply nested decompression chain that consumes excessive resources. Version 0.14.0 patches the vulnerability by limiting responses to five content-encoding layers and raising `DecodingError` when that limit is exceeded. As a workaround, applications can add response middleware that inspects the `Content-Encoding` header and rejects responses containing more than a safe number of encoding layers.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The Zapros Python HTTP client library contains a critical vulnerability in versions prior to 0.14.0 that allows for denial of service attacks through resource exhaustion. This flaw arises from the way the library handles multiple chained Content-Encoding headers within HTTP responses. When an application using Zapros requests content from an untrusted server or follows a redirect to such a server, it may receive a response containing an excessive number of nested encoding layers. Instead of processing these encodings efficiently or rejecting them early in the pipeline, the vulnerable implementation constructs a deeply nested decompression chain. This recursive handling of each encoding layer consumes significant CPU and memory resources as the depth increases, potentially leading to application crashes or severe performance degradation that effectively denies service to legitimate users.
The technical root cause lies in the lack of bounds checking on the number of Content-Encoding transformations applied during response processing. In a typical HTTP scenario, content may be compressed using algorithms like gzip or deflate, and sometimes multiple layers are stacked for specific reasons. However, when an attacker controls the server-side response, they can craft a malicious payload with dozens or even hundreds of chained encodings. As Zapros attempts to decompress each layer sequentially by wrapping previous results in new decoder objects, it creates a deep call stack that rapidly exhausts system resources. This behavior aligns with CWE-400, which describes uncontrolled resource consumption vulnerabilities where an attacker can trigger excessive allocation or processing without adequate limits.
The operational impact of this vulnerability is primarily focused on availability rather than confidentiality or integrity. An adversary who can force a victim application to fetch data from a malicious server can cause the Zapros instance to hang indefinitely or crash due to stack overflow or memory exhaustion. This is particularly dangerous in environments where HTTP clients are used for web scraping, API integration with third-party services, or any scenario involving user-controlled URLs that might redirect to untrusted destinations. The attack does not require authentication and can be executed remotely over the network, making it a straightforward vector for disrupting service availability.
To mitigate this risk, developers should upgrade Zapros to version 0.14.0 or later, which implements a hard limit on the number of content-encoding layers allowed in a single response. The patched version restricts processing to five encoding layers and raises a DecodingError if this threshold is exceeded, thereby preventing the construction of deeply nested chains that lead to resource exhaustion. For applications unable to upgrade immediately, a recommended workaround involves implementing custom response middleware. This middleware should inspect the Content-Encoding header of incoming responses before they are processed by the core library logic. If the number of encoding values exceeds a safe predefined threshold, such as five or ten layers depending on specific use cases, the middleware can reject the response early, thus avoiding the expensive decompression operations entirely and preserving system stability until an upgrade is feasible.