CVE-2026-61541: Zapros has an Unbounded Content-Encoding decompression chain that allows denial of service
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Zapros (Python HTTP client)to a version that resolves this vulnerability.Fixed in 0.14.0 - Configuration
As a workaround, add response middleware that inspects the `Content-Encoding` header and rejects responses containing more than a safe number of encoding layers; the patched behavior in Zapros v0.14.0 limits responses to five content-encoding layers.
Zapros application response handling Content-Encoding layer limit = max 5 layers (reject when exceeded) - Compensating control
Ensure Zapros is not used to fetch from untrusted servers or to follow redirects to untrusted servers when possible, since the denial of service occurs when an application requests content from an untrusted server or follows a redirect to one.
Event History
Frequently Asked Questions
Which applications are exposed to this denial-of-service condition?
Applications using Zapros before 0.14.0 are exposed when they request content from an untrusted server or follow a redirect to one. A malicious server can return a response with an excessive chain of Content-Encoding values.
What does the fixed version change?
Zapros 0.14.0 limits responses to five Content-Encoding layers. It raises DecodingError when a response exceeds that limit.
How can this be mitigated before upgrading?
Add response middleware that inspects the Content-Encoding header and rejects responses with more than a safe number of encoding layers.