tesla

Summary

Tesla.Multipart.part_headers_for_disposition/1 interpolates Content-Disposition parameter values (field name, filename, and other opts) verbatim into the part header line without encoding or escaping any special characters. An attacker who controls a filename, field name, or other disposition parameter can use unescaped double-quotes to inject extra disposition key-value pairs, or CRLF sequences to inject additional part headers or prepend bytes to the part body.

Details

part_headers_for_disposition/1 in lib/tesla/multipart.ex formats each disposition parameter as k="v" with no sanitization. Values flow in from add_field/4 (the name argument), add_file/3 and add_file_content/4 (the filename argument and any disposition opts). A " in the value closes the quoted parameter early, allowing extra ; key="value" pairs to be appended. A \r\n ends the Content-Disposition header line entirely, with subsequent bytes interpreted as additional part headers (e.g. a forged Content-Type); a second \r\n ends the whole part header block and prepends attacker bytes to the part body.

The default-filename path in add_file/3 derives the name via Path.basename/1, which does not strip CR or LF, so any code that forwards a partially attacker-controlled file path is equally vulnerable.

PoC

1. Call Tesla.Multipart.add_file_content/4 with a filename containing \r\nX-Injected: evil.
2. POST the multipart body to any upstream via any Tesla adapter.
3. The upstream receives X-Injected: evil as a standalone header line on the affected part.

Impact

Low severity (CVSS v4.0: 2.1). Any application using tesla 0.8.0 through 1.18.2 that passes untrusted input into add_field/4, add_file/3, or add_file_content/4 disposition parameters is affected. Consequences range from forging part-level headers to body prepending against lenient multipart parsers. Fixed in tesla 1.18.3.

Workarounds

Validate disposition parameter values before passing them to the multipart API, rejecting any value that contains \r, \n, or ".

Resources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/6ebfdb9abe9c6f119408045b933d82462decd351
• Patch commit: https://github.com/elixir-tesla/tesla/commit/bb1a2c3da2775924d96e3db8e315dcc4d5d2246e

Summary

In the Mint adapter for the Tesla HTTP client library, Tesla.Adapter.Mint.open_conn/2 passes the URL scheme of every outgoing request through String.to_atom/1 with no allow-list validation. Because BEAM atoms are permanent (never garbage-collected) and the atom table is bounded at roughly 1,048,576 entries, an attacker who can vary the URL scheme across requests can mint one fresh atom per request and eventually exhaust the table, crashing the VM.

Details

Vulnerable call (lib/tesla/adapter/mint.ex, open_conn/2): the scheme field parsed from the request URI is passed directly to String.to_atom/1 before being forwarded to Mint.HTTP.connect/4. Even though Mint raises for unrecognised schemes, the atom is already interned by that point. The function's HTTPS-branch guard confirms that no scheme normalisation occurs beforehand.

The attack surface has two entry points. First, any application-level URL-forwarding feature (webhook relay, link preview, SSRF-style proxy) where untrusted input reaches Tesla.get/2 or equivalent. Second, any pipeline that includes Tesla.Middleware.FollowRedirects: a server under the attacker's control can return a Location header with a novel scheme, triggering the atom creation on the redirect follow.

PoC

