OSV 1.4.0 · github-reviewed · 修改于 2026-07-10 08:03
发布时间
2026-07-10 08:03
GitHub 审查时间
2026-07-10 08:03
NVD 发布时间
2026-06-03 04:16
源文件
advisories/github-reviewed/2026/07/GHSA-mc85-72gr-vm9f/GHSA-mc85-72gr-vm9f.json
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.
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.
content-encoding: gzip, gzip, gzip, gzip where the body is a 1 GB block of zeros compressed through four successive gzip passes.Tesla.Middleware.DecompressResponse.decompress_body/2 recurses four times without any size check, materialising ~1 GB in the calling process's heap.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.
The application must include Tesla.Middleware.DecompressResponse or Tesla.Middleware.Compression in its Tesla middleware pipeline.