Loading vulnerability details...
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.
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.
This high-severity vulnerability could allow attackers to gain unauthorized access, execute arbitrary code, or compromise data integrity. Prompt remediation is strongly recommended.
Probability of exploitation in the next 30 days · more likely than 51.7% of all CVEs.
Apply security patches to version 1.18.3 immediately
Isolate affected systems from untrusted networks until patching is complete
Implement enhanced monitoring for exploitation attempts and unusual behavior