1. Stand up any application that accepts a user-supplied URL and forwards it through Tesla.Adapter.Mint.
2. Send requests to the application, each with a distinct, previously unseen URL scheme (e.g. atk1://, atk2://, ...).
3. Each request interns one new permanent atom; Mint rejects the connection but the atom persists.
4. After approximately 1,000,000 requests the BEAM atom table is exhausted and the VM crashes.

Impact

High severity (CVSS v4.0: 8.2). Any application using tesla 1.3.0 through 1.18.2 with Tesla.Adapter.Mint that allows untrusted input to influence request URLs is vulnerable to remote denial of service. No authentication or special privileges are required beyond access to the application's HTTP endpoint. Fixed in tesla 1.18.3.

Configurations

The application must use Tesla.Adapter.Mint and either expose a feature that forwards attacker-controlled URLs to Tesla, or include Tesla.Middleware.FollowRedirects in the middleware pipeline.

References

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/ccd0823d4ba37581a37d8f6108f9a81b263237ef
• Patch commit: https://github.com/elixir-tesla/tesla/commit/4699c3cb3e2fd6078f99f45f11cf7466aeedbf0e

Summary

Tesla.Middleware.FollowRedirects is meant to strip the Authorization header when following a cross-origin redirect, but performs the check with a case-sensitive comparison against the lowercase string "authorization". Because Tesla preserves header keys exactly as supplied by the caller, any application that sets the header with its RFC 7235 canonical casing ("Authorization") bypasses the filter entirely, leaking bearer tokens or other credentials to whatever origin the redirect points at.

Details

The filter list in lib/tesla/middleware/follow_redirects.ex is defined as @filter_headers ["authorization", "host"] and the membership check k not in @filter_headers compares the raw key string without case normalization. HTTP header names are case-insensitive per RFC 7230, but Tesla stores them verbatim. A header tuple {"Authorization", "Bearer …"} does not match "authorization", so it passes through the filter and is forwarded to the redirect destination unchecked. The same defect applies to the "Host" entry.

An attacker who can control a Location: response seen by the victim client (their own endpoint, a redirect-open service, or a compromised upstream) receives the credential on the cross-origin follow. No special configuration is required beyond the victim using the standard header casing.

PoC

1. Configure a Tesla client with Tesla.Middleware.FollowRedirects and set the Authorization header using canonical casing ({"Authorization", "Bearer <token>"}).
2. Make a request to an endpoint that returns a 302 redirect to a different origin.
3. Observe that the Authorization header with its value is present in the request delivered to the redirect destination.

Impact

High severity (CVSS v4.0: 8.2). Any application using tesla 1.4.0 through 1.18.2 with Tesla.Middleware.FollowRedirects and a non-lowercase Authorization header is affected. The workaround is to use all-lowercase "authorization" as the header key until upgrading to 1.18.3.

Workarounds

Normalize all header keys to lowercase before passing them to Tesla. Use "authorization" instead of "Authorization" when setting headers via Tesla.put_header/3 or Tesla.Middleware.Headers.

Resources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/2d937d5813d7cda5cd726f41824985fb655c920f
• Patch commit: https://github.com/elixir-tesla/tesla/commit/db963dba67651b9abd1fc420a1d9679cf6efe182

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

1. Serve an HTTP response with content-encoding: gzip, gzip, gzip, gzip where the body is a 1 GB block of zeros compressed through four successive gzip passes.
2. Send that response to a Tesla client whose pipeline includes Tesla.Middleware.DecompressResponse.
3. decompress_body/2 recurses four times without any size check, materialising ~1 GB in the calling process's heap.
4. 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

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/5bd90bb5cf0d15e375edc2a66fa322292940fce2
• Patch commit: https://github.com/elixir-tesla/tesla/commit/340f75b5d191dc747ef7ac6365bd002d1cd55a9d

Summary

Tesla.Multipart.add_content_type_param/2 appends caller-supplied strings to the multipart Content-Type header with no validation. A param value containing \r\n splits the header line, allowing an attacker who controls any content-type parameter (charset, boundary parameter, etc.) to inject arbitrary headers into the outbound HTTP request.

Details

add_content_type_param/2 in lib/tesla/multipart.ex stores the supplied string directly in multipart.content_type_params without any CR/LF check. headers/1 then joins all params with "; " and appends the result verbatim to the Content-Type header value. Because HTTP headers are delimited by \r\n, a param containing that sequence breaks out of the header field and introduces new header lines before the adapter writes the request to the socket.

The precondition is that untrusted input reaches add_content_type_param/2, which is the normal pattern for applications that accept user-supplied charset values, file type parameters, or any other content-type extension fields.

PoC

1. Call Tesla.Multipart.add_content_type_param/2 with a value containing \r\nX-Injected: pwned.
2. Pass the resulting Multipart struct as the request body via any Tesla adapter.
3. The raw request on the wire contains X-Injected: pwned as a standalone header line.

Impact

Low severity (CVSS v4.0: 2.1). Any application using tesla 0.8.0 through 1.18.2 that passes untrusted input into Tesla.Multipart.add_content_type_param/2 is affected. Consequences range from forging arbitrary outbound request headers to potential request smuggling against the upstream server. Fixed in tesla 1.18.3.

Workarounds

Validate content-type parameter strings before passing them to Tesla.Multipart.add_content_type_param/2, rejecting any value that contains \r or \n.

Reesources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/6ebfdb9abe9c6f119408045b933d82462decd351
• Patch commit: https://github.com/elixir-tesla/tesla/commit/23601edac5d22ba9407b427967b5bdbda201aec2

Summary

Tesla.Multipart.part_headers_for_disposition/1 interpolates Content-Disposition parameter values (field name, filename, and other opts) verbatim into the part header line without encoding or escaping any special characters. An attacker who controls a filename, field name, or other disposition parameter can use unescaped double-quotes to inject extra disposition key-value pairs, or CRLF sequences to inject additional part headers or prepend bytes to the part body.

Details

part_headers_for_disposition/1 in lib/tesla/multipart.ex formats each disposition parameter as k="v" with no sanitization. Values flow in from add_field/4 (the name argument), add_file/3 and add_file_content/4 (the filename argument and any disposition opts). A " in the value closes the quoted parameter early, allowing extra ; key="value" pairs to be appended. A \r\n ends the Content-Disposition header line entirely, with subsequent bytes interpreted as additional part headers (e.g. a forged Content-Type); a second \r\n ends the whole part header block and prepends attacker bytes to the part body.

The default-filename path in add_file/3 derives the name via Path.basename/1, which does not strip CR or LF, so any code that forwards a partially attacker-controlled file path is equally vulnerable.

PoC

1. Call Tesla.Multipart.add_file_content/4 with a filename containing \r\nX-Injected: evil.
2. POST the multipart body to any upstream via any Tesla adapter.
3. The upstream receives X-Injected: evil as a standalone header line on the affected part.

Impact

Low severity (CVSS v4.0: 2.1). Any application using tesla 0.8.0 through 1.18.2 that passes untrusted input into add_field/4, add_file/3, or add_file_content/4 disposition parameters is affected. Consequences range from forging part-level headers to body prepending against lenient multipart parsers. Fixed in tesla 1.18.3.

Workarounds

Validate disposition parameter values before passing them to the multipart API, rejecting any value that contains \r, \n, or ".

Resources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/6ebfdb9abe9c6f119408045b933d82462decd351
• Patch commit: https://github.com/elixir-tesla/tesla/commit/bb1a2c3da2775924d96e3db8e315dcc4d5d2246e

Summary

In the Mint adapter for the Tesla HTTP client library, Tesla.Adapter.Mint.open_conn/2 passes the URL scheme of every outgoing request through String.to_atom/1 with no allow-list validation. Because BEAM atoms are permanent (never garbage-collected) and the atom table is bounded at roughly 1,048,576 entries, an attacker who can vary the URL scheme across requests can mint one fresh atom per request and eventually exhaust the table, crashing the VM.

Details

Vulnerable call (lib/tesla/adapter/mint.ex, open_conn/2): the scheme field parsed from the request URI is passed directly to String.to_atom/1 before being forwarded to Mint.HTTP.connect/4. Even though Mint raises for unrecognised schemes, the atom is already interned by that point. The function's HTTPS-branch guard confirms that no scheme normalisation occurs beforehand.

The attack surface has two entry points. First, any application-level URL-forwarding feature (webhook relay, link preview, SSRF-style proxy) where untrusted input reaches Tesla.get/2 or equivalent. Second, any pipeline that includes Tesla.Middleware.FollowRedirects: a server under the attacker's control can return a Location header with a novel scheme, triggering the atom creation on the redirect follow.

PoC

1. Stand up any application that accepts a user-supplied URL and forwards it through Tesla.Adapter.Mint.
2. Send requests to the application, each with a distinct, previously unseen URL scheme (e.g. atk1://, atk2://, ...).
3. Each request interns one new permanent atom; Mint rejects the connection but the atom persists.
4. After approximately 1,000,000 requests the BEAM atom table is exhausted and the VM crashes.

Impact

High severity (CVSS v4.0: 8.2). Any application using tesla 1.3.0 through 1.18.2 with Tesla.Adapter.Mint that allows untrusted input to influence request URLs is vulnerable to remote denial of service. No authentication or special privileges are required beyond access to the application's HTTP endpoint. Fixed in tesla 1.18.3.

Configurations

The application must use Tesla.Adapter.Mint and either expose a feature that forwards attacker-controlled URLs to Tesla, or include Tesla.Middleware.FollowRedirects in the middleware pipeline.

References

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/ccd0823d4ba37581a37d8f6108f9a81b263237ef
• Patch commit: https://github.com/elixir-tesla/tesla/commit/4699c3cb3e2fd6078f99f45f11cf7466aeedbf0e

Summary

Tesla.Middleware.FollowRedirects is meant to strip the Authorization header when following a cross-origin redirect, but performs the check with a case-sensitive comparison against the lowercase string "authorization". Because Tesla preserves header keys exactly as supplied by the caller, any application that sets the header with its RFC 7235 canonical casing ("Authorization") bypasses the filter entirely, leaking bearer tokens or other credentials to whatever origin the redirect points at.

Details

The filter list in lib/tesla/middleware/follow_redirects.ex is defined as @filter_headers ["authorization", "host"] and the membership check k not in @filter_headers compares the raw key string without case normalization. HTTP header names are case-insensitive per RFC 7230, but Tesla stores them verbatim. A header tuple {"Authorization", "Bearer …"} does not match "authorization", so it passes through the filter and is forwarded to the redirect destination unchecked. The same defect applies to the "Host" entry.

An attacker who can control a Location: response seen by the victim client (their own endpoint, a redirect-open service, or a compromised upstream) receives the credential on the cross-origin follow. No special configuration is required beyond the victim using the standard header casing.

PoC

1. Configure a Tesla client with Tesla.Middleware.FollowRedirects and set the Authorization header using canonical casing ({"Authorization", "Bearer <token>"}).
2. Make a request to an endpoint that returns a 302 redirect to a different origin.
3. Observe that the Authorization header with its value is present in the request delivered to the redirect destination.

Impact

High severity (CVSS v4.0: 8.2). Any application using tesla 1.4.0 through 1.18.2 with Tesla.Middleware.FollowRedirects and a non-lowercase Authorization header is affected. The workaround is to use all-lowercase "authorization" as the header key until upgrading to 1.18.3.

Workarounds

Normalize all header keys to lowercase before passing them to Tesla. Use "authorization" instead of "Authorization" when setting headers via Tesla.put_header/3 or Tesla.Middleware.Headers.

Resources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/2d937d5813d7cda5cd726f41824985fb655c920f
• Patch commit: https://github.com/elixir-tesla/tesla/commit/db963dba67651b9abd1fc420a1d9679cf6efe182

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

1. Serve an HTTP response with content-encoding: gzip, gzip, gzip, gzip where the body is a 1 GB block of zeros compressed through four successive gzip passes.
2. Send that response to a Tesla client whose pipeline includes Tesla.Middleware.DecompressResponse.
3. decompress_body/2 recurses four times without any size check, materialising ~1 GB in the calling process's heap.
4. 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

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/5bd90bb5cf0d15e375edc2a66fa322292940fce2
• Patch commit: https://github.com/elixir-tesla/tesla/commit/340f75b5d191dc747ef7ac6365bd002d1cd55a9d

Summary

Tesla.Multipart.add_content_type_param/2 appends caller-supplied strings to the multipart Content-Type header with no validation. A param value containing \r\n splits the header line, allowing an attacker who controls any content-type parameter (charset, boundary parameter, etc.) to inject arbitrary headers into the outbound HTTP request.

Details

add_content_type_param/2 in lib/tesla/multipart.ex stores the supplied string directly in multipart.content_type_params without any CR/LF check. headers/1 then joins all params with "; " and appends the result verbatim to the Content-Type header value. Because HTTP headers are delimited by \r\n, a param containing that sequence breaks out of the header field and introduces new header lines before the adapter writes the request to the socket.

The precondition is that untrusted input reaches add_content_type_param/2, which is the normal pattern for applications that accept user-supplied charset values, file type parameters, or any other content-type extension fields.

PoC

1. Call Tesla.Multipart.add_content_type_param/2 with a value containing \r\nX-Injected: pwned.
2. Pass the resulting Multipart struct as the request body via any Tesla adapter.
3. The raw request on the wire contains X-Injected: pwned as a standalone header line.

Impact

Low severity (CVSS v4.0: 2.1). Any application using tesla 0.8.0 through 1.18.2 that passes untrusted input into Tesla.Multipart.add_content_type_param/2 is affected. Consequences range from forging arbitrary outbound request headers to potential request smuggling against the upstream server. Fixed in tesla 1.18.3.

Workarounds

Validate content-type parameter strings before passing them to Tesla.Multipart.add_content_type_param/2, rejecting any value that contains \r or \n.

Reesources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/6ebfdb9abe9c6f119408045b933d82462decd351
• Patch commit: https://github.com/elixir-tesla/tesla/commit/23601edac5d22ba9407b427967b5bdbda201aec2

Summary

Tesla.Multipart.part_headers_for_disposition/1 interpolates Content-Disposition parameter values (field name, filename, and other opts) verbatim into the part header line without encoding or escaping any special characters. An attacker who controls a filename, field name, or other disposition parameter can use unescaped double-quotes to inject extra disposition key-value pairs, or CRLF sequences to inject additional part headers or prepend bytes to the part body.

Details

part_headers_for_disposition/1 in lib/tesla/multipart.ex formats each disposition parameter as k="v" with no sanitization. Values flow in from add_field/4 (the name argument), add_file/3 and add_file_content/4 (the filename argument and any disposition opts). A " in the value closes the quoted parameter early, allowing extra ; key="value" pairs to be appended. A \r\n ends the Content-Disposition header line entirely, with subsequent bytes interpreted as additional part headers (e.g. a forged Content-Type); a second \r\n ends the whole part header block and prepends attacker bytes to the part body.

The default-filename path in add_file/3 derives the name via Path.basename/1, which does not strip CR or LF, so any code that forwards a partially attacker-controlled file path is equally vulnerable.

PoC

1. Call Tesla.Multipart.add_file_content/4 with a filename containing \r\nX-Injected: evil.
2. POST the multipart body to any upstream via any Tesla adapter.
3. The upstream receives X-Injected: evil as a standalone header line on the affected part.

Impact

Low severity (CVSS v4.0: 2.1). Any application using tesla 0.8.0 through 1.18.2 that passes untrusted input into add_field/4, add_file/3, or add_file_content/4 disposition parameters is affected. Consequences range from forging part-level headers to body prepending against lenient multipart parsers. Fixed in tesla 1.18.3.

Workarounds

Validate disposition parameter values before passing them to the multipart API, rejecting any value that contains \r, \n, or ".

Resources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/6ebfdb9abe9c6f119408045b933d82462decd351
• Patch commit: https://github.com/elixir-tesla/tesla/commit/bb1a2c3da2775924d96e3db8e315dcc4d5d2246e

Summary

In the Mint adapter for the Tesla HTTP client library, Tesla.Adapter.Mint.open_conn/2 passes the URL scheme of every outgoing request through String.to_atom/1 with no allow-list validation. Because BEAM atoms are permanent (never garbage-collected) and the atom table is bounded at roughly 1,048,576 entries, an attacker who can vary the URL scheme across requests can mint one fresh atom per request and eventually exhaust the table, crashing the VM.

Details

Vulnerable call (lib/tesla/adapter/mint.ex, open_conn/2): the scheme field parsed from the request URI is passed directly to String.to_atom/1 before being forwarded to Mint.HTTP.connect/4. Even though Mint raises for unrecognised schemes, the atom is already interned by that point. The function's HTTPS-branch guard confirms that no scheme normalisation occurs beforehand.

The attack surface has two entry points. First, any application-level URL-forwarding feature (webhook relay, link preview, SSRF-style proxy) where untrusted input reaches Tesla.get/2 or equivalent. Second, any pipeline that includes Tesla.Middleware.FollowRedirects: a server under the attacker's control can return a Location header with a novel scheme, triggering the atom creation on the redirect follow.

PoC

1. Stand up any application that accepts a user-supplied URL and forwards it through Tesla.Adapter.Mint.
2. Send requests to the application, each with a distinct, previously unseen URL scheme (e.g. atk1://, atk2://, ...).
3. Each request interns one new permanent atom; Mint rejects the connection but the atom persists.
4. After approximately 1,000,000 requests the BEAM atom table is exhausted and the VM crashes.

Impact

High severity (CVSS v4.0: 8.2). Any application using tesla 1.3.0 through 1.18.2 with Tesla.Adapter.Mint that allows untrusted input to influence request URLs is vulnerable to remote denial of service. No authentication or special privileges are required beyond access to the application's HTTP endpoint. Fixed in tesla 1.18.3.

Configurations

The application must use Tesla.Adapter.Mint and either expose a feature that forwards attacker-controlled URLs to Tesla, or include Tesla.Middleware.FollowRedirects in the middleware pipeline.

References

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/ccd0823d4ba37581a37d8f6108f9a81b263237ef
• Patch commit: https://github.com/elixir-tesla/tesla/commit/4699c3cb3e2fd6078f99f45f11cf7466aeedbf0e

Summary

Tesla.Middleware.FollowRedirects is meant to strip the Authorization header when following a cross-origin redirect, but performs the check with a case-sensitive comparison against the lowercase string "authorization". Because Tesla preserves header keys exactly as supplied by the caller, any application that sets the header with its RFC 7235 canonical casing ("Authorization") bypasses the filter entirely, leaking bearer tokens or other credentials to whatever origin the redirect points at.

Details

The filter list in lib/tesla/middleware/follow_redirects.ex is defined as @filter_headers ["authorization", "host"] and the membership check k not in @filter_headers compares the raw key string without case normalization. HTTP header names are case-insensitive per RFC 7230, but Tesla stores them verbatim. A header tuple {"Authorization", "Bearer …"} does not match "authorization", so it passes through the filter and is forwarded to the redirect destination unchecked. The same defect applies to the "Host" entry.

An attacker who can control a Location: response seen by the victim client (their own endpoint, a redirect-open service, or a compromised upstream) receives the credential on the cross-origin follow. No special configuration is required beyond the victim using the standard header casing.

PoC

1. Configure a Tesla client with Tesla.Middleware.FollowRedirects and set the Authorization header using canonical casing ({"Authorization", "Bearer <token>"}).
2. Make a request to an endpoint that returns a 302 redirect to a different origin.
3. Observe that the Authorization header with its value is present in the request delivered to the redirect destination.

Impact

High severity (CVSS v4.0: 8.2). Any application using tesla 1.4.0 through 1.18.2 with Tesla.Middleware.FollowRedirects and a non-lowercase Authorization header is affected. The workaround is to use all-lowercase "authorization" as the header key until upgrading to 1.18.3.

Workarounds

Normalize all header keys to lowercase before passing them to Tesla. Use "authorization" instead of "Authorization" when setting headers via Tesla.put_header/3 or Tesla.Middleware.Headers.

Resources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/2d937d5813d7cda5cd726f41824985fb655c920f
• Patch commit: https://github.com/elixir-tesla/tesla/commit/db963dba67651b9abd1fc420a1d9679cf6efe182

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

1. Serve an HTTP response with content-encoding: gzip, gzip, gzip, gzip where the body is a 1 GB block of zeros compressed through four successive gzip passes.
2. Send that response to a Tesla client whose pipeline includes Tesla.Middleware.DecompressResponse.
3. decompress_body/2 recurses four times without any size check, materialising ~1 GB in the calling process's heap.
4. 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

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/5bd90bb5cf0d15e375edc2a66fa322292940fce2
• Patch commit: https://github.com/elixir-tesla/tesla/commit/340f75b5d191dc747ef7ac6365bd002d1cd55a9d

Summary

Tesla.Multipart.add_content_type_param/2 appends caller-supplied strings to the multipart Content-Type header with no validation. A param value containing \r\n splits the header line, allowing an attacker who controls any content-type parameter (charset, boundary parameter, etc.) to inject arbitrary headers into the outbound HTTP request.

Details

add_content_type_param/2 in lib/tesla/multipart.ex stores the supplied string directly in multipart.content_type_params without any CR/LF check. headers/1 then joins all params with "; " and appends the result verbatim to the Content-Type header value. Because HTTP headers are delimited by \r\n, a param containing that sequence breaks out of the header field and introduces new header lines before the adapter writes the request to the socket.

The precondition is that untrusted input reaches add_content_type_param/2, which is the normal pattern for applications that accept user-supplied charset values, file type parameters, or any other content-type extension fields.

PoC

1. Call Tesla.Multipart.add_content_type_param/2 with a value containing \r\nX-Injected: pwned.
2. Pass the resulting Multipart struct as the request body via any Tesla adapter.
3. The raw request on the wire contains X-Injected: pwned as a standalone header line.

Impact

Low severity (CVSS v4.0: 2.1). Any application using tesla 0.8.0 through 1.18.2 that passes untrusted input into Tesla.Multipart.add_content_type_param/2 is affected. Consequences range from forging arbitrary outbound request headers to potential request smuggling against the upstream server. Fixed in tesla 1.18.3.

Workarounds

Validate content-type parameter strings before passing them to Tesla.Multipart.add_content_type_param/2, rejecting any value that contains \r or \n.

Reesources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/6ebfdb9abe9c6f119408045b933d82462decd351
• Patch commit: https://github.com/elixir-tesla/tesla/commit/23601edac5d22ba9407b427967b5bdbda201aec2

Summary

Tesla.Multipart.part_headers_for_disposition/1 interpolates Content-Disposition parameter values (field name, filename, and other opts) verbatim into the part header line without encoding or escaping any special characters. An attacker who controls a filename, field name, or other disposition parameter can use unescaped double-quotes to inject extra disposition key-value pairs, or CRLF sequences to inject additional part headers or prepend bytes to the part body.

Details

part_headers_for_disposition/1 in lib/tesla/multipart.ex formats each disposition parameter as k="v" with no sanitization. Values flow in from add_field/4 (the name argument), add_file/3 and add_file_content/4 (the filename argument and any disposition opts). A " in the value closes the quoted parameter early, allowing extra ; key="value" pairs to be appended. A \r\n ends the Content-Disposition header line entirely, with subsequent bytes interpreted as additional part headers (e.g. a forged Content-Type); a second \r\n ends the whole part header block and prepends attacker bytes to the part body.

The default-filename path in add_file/3 derives the name via Path.basename/1, which does not strip CR or LF, so any code that forwards a partially attacker-controlled file path is equally vulnerable.

PoC

1. Call Tesla.Multipart.add_file_content/4 with a filename containing \r\nX-Injected: evil.
2. POST the multipart body to any upstream via any Tesla adapter.
3. The upstream receives X-Injected: evil as a standalone header line on the affected part.

Impact

Low severity (CVSS v4.0: 2.1). Any application using tesla 0.8.0 through 1.18.2 that passes untrusted input into add_field/4, add_file/3, or add_file_content/4 disposition parameters is affected. Consequences range from forging part-level headers to body prepending against lenient multipart parsers. Fixed in tesla 1.18.3.

Workarounds

Validate disposition parameter values before passing them to the multipart API, rejecting any value that contains \r, \n, or ".

Resources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/6ebfdb9abe9c6f119408045b933d82462decd351
• Patch commit: https://github.com/elixir-tesla/tesla/commit/bb1a2c3da2775924d96e3db8e315dcc4d5d2246e

Summary

In the Mint adapter for the Tesla HTTP client library, Tesla.Adapter.Mint.open_conn/2 passes the URL scheme of every outgoing request through String.to_atom/1 with no allow-list validation. Because BEAM atoms are permanent (never garbage-collected) and the atom table is bounded at roughly 1,048,576 entries, an attacker who can vary the URL scheme across requests can mint one fresh atom per request and eventually exhaust the table, crashing the VM.

Details

Vulnerable call (lib/tesla/adapter/mint.ex, open_conn/2): the scheme field parsed from the request URI is passed directly to String.to_atom/1 before being forwarded to Mint.HTTP.connect/4. Even though Mint raises for unrecognised schemes, the atom is already interned by that point. The function's HTTPS-branch guard confirms that no scheme normalisation occurs beforehand.

The attack surface has two entry points. First, any application-level URL-forwarding feature (webhook relay, link preview, SSRF-style proxy) where untrusted input reaches Tesla.get/2 or equivalent. Second, any pipeline that includes Tesla.Middleware.FollowRedirects: a server under the attacker's control can return a Location header with a novel scheme, triggering the atom creation on the redirect follow.

PoC

1. Stand up any application that accepts a user-supplied URL and forwards it through Tesla.Adapter.Mint.
2. Send requests to the application, each with a distinct, previously unseen URL scheme (e.g. atk1://, atk2://, ...).
3. Each request interns one new permanent atom; Mint rejects the connection but the atom persists.
4. After approximately 1,000,000 requests the BEAM atom table is exhausted and the VM crashes.

Impact

High severity (CVSS v4.0: 8.2). Any application using tesla 1.3.0 through 1.18.2 with Tesla.Adapter.Mint that allows untrusted input to influence request URLs is vulnerable to remote denial of service. No authentication or special privileges are required beyond access to the application's HTTP endpoint. Fixed in tesla 1.18.3.

Configurations

The application must use Tesla.Adapter.Mint and either expose a feature that forwards attacker-controlled URLs to Tesla, or include Tesla.Middleware.FollowRedirects in the middleware pipeline.

References

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/ccd0823d4ba37581a37d8f6108f9a81b263237ef
• Patch commit: https://github.com/elixir-tesla/tesla/commit/4699c3cb3e2fd6078f99f45f11cf7466aeedbf0e

Summary

Tesla.Middleware.FollowRedirects is meant to strip the Authorization header when following a cross-origin redirect, but performs the check with a case-sensitive comparison against the lowercase string "authorization". Because Tesla preserves header keys exactly as supplied by the caller, any application that sets the header with its RFC 7235 canonical casing ("Authorization") bypasses the filter entirely, leaking bearer tokens or other credentials to whatever origin the redirect points at.

Details

The filter list in lib/tesla/middleware/follow_redirects.ex is defined as @filter_headers ["authorization", "host"] and the membership check k not in @filter_headers compares the raw key string without case normalization. HTTP header names are case-insensitive per RFC 7230, but Tesla stores them verbatim. A header tuple {"Authorization", "Bearer …"} does not match "authorization", so it passes through the filter and is forwarded to the redirect destination unchecked. The same defect applies to the "Host" entry.

An attacker who can control a Location: response seen by the victim client (their own endpoint, a redirect-open service, or a compromised upstream) receives the credential on the cross-origin follow. No special configuration is required beyond the victim using the standard header casing.

PoC

1. Configure a Tesla client with Tesla.Middleware.FollowRedirects and set the Authorization header using canonical casing ({"Authorization", "Bearer <token>"}).
2. Make a request to an endpoint that returns a 302 redirect to a different origin.
3. Observe that the Authorization header with its value is present in the request delivered to the redirect destination.

Impact

High severity (CVSS v4.0: 8.2). Any application using tesla 1.4.0 through 1.18.2 with Tesla.Middleware.FollowRedirects and a non-lowercase Authorization header is affected. The workaround is to use all-lowercase "authorization" as the header key until upgrading to 1.18.3.

Workarounds

Normalize all header keys to lowercase before passing them to Tesla. Use "authorization" instead of "Authorization" when setting headers via Tesla.put_header/3 or Tesla.Middleware.Headers.

Resources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/2d937d5813d7cda5cd726f41824985fb655c920f
• Patch commit: https://github.com/elixir-tesla/tesla/commit/db963dba67651b9abd1fc420a1d9679cf6efe182

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

1. Serve an HTTP response with content-encoding: gzip, gzip, gzip, gzip where the body is a 1 GB block of zeros compressed through four successive gzip passes.
2. Send that response to a Tesla client whose pipeline includes Tesla.Middleware.DecompressResponse.
3. decompress_body/2 recurses four times without any size check, materialising ~1 GB in the calling process's heap.
4. 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

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/5bd90bb5cf0d15e375edc2a66fa322292940fce2
• Patch commit: https://github.com/elixir-tesla/tesla/commit/340f75b5d191dc747ef7ac6365bd002d1cd55a9d

Summary

Tesla.Multipart.add_content_type_param/2 appends caller-supplied strings to the multipart Content-Type header with no validation. A param value containing \r\n splits the header line, allowing an attacker who controls any content-type parameter (charset, boundary parameter, etc.) to inject arbitrary headers into the outbound HTTP request.

Details

add_content_type_param/2 in lib/tesla/multipart.ex stores the supplied string directly in multipart.content_type_params without any CR/LF check. headers/1 then joins all params with "; " and appends the result verbatim to the Content-Type header value. Because HTTP headers are delimited by \r\n, a param containing that sequence breaks out of the header field and introduces new header lines before the adapter writes the request to the socket.

The precondition is that untrusted input reaches add_content_type_param/2, which is the normal pattern for applications that accept user-supplied charset values, file type parameters, or any other content-type extension fields.

PoC

1. Call Tesla.Multipart.add_content_type_param/2 with a value containing \r\nX-Injected: pwned.
2. Pass the resulting Multipart struct as the request body via any Tesla adapter.
3. The raw request on the wire contains X-Injected: pwned as a standalone header line.

Impact

Low severity (CVSS v4.0: 2.1). Any application using tesla 0.8.0 through 1.18.2 that passes untrusted input into Tesla.Multipart.add_content_type_param/2 is affected. Consequences range from forging arbitrary outbound request headers to potential request smuggling against the upstream server. Fixed in tesla 1.18.3.

Workarounds

Validate content-type parameter strings before passing them to Tesla.Multipart.add_content_type_param/2, rejecting any value that contains \r or \n.

Reesources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/6ebfdb9abe9c6f119408045b933d82462decd351
• Patch commit: https://github.com/elixir-tesla/tesla/commit/23601edac5d22ba9407b427967b5bdbda201aec2

Summary

Tesla.Multipart.part_headers_for_disposition/1 interpolates Content-Disposition parameter values (field name, filename, and other opts) verbatim into the part header line without encoding or escaping any special characters. An attacker who controls a filename, field name, or other disposition parameter can use unescaped double-quotes to inject extra disposition key-value pairs, or CRLF sequences to inject additional part headers or prepend bytes to the part body.

Details

part_headers_for_disposition/1 in lib/tesla/multipart.ex formats each disposition parameter as k="v" with no sanitization. Values flow in from add_field/4 (the name argument), add_file/3 and add_file_content/4 (the filename argument and any disposition opts). A " in the value closes the quoted parameter early, allowing extra ; key="value" pairs to be appended. A \r\n ends the Content-Disposition header line entirely, with subsequent bytes interpreted as additional part headers (e.g. a forged Content-Type); a second \r\n ends the whole part header block and prepends attacker bytes to the part body.

The default-filename path in add_file/3 derives the name via Path.basename/1, which does not strip CR or LF, so any code that forwards a partially attacker-controlled file path is equally vulnerable.

PoC

1. Call Tesla.Multipart.add_file_content/4 with a filename containing \r\nX-Injected: evil.
2. POST the multipart body to any upstream via any Tesla adapter.
3. The upstream receives X-Injected: evil as a standalone header line on the affected part.

Impact

Low severity (CVSS v4.0: 2.1). Any application using tesla 0.8.0 through 1.18.2 that passes untrusted input into add_field/4, add_file/3, or add_file_content/4 disposition parameters is affected. Consequences range from forging part-level headers to body prepending against lenient multipart parsers. Fixed in tesla 1.18.3.

Workarounds

Validate disposition parameter values before passing them to the multipart API, rejecting any value that contains \r, \n, or ".

Resources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/6ebfdb9abe9c6f119408045b933d82462decd351
• Patch commit: https://github.com/elixir-tesla/tesla/commit/bb1a2c3da2775924d96e3db8e315dcc4d5d2246e

Summary

In the Mint adapter for the Tesla HTTP client library, Tesla.Adapter.Mint.open_conn/2 passes the URL scheme of every outgoing request through String.to_atom/1 with no allow-list validation. Because BEAM atoms are permanent (never garbage-collected) and the atom table is bounded at roughly 1,048,576 entries, an attacker who can vary the URL scheme across requests can mint one fresh atom per request and eventually exhaust the table, crashing the VM.

Details

Vulnerable call (lib/tesla/adapter/mint.ex, open_conn/2): the scheme field parsed from the request URI is passed directly to String.to_atom/1 before being forwarded to Mint.HTTP.connect/4. Even though Mint raises for unrecognised schemes, the atom is already interned by that point. The function's HTTPS-branch guard confirms that no scheme normalisation occurs beforehand.

The attack surface has two entry points. First, any application-level URL-forwarding feature (webhook relay, link preview, SSRF-style proxy) where untrusted input reaches Tesla.get/2 or equivalent. Second, any pipeline that includes Tesla.Middleware.FollowRedirects: a server under the attacker's control can return a Location header with a novel scheme, triggering the atom creation on the redirect follow.

PoC

1. Stand up any application that accepts a user-supplied URL and forwards it through Tesla.Adapter.Mint.
2. Send requests to the application, each with a distinct, previously unseen URL scheme (e.g. atk1://, atk2://, ...).
3. Each request interns one new permanent atom; Mint rejects the connection but the atom persists.
4. After approximately 1,000,000 requests the BEAM atom table is exhausted and the VM crashes.

Impact

High severity (CVSS v4.0: 8.2). Any application using tesla 1.3.0 through 1.18.2 with Tesla.Adapter.Mint that allows untrusted input to influence request URLs is vulnerable to remote denial of service. No authentication or special privileges are required beyond access to the application's HTTP endpoint. Fixed in tesla 1.18.3.

Configurations

The application must use Tesla.Adapter.Mint and either expose a feature that forwards attacker-controlled URLs to Tesla, or include Tesla.Middleware.FollowRedirects in the middleware pipeline.

References

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/ccd0823d4ba37581a37d8f6108f9a81b263237ef
• Patch commit: https://github.com/elixir-tesla/tesla/commit/4699c3cb3e2fd6078f99f45f11cf7466aeedbf0e

Summary

Tesla.Middleware.FollowRedirects is meant to strip the Authorization header when following a cross-origin redirect, but performs the check with a case-sensitive comparison against the lowercase string "authorization". Because Tesla preserves header keys exactly as supplied by the caller, any application that sets the header with its RFC 7235 canonical casing ("Authorization") bypasses the filter entirely, leaking bearer tokens or other credentials to whatever origin the redirect points at.

Details

The filter list in lib/tesla/middleware/follow_redirects.ex is defined as @filter_headers ["authorization", "host"] and the membership check k not in @filter_headers compares the raw key string without case normalization. HTTP header names are case-insensitive per RFC 7230, but Tesla stores them verbatim. A header tuple {"Authorization", "Bearer …"} does not match "authorization", so it passes through the filter and is forwarded to the redirect destination unchecked. The same defect applies to the "Host" entry.

An attacker who can control a Location: response seen by the victim client (their own endpoint, a redirect-open service, or a compromised upstream) receives the credential on the cross-origin follow. No special configuration is required beyond the victim using the standard header casing.

PoC

1. Configure a Tesla client with Tesla.Middleware.FollowRedirects and set the Authorization header using canonical casing ({"Authorization", "Bearer <token>"}).
2. Make a request to an endpoint that returns a 302 redirect to a different origin.
3. Observe that the Authorization header with its value is present in the request delivered to the redirect destination.

Impact

High severity (CVSS v4.0: 8.2). Any application using tesla 1.4.0 through 1.18.2 with Tesla.Middleware.FollowRedirects and a non-lowercase Authorization header is affected. The workaround is to use all-lowercase "authorization" as the header key until upgrading to 1.18.3.

Workarounds

Normalize all header keys to lowercase before passing them to Tesla. Use "authorization" instead of "Authorization" when setting headers via Tesla.put_header/3 or Tesla.Middleware.Headers.

Resources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/2d937d5813d7cda5cd726f41824985fb655c920f
• Patch commit: https://github.com/elixir-tesla/tesla/commit/db963dba67651b9abd1fc420a1d9679cf6efe182

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

1. Serve an HTTP response with content-encoding: gzip, gzip, gzip, gzip where the body is a 1 GB block of zeros compressed through four successive gzip passes.
2. Send that response to a Tesla client whose pipeline includes Tesla.Middleware.DecompressResponse.
3. decompress_body/2 recurses four times without any size check, materialising ~1 GB in the calling process's heap.
4. 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

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/5bd90bb5cf0d15e375edc2a66fa322292940fce2
• Patch commit: https://github.com/elixir-tesla/tesla/commit/340f75b5d191dc747ef7ac6365bd002d1cd55a9d

Summary

Tesla.Multipart.add_content_type_param/2 appends caller-supplied strings to the multipart Content-Type header with no validation. A param value containing \r\n splits the header line, allowing an attacker who controls any content-type parameter (charset, boundary parameter, etc.) to inject arbitrary headers into the outbound HTTP request.

Details

add_content_type_param/2 in lib/tesla/multipart.ex stores the supplied string directly in multipart.content_type_params without any CR/LF check. headers/1 then joins all params with "; " and appends the result verbatim to the Content-Type header value. Because HTTP headers are delimited by \r\n, a param containing that sequence breaks out of the header field and introduces new header lines before the adapter writes the request to the socket.

The precondition is that untrusted input reaches add_content_type_param/2, which is the normal pattern for applications that accept user-supplied charset values, file type parameters, or any other content-type extension fields.

PoC

1. Call Tesla.Multipart.add_content_type_param/2 with a value containing \r\nX-Injected: pwned.
2. Pass the resulting Multipart struct as the request body via any Tesla adapter.
3. The raw request on the wire contains X-Injected: pwned as a standalone header line.

Impact

Low severity (CVSS v4.0: 2.1). Any application using tesla 0.8.0 through 1.18.2 that passes untrusted input into Tesla.Multipart.add_content_type_param/2 is affected. Consequences range from forging arbitrary outbound request headers to potential request smuggling against the upstream server. Fixed in tesla 1.18.3.

Workarounds

Validate content-type parameter strings before passing them to Tesla.Multipart.add_content_type_param/2, rejecting any value that contains \r or \n.

Reesources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/6ebfdb9abe9c6f119408045b933d82462decd351
• Patch commit: https://github.com/elixir-tesla/tesla/commit/23601edac5d22ba9407b427967b5bdbda201aec2

Summary

Tesla.Multipart.part_headers_for_disposition/1 interpolates Content-Disposition parameter values (field name, filename, and other opts) verbatim into the part header line without encoding or escaping any special characters. An attacker who controls a filename, field name, or other disposition parameter can use unescaped double-quotes to inject extra disposition key-value pairs, or CRLF sequences to inject additional part headers or prepend bytes to the part body.

Details

part_headers_for_disposition/1 in lib/tesla/multipart.ex formats each disposition parameter as k="v" with no sanitization. Values flow in from add_field/4 (the name argument), add_file/3 and add_file_content/4 (the filename argument and any disposition opts). A " in the value closes the quoted parameter early, allowing extra ; key="value" pairs to be appended. A \r\n ends the Content-Disposition header line entirely, with subsequent bytes interpreted as additional part headers (e.g. a forged Content-Type); a second \r\n ends the whole part header block and prepends attacker bytes to the part body.

The default-filename path in add_file/3 derives the name via Path.basename/1, which does not strip CR or LF, so any code that forwards a partially attacker-controlled file path is equally vulnerable.

PoC

1. Call Tesla.Multipart.add_file_content/4 with a filename containing \r\nX-Injected: evil.
2. POST the multipart body to any upstream via any Tesla adapter.
3. The upstream receives X-Injected: evil as a standalone header line on the affected part.

Impact

Low severity (CVSS v4.0: 2.1). Any application using tesla 0.8.0 through 1.18.2 that passes untrusted input into add_field/4, add_file/3, or add_file_content/4 disposition parameters is affected. Consequences range from forging part-level headers to body prepending against lenient multipart parsers. Fixed in tesla 1.18.3.

Workarounds

Validate disposition parameter values before passing them to the multipart API, rejecting any value that contains \r, \n, or ".

Resources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/6ebfdb9abe9c6f119408045b933d82462decd351
• Patch commit: https://github.com/elixir-tesla/tesla/commit/bb1a2c3da2775924d96e3db8e315dcc4d5d2246e

Summary

In the Mint adapter for the Tesla HTTP client library, Tesla.Adapter.Mint.open_conn/2 passes the URL scheme of every outgoing request through String.to_atom/1 with no allow-list validation. Because BEAM atoms are permanent (never garbage-collected) and the atom table is bounded at roughly 1,048,576 entries, an attacker who can vary the URL scheme across requests can mint one fresh atom per request and eventually exhaust the table, crashing the VM.

Details

Vulnerable call (lib/tesla/adapter/mint.ex, open_conn/2): the scheme field parsed from the request URI is passed directly to String.to_atom/1 before being forwarded to Mint.HTTP.connect/4. Even though Mint raises for unrecognised schemes, the atom is already interned by that point. The function's HTTPS-branch guard confirms that no scheme normalisation occurs beforehand.

The attack surface has two entry points. First, any application-level URL-forwarding feature (webhook relay, link preview, SSRF-style proxy) where untrusted input reaches Tesla.get/2 or equivalent. Second, any pipeline that includes Tesla.Middleware.FollowRedirects: a server under the attacker's control can return a Location header with a novel scheme, triggering the atom creation on the redirect follow.

PoC

1. Stand up any application that accepts a user-supplied URL and forwards it through Tesla.Adapter.Mint.
2. Send requests to the application, each with a distinct, previously unseen URL scheme (e.g. atk1://, atk2://, ...).
3. Each request interns one new permanent atom; Mint rejects the connection but the atom persists.
4. After approximately 1,000,000 requests the BEAM atom table is exhausted and the VM crashes.

Impact

High severity (CVSS v4.0: 8.2). Any application using tesla 1.3.0 through 1.18.2 with Tesla.Adapter.Mint that allows untrusted input to influence request URLs is vulnerable to remote denial of service. No authentication or special privileges are required beyond access to the application's HTTP endpoint. Fixed in tesla 1.18.3.

Configurations

The application must use Tesla.Adapter.Mint and either expose a feature that forwards attacker-controlled URLs to Tesla, or include Tesla.Middleware.FollowRedirects in the middleware pipeline.

References

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/ccd0823d4ba37581a37d8f6108f9a81b263237ef
• Patch commit: https://github.com/elixir-tesla/tesla/commit/4699c3cb3e2fd6078f99f45f11cf7466aeedbf0e

Summary

Tesla.Middleware.FollowRedirects is meant to strip the Authorization header when following a cross-origin redirect, but performs the check with a case-sensitive comparison against the lowercase string "authorization". Because Tesla preserves header keys exactly as supplied by the caller, any application that sets the header with its RFC 7235 canonical casing ("Authorization") bypasses the filter entirely, leaking bearer tokens or other credentials to whatever origin the redirect points at.

Details

The filter list in lib/tesla/middleware/follow_redirects.ex is defined as @filter_headers ["authorization", "host"] and the membership check k not in @filter_headers compares the raw key string without case normalization. HTTP header names are case-insensitive per RFC 7230, but Tesla stores them verbatim. A header tuple {"Authorization", "Bearer …"} does not match "authorization", so it passes through the filter and is forwarded to the redirect destination unchecked. The same defect applies to the "Host" entry.

An attacker who can control a Location: response seen by the victim client (their own endpoint, a redirect-open service, or a compromised upstream) receives the credential on the cross-origin follow. No special configuration is required beyond the victim using the standard header casing.

PoC

1. Configure a Tesla client with Tesla.Middleware.FollowRedirects and set the Authorization header using canonical casing ({"Authorization", "Bearer <token>"}).
2. Make a request to an endpoint that returns a 302 redirect to a different origin.
3. Observe that the Authorization header with its value is present in the request delivered to the redirect destination.

Impact

High severity (CVSS v4.0: 8.2). Any application using tesla 1.4.0 through 1.18.2 with Tesla.Middleware.FollowRedirects and a non-lowercase Authorization header is affected. The workaround is to use all-lowercase "authorization" as the header key until upgrading to 1.18.3.

Workarounds

Normalize all header keys to lowercase before passing them to Tesla. Use "authorization" instead of "Authorization" when setting headers via Tesla.put_header/3 or Tesla.Middleware.Headers.

Resources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/2d937d5813d7cda5cd726f41824985fb655c920f
• Patch commit: https://github.com/elixir-tesla/tesla/commit/db963dba67651b9abd1fc420a1d9679cf6efe182

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

1. Serve an HTTP response with content-encoding: gzip, gzip, gzip, gzip where the body is a 1 GB block of zeros compressed through four successive gzip passes.
2. Send that response to a Tesla client whose pipeline includes Tesla.Middleware.DecompressResponse.
3. decompress_body/2 recurses four times without any size check, materialising ~1 GB in the calling process's heap.
4. 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

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/5bd90bb5cf0d15e375edc2a66fa322292940fce2
• Patch commit: https://github.com/elixir-tesla/tesla/commit/340f75b5d191dc747ef7ac6365bd002d1cd55a9d

Summary

Tesla.Multipart.add_content_type_param/2 appends caller-supplied strings to the multipart Content-Type header with no validation. A param value containing \r\n splits the header line, allowing an attacker who controls any content-type parameter (charset, boundary parameter, etc.) to inject arbitrary headers into the outbound HTTP request.

Details

add_content_type_param/2 in lib/tesla/multipart.ex stores the supplied string directly in multipart.content_type_params without any CR/LF check. headers/1 then joins all params with "; " and appends the result verbatim to the Content-Type header value. Because HTTP headers are delimited by \r\n, a param containing that sequence breaks out of the header field and introduces new header lines before the adapter writes the request to the socket.

The precondition is that untrusted input reaches add_content_type_param/2, which is the normal pattern for applications that accept user-supplied charset values, file type parameters, or any other content-type extension fields.

PoC

1. Call Tesla.Multipart.add_content_type_param/2 with a value containing \r\nX-Injected: pwned.
2. Pass the resulting Multipart struct as the request body via any Tesla adapter.
3. The raw request on the wire contains X-Injected: pwned as a standalone header line.

Impact

Low severity (CVSS v4.0: 2.1). Any application using tesla 0.8.0 through 1.18.2 that passes untrusted input into Tesla.Multipart.add_content_type_param/2 is affected. Consequences range from forging arbitrary outbound request headers to potential request smuggling against the upstream server. Fixed in tesla 1.18.3.

Workarounds

Validate content-type parameter strings before passing them to Tesla.Multipart.add_content_type_param/2, rejecting any value that contains \r or \n.

Reesources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/6ebfdb9abe9c6f119408045b933d82462decd351
• Patch commit: https://github.com/elixir-tesla/tesla/commit/23601edac5d22ba9407b427967b5bdbda201aec2

Summary

Tesla.Multipart.part_headers_for_disposition/1 interpolates Content-Disposition parameter values (field name, filename, and other opts) verbatim into the part header line without encoding or escaping any special characters. An attacker who controls a filename, field name, or other disposition parameter can use unescaped double-quotes to inject extra disposition key-value pairs, or CRLF sequences to inject additional part headers or prepend bytes to the part body.

Details

part_headers_for_disposition/1 in lib/tesla/multipart.ex formats each disposition parameter as k="v" with no sanitization. Values flow in from add_field/4 (the name argument), add_file/3 and add_file_content/4 (the filename argument and any disposition opts). A " in the value closes the quoted parameter early, allowing extra ; key="value" pairs to be appended. A \r\n ends the Content-Disposition header line entirely, with subsequent bytes interpreted as additional part headers (e.g. a forged Content-Type); a second \r\n ends the whole part header block and prepends attacker bytes to the part body.

The default-filename path in add_file/3 derives the name via Path.basename/1, which does not strip CR or LF, so any code that forwards a partially attacker-controlled file path is equally vulnerable.

PoC

1. Call Tesla.Multipart.add_file_content/4 with a filename containing \r\nX-Injected: evil.
2. POST the multipart body to any upstream via any Tesla adapter.
3. The upstream receives X-Injected: evil as a standalone header line on the affected part.

Impact

Low severity (CVSS v4.0: 2.1). Any application using tesla 0.8.0 through 1.18.2 that passes untrusted input into add_field/4, add_file/3, or add_file_content/4 disposition parameters is affected. Consequences range from forging part-level headers to body prepending against lenient multipart parsers. Fixed in tesla 1.18.3.

Workarounds

Validate disposition parameter values before passing them to the multipart API, rejecting any value that contains \r, \n, or ".

Resources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/6ebfdb9abe9c6f119408045b933d82462decd351
• Patch commit: https://github.com/elixir-tesla/tesla/commit/bb1a2c3da2775924d96e3db8e315dcc4d5d2246e

Summary

In the Mint adapter for the Tesla HTTP client library, Tesla.Adapter.Mint.open_conn/2 passes the URL scheme of every outgoing request through String.to_atom/1 with no allow-list validation. Because BEAM atoms are permanent (never garbage-collected) and the atom table is bounded at roughly 1,048,576 entries, an attacker who can vary the URL scheme across requests can mint one fresh atom per request and eventually exhaust the table, crashing the VM.

Details

Vulnerable call (lib/tesla/adapter/mint.ex, open_conn/2): the scheme field parsed from the request URI is passed directly to String.to_atom/1 before being forwarded to Mint.HTTP.connect/4. Even though Mint raises for unrecognised schemes, the atom is already interned by that point. The function's HTTPS-branch guard confirms that no scheme normalisation occurs beforehand.

The attack surface has two entry points. First, any application-level URL-forwarding feature (webhook relay, link preview, SSRF-style proxy) where untrusted input reaches Tesla.get/2 or equivalent. Second, any pipeline that includes Tesla.Middleware.FollowRedirects: a server under the attacker's control can return a Location header with a novel scheme, triggering the atom creation on the redirect follow.

PoC

1. Stand up any application that accepts a user-supplied URL and forwards it through Tesla.Adapter.Mint.
2. Send requests to the application, each with a distinct, previously unseen URL scheme (e.g. atk1://, atk2://, ...).
3. Each request interns one new permanent atom; Mint rejects the connection but the atom persists.
4. After approximately 1,000,000 requests the BEAM atom table is exhausted and the VM crashes.

Impact

High severity (CVSS v4.0: 8.2). Any application using tesla 1.3.0 through 1.18.2 with Tesla.Adapter.Mint that allows untrusted input to influence request URLs is vulnerable to remote denial of service. No authentication or special privileges are required beyond access to the application's HTTP endpoint. Fixed in tesla 1.18.3.

Configurations

The application must use Tesla.Adapter.Mint and either expose a feature that forwards attacker-controlled URLs to Tesla, or include Tesla.Middleware.FollowRedirects in the middleware pipeline.

References

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/ccd0823d4ba37581a37d8f6108f9a81b263237ef
• Patch commit: https://github.com/elixir-tesla/tesla/commit/4699c3cb3e2fd6078f99f45f11cf7466aeedbf0e

Summary

Tesla.Middleware.FollowRedirects is meant to strip the Authorization header when following a cross-origin redirect, but performs the check with a case-sensitive comparison against the lowercase string "authorization". Because Tesla preserves header keys exactly as supplied by the caller, any application that sets the header with its RFC 7235 canonical casing ("Authorization") bypasses the filter entirely, leaking bearer tokens or other credentials to whatever origin the redirect points at.

Details

The filter list in lib/tesla/middleware/follow_redirects.ex is defined as @filter_headers ["authorization", "host"] and the membership check k not in @filter_headers compares the raw key string without case normalization. HTTP header names are case-insensitive per RFC 7230, but Tesla stores them verbatim. A header tuple {"Authorization", "Bearer …"} does not match "authorization", so it passes through the filter and is forwarded to the redirect destination unchecked. The same defect applies to the "Host" entry.

An attacker who can control a Location: response seen by the victim client (their own endpoint, a redirect-open service, or a compromised upstream) receives the credential on the cross-origin follow. No special configuration is required beyond the victim using the standard header casing.

PoC

1. Configure a Tesla client with Tesla.Middleware.FollowRedirects and set the Authorization header using canonical casing ({"Authorization", "Bearer <token>"}).
2. Make a request to an endpoint that returns a 302 redirect to a different origin.
3. Observe that the Authorization header with its value is present in the request delivered to the redirect destination.

Impact

High severity (CVSS v4.0: 8.2). Any application using tesla 1.4.0 through 1.18.2 with Tesla.Middleware.FollowRedirects and a non-lowercase Authorization header is affected. The workaround is to use all-lowercase "authorization" as the header key until upgrading to 1.18.3.

Workarounds

Normalize all header keys to lowercase before passing them to Tesla. Use "authorization" instead of "Authorization" when setting headers via Tesla.put_header/3 or Tesla.Middleware.Headers.

Resources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/2d937d5813d7cda5cd726f41824985fb655c920f
• Patch commit: https://github.com/elixir-tesla/tesla/commit/db963dba67651b9abd1fc420a1d9679cf6efe182

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

1. Serve an HTTP response with content-encoding: gzip, gzip, gzip, gzip where the body is a 1 GB block of zeros compressed through four successive gzip passes.
2. Send that response to a Tesla client whose pipeline includes Tesla.Middleware.DecompressResponse.
3. decompress_body/2 recurses four times without any size check, materialising ~1 GB in the calling process's heap.
4. 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

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/5bd90bb5cf0d15e375edc2a66fa322292940fce2
• Patch commit: https://github.com/elixir-tesla/tesla/commit/340f75b5d191dc747ef7ac6365bd002d1cd55a9d

Summary

Tesla.Multipart.add_content_type_param/2 appends caller-supplied strings to the multipart Content-Type header with no validation. A param value containing \r\n splits the header line, allowing an attacker who controls any content-type parameter (charset, boundary parameter, etc.) to inject arbitrary headers into the outbound HTTP request.

Details

add_content_type_param/2 in lib/tesla/multipart.ex stores the supplied string directly in multipart.content_type_params without any CR/LF check. headers/1 then joins all params with "; " and appends the result verbatim to the Content-Type header value. Because HTTP headers are delimited by \r\n, a param containing that sequence breaks out of the header field and introduces new header lines before the adapter writes the request to the socket.

The precondition is that untrusted input reaches add_content_type_param/2, which is the normal pattern for applications that accept user-supplied charset values, file type parameters, or any other content-type extension fields.

PoC

1. Call Tesla.Multipart.add_content_type_param/2 with a value containing \r\nX-Injected: pwned.
2. Pass the resulting Multipart struct as the request body via any Tesla adapter.
3. The raw request on the wire contains X-Injected: pwned as a standalone header line.

Impact

Low severity (CVSS v4.0: 2.1). Any application using tesla 0.8.0 through 1.18.2 that passes untrusted input into Tesla.Multipart.add_content_type_param/2 is affected. Consequences range from forging arbitrary outbound request headers to potential request smuggling against the upstream server. Fixed in tesla 1.18.3.

Workarounds

Validate content-type parameter strings before passing them to Tesla.Multipart.add_content_type_param/2, rejecting any value that contains \r or \n.

Reesources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/6ebfdb9abe9c6f119408045b933d82462decd351
• Patch commit: https://github.com/elixir-tesla/tesla/commit/23601edac5d22ba9407b427967b5bdbda201aec2

Summary

Tesla.Multipart.part_headers_for_disposition/1 interpolates Content-Disposition parameter values (field name, filename, and other opts) verbatim into the part header line without encoding or escaping any special characters. An attacker who controls a filename, field name, or other disposition parameter can use unescaped double-quotes to inject extra disposition key-value pairs, or CRLF sequences to inject additional part headers or prepend bytes to the part body.

Details

part_headers_for_disposition/1 in lib/tesla/multipart.ex formats each disposition parameter as k="v" with no sanitization. Values flow in from add_field/4 (the name argument), add_file/3 and add_file_content/4 (the filename argument and any disposition opts). A " in the value closes the quoted parameter early, allowing extra ; key="value" pairs to be appended. A \r\n ends the Content-Disposition header line entirely, with subsequent bytes interpreted as additional part headers (e.g. a forged Content-Type); a second \r\n ends the whole part header block and prepends attacker bytes to the part body.

The default-filename path in add_file/3 derives the name via Path.basename/1, which does not strip CR or LF, so any code that forwards a partially attacker-controlled file path is equally vulnerable.

PoC

1. Call Tesla.Multipart.add_file_content/4 with a filename containing \r\nX-Injected: evil.
2. POST the multipart body to any upstream via any Tesla adapter.
3. The upstream receives X-Injected: evil as a standalone header line on the affected part.

Impact

Low severity (CVSS v4.0: 2.1). Any application using tesla 0.8.0 through 1.18.2 that passes untrusted input into add_field/4, add_file/3, or add_file_content/4 disposition parameters is affected. Consequences range from forging part-level headers to body prepending against lenient multipart parsers. Fixed in tesla 1.18.3.

Workarounds

Validate disposition parameter values before passing them to the multipart API, rejecting any value that contains \r, \n, or ".

Resources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/6ebfdb9abe9c6f119408045b933d82462decd351
• Patch commit: https://github.com/elixir-tesla/tesla/commit/bb1a2c3da2775924d96e3db8e315dcc4d5d2246e

Summary

In the Mint adapter for the Tesla HTTP client library, Tesla.Adapter.Mint.open_conn/2 passes the URL scheme of every outgoing request through String.to_atom/1 with no allow-list validation. Because BEAM atoms are permanent (never garbage-collected) and the atom table is bounded at roughly 1,048,576 entries, an attacker who can vary the URL scheme across requests can mint one fresh atom per request and eventually exhaust the table, crashing the VM.

Details

Vulnerable call (lib/tesla/adapter/mint.ex, open_conn/2): the scheme field parsed from the request URI is passed directly to String.to_atom/1 before being forwarded to Mint.HTTP.connect/4. Even though Mint raises for unrecognised schemes, the atom is already interned by that point. The function's HTTPS-branch guard confirms that no scheme normalisation occurs beforehand.

The attack surface has two entry points. First, any application-level URL-forwarding feature (webhook relay, link preview, SSRF-style proxy) where untrusted input reaches Tesla.get/2 or equivalent. Second, any pipeline that includes Tesla.Middleware.FollowRedirects: a server under the attacker's control can return a Location header with a novel scheme, triggering the atom creation on the redirect follow.

PoC

1. Stand up any application that accepts a user-supplied URL and forwards it through Tesla.Adapter.Mint.
2. Send requests to the application, each with a distinct, previously unseen URL scheme (e.g. atk1://, atk2://, ...).
3. Each request interns one new permanent atom; Mint rejects the connection but the atom persists.
4. After approximately 1,000,000 requests the BEAM atom table is exhausted and the VM crashes.

Impact

High severity (CVSS v4.0: 8.2). Any application using tesla 1.3.0 through 1.18.2 with Tesla.Adapter.Mint that allows untrusted input to influence request URLs is vulnerable to remote denial of service. No authentication or special privileges are required beyond access to the application's HTTP endpoint. Fixed in tesla 1.18.3.

Configurations

The application must use Tesla.Adapter.Mint and either expose a feature that forwards attacker-controlled URLs to Tesla, or include Tesla.Middleware.FollowRedirects in the middleware pipeline.

References

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/ccd0823d4ba37581a37d8f6108f9a81b263237ef
• Patch commit: https://github.com/elixir-tesla/tesla/commit/4699c3cb3e2fd6078f99f45f11cf7466aeedbf0e

Summary

Tesla.Middleware.FollowRedirects is meant to strip the Authorization header when following a cross-origin redirect, but performs the check with a case-sensitive comparison against the lowercase string "authorization". Because Tesla preserves header keys exactly as supplied by the caller, any application that sets the header with its RFC 7235 canonical casing ("Authorization") bypasses the filter entirely, leaking bearer tokens or other credentials to whatever origin the redirect points at.

Details

The filter list in lib/tesla/middleware/follow_redirects.ex is defined as @filter_headers ["authorization", "host"] and the membership check k not in @filter_headers compares the raw key string without case normalization. HTTP header names are case-insensitive per RFC 7230, but Tesla stores them verbatim. A header tuple {"Authorization", "Bearer …"} does not match "authorization", so it passes through the filter and is forwarded to the redirect destination unchecked. The same defect applies to the "Host" entry.

An attacker who can control a Location: response seen by the victim client (their own endpoint, a redirect-open service, or a compromised upstream) receives the credential on the cross-origin follow. No special configuration is required beyond the victim using the standard header casing.

PoC

1. Configure a Tesla client with Tesla.Middleware.FollowRedirects and set the Authorization header using canonical casing ({"Authorization", "Bearer <token>"}).
2. Make a request to an endpoint that returns a 302 redirect to a different origin.
3. Observe that the Authorization header with its value is present in the request delivered to the redirect destination.

Impact

High severity (CVSS v4.0: 8.2). Any application using tesla 1.4.0 through 1.18.2 with Tesla.Middleware.FollowRedirects and a non-lowercase Authorization header is affected. The workaround is to use all-lowercase "authorization" as the header key until upgrading to 1.18.3.

Workarounds

Normalize all header keys to lowercase before passing them to Tesla. Use "authorization" instead of "Authorization" when setting headers via Tesla.put_header/3 or Tesla.Middleware.Headers.

Resources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/2d937d5813d7cda5cd726f41824985fb655c920f
• Patch commit: https://github.com/elixir-tesla/tesla/commit/db963dba67651b9abd1fc420a1d9679cf6efe182

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

1. Serve an HTTP response with content-encoding: gzip, gzip, gzip, gzip where the body is a 1 GB block of zeros compressed through four successive gzip passes.
2. Send that response to a Tesla client whose pipeline includes Tesla.Middleware.DecompressResponse.
3. decompress_body/2 recurses four times without any size check, materialising ~1 GB in the calling process's heap.
4. 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

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/5bd90bb5cf0d15e375edc2a66fa322292940fce2
• Patch commit: https://github.com/elixir-tesla/tesla/commit/340f75b5d191dc747ef7ac6365bd002d1cd55a9d

Summary

Tesla.Multipart.add_content_type_param/2 appends caller-supplied strings to the multipart Content-Type header with no validation. A param value containing \r\n splits the header line, allowing an attacker who controls any content-type parameter (charset, boundary parameter, etc.) to inject arbitrary headers into the outbound HTTP request.

Details

add_content_type_param/2 in lib/tesla/multipart.ex stores the supplied string directly in multipart.content_type_params without any CR/LF check. headers/1 then joins all params with "; " and appends the result verbatim to the Content-Type header value. Because HTTP headers are delimited by \r\n, a param containing that sequence breaks out of the header field and introduces new header lines before the adapter writes the request to the socket.

The precondition is that untrusted input reaches add_content_type_param/2, which is the normal pattern for applications that accept user-supplied charset values, file type parameters, or any other content-type extension fields.

PoC

1. Call Tesla.Multipart.add_content_type_param/2 with a value containing \r\nX-Injected: pwned.
2. Pass the resulting Multipart struct as the request body via any Tesla adapter.
3. The raw request on the wire contains X-Injected: pwned as a standalone header line.

Impact

Low severity (CVSS v4.0: 2.1). Any application using tesla 0.8.0 through 1.18.2 that passes untrusted input into Tesla.Multipart.add_content_type_param/2 is affected. Consequences range from forging arbitrary outbound request headers to potential request smuggling against the upstream server. Fixed in tesla 1.18.3.

Workarounds

Validate content-type parameter strings before passing them to Tesla.Multipart.add_content_type_param/2, rejecting any value that contains \r or \n.

Reesources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/6ebfdb9abe9c6f119408045b933d82462decd351
• Patch commit: https://github.com/elixir-tesla/tesla/commit/23601edac5d22ba9407b427967b5bdbda201aec2

Summary

Tesla.Multipart.part_headers_for_disposition/1 interpolates Content-Disposition parameter values (field name, filename, and other opts) verbatim into the part header line without encoding or escaping any special characters. An attacker who controls a filename, field name, or other disposition parameter can use unescaped double-quotes to inject extra disposition key-value pairs, or CRLF sequences to inject additional part headers or prepend bytes to the part body.

Details

part_headers_for_disposition/1 in lib/tesla/multipart.ex formats each disposition parameter as k="v" with no sanitization. Values flow in from add_field/4 (the name argument), add_file/3 and add_file_content/4 (the filename argument and any disposition opts). A " in the value closes the quoted parameter early, allowing extra ; key="value" pairs to be appended. A \r\n ends the Content-Disposition header line entirely, with subsequent bytes interpreted as additional part headers (e.g. a forged Content-Type); a second \r\n ends the whole part header block and prepends attacker bytes to the part body.

The default-filename path in add_file/3 derives the name via Path.basename/1, which does not strip CR or LF, so any code that forwards a partially attacker-controlled file path is equally vulnerable.

PoC

1. Call Tesla.Multipart.add_file_content/4 with a filename containing \r\nX-Injected: evil.
2. POST the multipart body to any upstream via any Tesla adapter.
3. The upstream receives X-Injected: evil as a standalone header line on the affected part.

Impact

Low severity (CVSS v4.0: 2.1). Any application using tesla 0.8.0 through 1.18.2 that passes untrusted input into add_field/4, add_file/3, or add_file_content/4 disposition parameters is affected. Consequences range from forging part-level headers to body prepending against lenient multipart parsers. Fixed in tesla 1.18.3.

Workarounds

Validate disposition parameter values before passing them to the multipart API, rejecting any value that contains \r, \n, or ".

Resources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/6ebfdb9abe9c6f119408045b933d82462decd351
• Patch commit: https://github.com/elixir-tesla/tesla/commit/bb1a2c3da2775924d96e3db8e315dcc4d5d2246e

Summary

In the Mint adapter for the Tesla HTTP client library, Tesla.Adapter.Mint.open_conn/2 passes the URL scheme of every outgoing request through String.to_atom/1 with no allow-list validation. Because BEAM atoms are permanent (never garbage-collected) and the atom table is bounded at roughly 1,048,576 entries, an attacker who can vary the URL scheme across requests can mint one fresh atom per request and eventually exhaust the table, crashing the VM.

Details

Vulnerable call (lib/tesla/adapter/mint.ex, open_conn/2): the scheme field parsed from the request URI is passed directly to String.to_atom/1 before being forwarded to Mint.HTTP.connect/4. Even though Mint raises for unrecognised schemes, the atom is already interned by that point. The function's HTTPS-branch guard confirms that no scheme normalisation occurs beforehand.

The attack surface has two entry points. First, any application-level URL-forwarding feature (webhook relay, link preview, SSRF-style proxy) where untrusted input reaches Tesla.get/2 or equivalent. Second, any pipeline that includes Tesla.Middleware.FollowRedirects: a server under the attacker's control can return a Location header with a novel scheme, triggering the atom creation on the redirect follow.

PoC

1. Stand up any application that accepts a user-supplied URL and forwards it through Tesla.Adapter.Mint.
2. Send requests to the application, each with a distinct, previously unseen URL scheme (e.g. atk1://, atk2://, ...).
3. Each request interns one new permanent atom; Mint rejects the connection but the atom persists.
4. After approximately 1,000,000 requests the BEAM atom table is exhausted and the VM crashes.

Impact

High severity (CVSS v4.0: 8.2). Any application using tesla 1.3.0 through 1.18.2 with Tesla.Adapter.Mint that allows untrusted input to influence request URLs is vulnerable to remote denial of service. No authentication or special privileges are required beyond access to the application's HTTP endpoint. Fixed in tesla 1.18.3.

Configurations

The application must use Tesla.Adapter.Mint and either expose a feature that forwards attacker-controlled URLs to Tesla, or include Tesla.Middleware.FollowRedirects in the middleware pipeline.

References

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/ccd0823d4ba37581a37d8f6108f9a81b263237ef
• Patch commit: https://github.com/elixir-tesla/tesla/commit/4699c3cb3e2fd6078f99f45f11cf7466aeedbf0e

Summary

Tesla.Middleware.FollowRedirects is meant to strip the Authorization header when following a cross-origin redirect, but performs the check with a case-sensitive comparison against the lowercase string "authorization". Because Tesla preserves header keys exactly as supplied by the caller, any application that sets the header with its RFC 7235 canonical casing ("Authorization") bypasses the filter entirely, leaking bearer tokens or other credentials to whatever origin the redirect points at.

Details

The filter list in lib/tesla/middleware/follow_redirects.ex is defined as @filter_headers ["authorization", "host"] and the membership check k not in @filter_headers compares the raw key string without case normalization. HTTP header names are case-insensitive per RFC 7230, but Tesla stores them verbatim. A header tuple {"Authorization", "Bearer …"} does not match "authorization", so it passes through the filter and is forwarded to the redirect destination unchecked. The same defect applies to the "Host" entry.

An attacker who can control a Location: response seen by the victim client (their own endpoint, a redirect-open service, or a compromised upstream) receives the credential on the cross-origin follow. No special configuration is required beyond the victim using the standard header casing.

PoC

1. Configure a Tesla client with Tesla.Middleware.FollowRedirects and set the Authorization header using canonical casing ({"Authorization", "Bearer <token>"}).
2. Make a request to an endpoint that returns a 302 redirect to a different origin.
3. Observe that the Authorization header with its value is present in the request delivered to the redirect destination.

Impact

High severity (CVSS v4.0: 8.2). Any application using tesla 1.4.0 through 1.18.2 with Tesla.Middleware.FollowRedirects and a non-lowercase Authorization header is affected. The workaround is to use all-lowercase "authorization" as the header key until upgrading to 1.18.3.

Workarounds

Normalize all header keys to lowercase before passing them to Tesla. Use "authorization" instead of "Authorization" when setting headers via Tesla.put_header/3 or Tesla.Middleware.Headers.

Resources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/2d937d5813d7cda5cd726f41824985fb655c920f
• Patch commit: https://github.com/elixir-tesla/tesla/commit/db963dba67651b9abd1fc420a1d9679cf6efe182

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

1. Serve an HTTP response with content-encoding: gzip, gzip, gzip, gzip where the body is a 1 GB block of zeros compressed through four successive gzip passes.
2. Send that response to a Tesla client whose pipeline includes Tesla.Middleware.DecompressResponse.
3. decompress_body/2 recurses four times without any size check, materialising ~1 GB in the calling process's heap.
4. 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

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/5bd90bb5cf0d15e375edc2a66fa322292940fce2
• Patch commit: https://github.com/elixir-tesla/tesla/commit/340f75b5d191dc747ef7ac6365bd002d1cd55a9d

Summary

Tesla.Multipart.add_content_type_param/2 appends caller-supplied strings to the multipart Content-Type header with no validation. A param value containing \r\n splits the header line, allowing an attacker who controls any content-type parameter (charset, boundary parameter, etc.) to inject arbitrary headers into the outbound HTTP request.

Details

add_content_type_param/2 in lib/tesla/multipart.ex stores the supplied string directly in multipart.content_type_params without any CR/LF check. headers/1 then joins all params with "; " and appends the result verbatim to the Content-Type header value. Because HTTP headers are delimited by \r\n, a param containing that sequence breaks out of the header field and introduces new header lines before the adapter writes the request to the socket.

The precondition is that untrusted input reaches add_content_type_param/2, which is the normal pattern for applications that accept user-supplied charset values, file type parameters, or any other content-type extension fields.

PoC

1. Call Tesla.Multipart.add_content_type_param/2 with a value containing \r\nX-Injected: pwned.
2. Pass the resulting Multipart struct as the request body via any Tesla adapter.
3. The raw request on the wire contains X-Injected: pwned as a standalone header line.

Impact

Low severity (CVSS v4.0: 2.1). Any application using tesla 0.8.0 through 1.18.2 that passes untrusted input into Tesla.Multipart.add_content_type_param/2 is affected. Consequences range from forging arbitrary outbound request headers to potential request smuggling against the upstream server. Fixed in tesla 1.18.3.

Workarounds

Validate content-type parameter strings before passing them to Tesla.Multipart.add_content_type_param/2, rejecting any value that contains \r or \n.

Reesources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/6ebfdb9abe9c6f119408045b933d82462decd351
• Patch commit: https://github.com/elixir-tesla/tesla/commit/23601edac5d22ba9407b427967b5bdbda201aec2

Summary

Tesla.Multipart.part_headers_for_disposition/1 interpolates Content-Disposition parameter values (field name, filename, and other opts) verbatim into the part header line without encoding or escaping any special characters. An attacker who controls a filename, field name, or other disposition parameter can use unescaped double-quotes to inject extra disposition key-value pairs, or CRLF sequences to inject additional part headers or prepend bytes to the part body.

Details

part_headers_for_disposition/1 in lib/tesla/multipart.ex formats each disposition parameter as k="v" with no sanitization. Values flow in from add_field/4 (the name argument), add_file/3 and add_file_content/4 (the filename argument and any disposition opts). A " in the value closes the quoted parameter early, allowing extra ; key="value" pairs to be appended. A \r\n ends the Content-Disposition header line entirely, with subsequent bytes interpreted as additional part headers (e.g. a forged Content-Type); a second \r\n ends the whole part header block and prepends attacker bytes to the part body.

The default-filename path in add_file/3 derives the name via Path.basename/1, which does not strip CR or LF, so any code that forwards a partially attacker-controlled file path is equally vulnerable.

PoC

1. Call Tesla.Multipart.add_file_content/4 with a filename containing \r\nX-Injected: evil.
2. POST the multipart body to any upstream via any Tesla adapter.
3. The upstream receives X-Injected: evil as a standalone header line on the affected part.

Impact

Low severity (CVSS v4.0: 2.1). Any application using tesla 0.8.0 through 1.18.2 that passes untrusted input into add_field/4, add_file/3, or add_file_content/4 disposition parameters is affected. Consequences range from forging part-level headers to body prepending against lenient multipart parsers. Fixed in tesla 1.18.3.

Workarounds

Validate disposition parameter values before passing them to the multipart API, rejecting any value that contains \r, \n, or ".

Resources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/6ebfdb9abe9c6f119408045b933d82462decd351
• Patch commit: https://github.com/elixir-tesla/tesla/commit/bb1a2c3da2775924d96e3db8e315dcc4d5d2246e

Summary

In the Mint adapter for the Tesla HTTP client library, Tesla.Adapter.Mint.open_conn/2 passes the URL scheme of every outgoing request through String.to_atom/1 with no allow-list validation. Because BEAM atoms are permanent (never garbage-collected) and the atom table is bounded at roughly 1,048,576 entries, an attacker who can vary the URL scheme across requests can mint one fresh atom per request and eventually exhaust the table, crashing the VM.

Details

Vulnerable call (lib/tesla/adapter/mint.ex, open_conn/2): the scheme field parsed from the request URI is passed directly to String.to_atom/1 before being forwarded to Mint.HTTP.connect/4. Even though Mint raises for unrecognised schemes, the atom is already interned by that point. The function's HTTPS-branch guard confirms that no scheme normalisation occurs beforehand.

The attack surface has two entry points. First, any application-level URL-forwarding feature (webhook relay, link preview, SSRF-style proxy) where untrusted input reaches Tesla.get/2 or equivalent. Second, any pipeline that includes Tesla.Middleware.FollowRedirects: a server under the attacker's control can return a Location header with a novel scheme, triggering the atom creation on the redirect follow.

PoC

1. Stand up any application that accepts a user-supplied URL and forwards it through Tesla.Adapter.Mint.
2. Send requests to the application, each with a distinct, previously unseen URL scheme (e.g. atk1://, atk2://, ...).
3. Each request interns one new permanent atom; Mint rejects the connection but the atom persists.
4. After approximately 1,000,000 requests the BEAM atom table is exhausted and the VM crashes.

Impact

High severity (CVSS v4.0: 8.2). Any application using tesla 1.3.0 through 1.18.2 with Tesla.Adapter.Mint that allows untrusted input to influence request URLs is vulnerable to remote denial of service. No authentication or special privileges are required beyond access to the application's HTTP endpoint. Fixed in tesla 1.18.3.

Configurations

The application must use Tesla.Adapter.Mint and either expose a feature that forwards attacker-controlled URLs to Tesla, or include Tesla.Middleware.FollowRedirects in the middleware pipeline.

References

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/ccd0823d4ba37581a37d8f6108f9a81b263237ef
• Patch commit: https://github.com/elixir-tesla/tesla/commit/4699c3cb3e2fd6078f99f45f11cf7466aeedbf0e

Summary

Tesla.Middleware.FollowRedirects is meant to strip the Authorization header when following a cross-origin redirect, but performs the check with a case-sensitive comparison against the lowercase string "authorization". Because Tesla preserves header keys exactly as supplied by the caller, any application that sets the header with its RFC 7235 canonical casing ("Authorization") bypasses the filter entirely, leaking bearer tokens or other credentials to whatever origin the redirect points at.

Details

The filter list in lib/tesla/middleware/follow_redirects.ex is defined as @filter_headers ["authorization", "host"] and the membership check k not in @filter_headers compares the raw key string without case normalization. HTTP header names are case-insensitive per RFC 7230, but Tesla stores them verbatim. A header tuple {"Authorization", "Bearer …"} does not match "authorization", so it passes through the filter and is forwarded to the redirect destination unchecked. The same defect applies to the "Host" entry.

An attacker who can control a Location: response seen by the victim client (their own endpoint, a redirect-open service, or a compromised upstream) receives the credential on the cross-origin follow. No special configuration is required beyond the victim using the standard header casing.

PoC

1. Configure a Tesla client with Tesla.Middleware.FollowRedirects and set the Authorization header using canonical casing ({"Authorization", "Bearer <token>"}).
2. Make a request to an endpoint that returns a 302 redirect to a different origin.
3. Observe that the Authorization header with its value is present in the request delivered to the redirect destination.

Impact

High severity (CVSS v4.0: 8.2). Any application using tesla 1.4.0 through 1.18.2 with Tesla.Middleware.FollowRedirects and a non-lowercase Authorization header is affected. The workaround is to use all-lowercase "authorization" as the header key until upgrading to 1.18.3.

Workarounds

Normalize all header keys to lowercase before passing them to Tesla. Use "authorization" instead of "Authorization" when setting headers via Tesla.put_header/3 or Tesla.Middleware.Headers.

Resources

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/2d937d5813d7cda5cd726f41824985fb655c920f
• Patch commit: https://github.com/elixir-tesla/tesla/commit/db963dba67651b9abd1fc420a1d9679cf6efe182

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

1. Serve an HTTP response with content-encoding: gzip, gzip, gzip, gzip where the body is a 1 GB block of zeros compressed through four successive gzip passes.
2. Send that response to a Tesla client whose pipeline includes Tesla.Middleware.DecompressResponse.
3. decompress_body/2 recurses four times without any size check, materialising ~1 GB in the calling process's heap.
4. 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

• Introduction commit: https://github.com/elixir-tesla/tesla/commit/5bd90bb5cf0d15e375edc2a66fa322292940fce2
• Patch commit: https://github.com/elixir-tesla/tesla/commit/340f75b5d191dc747ef7ac6365bd002d1cd55a9d