GHSA-mc85-72gr-vm9f — tesla
Fix: elixir-tesla/tesla@340f75bGHSA-mc85-72gr-vm9f is a CWE-409 vulnerability in tesla. A fix is available for tesla — see the affected versions and patch details below.
Tesla has decompression bomb on response body
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-mc85-72gr-vm9f.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
teslaReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Hex packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Any Tesla client pipeline that includes Tesla.Middleware.DecompressResponse or Tesla.Middleware.Compression eagerly decompresses HTTP response bodies with no size limit. A server under attacker control (or reached via a redirect) can return a tiny gzip-encoded payload that expands into gigabytes of BEAM heap, crashing or freezing the calling process. Stacking multiple content-encoding tokens multiplies the amplification exponentially.
Details
decompress_body/2 in lib/tesla/middleware/compression.ex passes the full response body to :zlib.gunzip/1 or :zlib.unzip/1 with no cap on output size. The list of codec tokens comes from splitting the content-encoding header on commas, and decompress_body/2 recurses once per token. A response advertising content-encoding: gzip, gzip, gzip, gzip triggers four recursive decompression passes. Each gzip layer can expand its input roughly 1000x, so a 284-byte wire payload with four layers inflates to approximately 1 GB at the innermost pass, all materialised as a single binary in the caller's heap.
PoC
- Serve an HTTP response with
content-encoding: gzip, gzip, gzip, gzipwhere the body is a 1 GB block of zeros compressed through four successive gzip passes. - Send that response to a Tesla client whose pipeline includes
Tesla.Middleware.DecompressResponse. decompress_body/2recurses four times without any size check, materialising ~1 GB in the calling process's heap.- Repeated or sufficiently large requests exhaust available memory and crash or freeze the node.
Impact
High severity (CVSS v4.0: 8.2). Any application using tesla 0.6.0 through 1.18.2 with Tesla.Middleware.DecompressResponse or Tesla.Middleware.Compression in its pipeline is vulnerable. The attacker only needs to control a server the client contacts, including via redirects. Fixed in tesla 1.18.3.
Configurations
The application must include Tesla.Middleware.DecompressResponse or Tesla.Middleware.Compression in its Tesla middleware pipeline.
Resources
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💧Hex | tesla | ≥ 0.6.0&&< 1.18.3 | 1.18.3mix deps.update tesla |
Affected Products
teslaelixir-teslaDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for tesla, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update tesla to 1.18.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-mc85-72gr-vm9f 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.
Frequently Asked Questions
Is GHSA-mc85-72gr-vm9f in your dependencies?
Find it across Hex, including transitive dependencies.