CVE-2026-48598

Improper Encoding or Escaping of Output vulnerability in elixir-tesla tesla allows multipart part header injection via unescaped Content-Disposition parameter values.

Tesla.Multipart.part_headers_for_disposition/1 interpolates each disposition parameter as #{k}="#{v}" with no validation of CR (\r), LF (\n), or double-quote characters. The values come verbatim from the caller via Tesla.Multipart.add_field/4 (the name parameter), Tesla.Multipart.add_file/3, and Tesla.Multipart.add_file_content/4 (both the filename parameter and other disposition opts). A " in the value closes the quoted parameter early; a \r\n ends the Content-Disposition header line and starts a new part header (such as a forged Content-Type), or, after a second \r\n, ends the entire part header block and prepends bytes to the part body. The default-filename path in add_file/3 derives the filename via Path.basename/1, which does not strip CR or LF, so any application forwarding a partially-attacker-controlled file path inherits the same issue.

This issue affects tesla: from 0.8.0 before 1.18.3.

Improper Encoding or Escaping of Output vulnerability in elixir-tesla tesla allows multipart part header injection via unescaped Content-Disposition parameter values.

Tesla.Multipart.part_headers_for_disposition/1 interpolates each disposition parameter as #{k}="#{v}" with no validation of CR (\r), LF (\n), or double-quote characters. The values come verbatim from the caller via Tesla.Multipart.add_field/4 (the name parameter), Tesla.Multipart.add_file/3, and Tesla.Multipart.add_file_content/4 (both the filename parameter and other disposition opts). A " in the value closes the quoted parameter early; a \r\n ends the Content-Disposition header line and starts a new part header (such as a forged Content-Type), or, after a second \r\n, ends the entire part header block and prepends bytes to the part body. The default-filename path in add_file/3 derives the filename via Path.basename/1, which does not strip CR or LF, so any application forwarding a partially-attacker-controlled file path inherits the same issue.

This issue affects tesla: from 0.8.0 before 1.18.3.

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

Improper Encoding or Escaping of Output vulnerability in elixir-tesla tesla allows multipart part header injection via unescaped Content-Disposition parameter values.

Tesla.Multipart.part_headers_for_disposition/1 interpolates each disposition parameter as #{k}="#{v}" with no validation of CR (\r), LF (\n), or double-quote characters. The values come verbatim from the caller via Tesla.Multipart.add_field/4 (the name parameter), Tesla.Multipart.add_file/3, and Tesla.Multipart.add_file_content/4 (both the filename parameter and other disposition opts). A " in the value closes the quoted parameter early; a \r\n ends the Content-Disposition header line and starts a new part header (such as a forged Content-Type), or, after a second \r\n, ends the entire part header block and prepends bytes to the part body. The default-filename path in add_file/3 derives the filename via Path.basename/1, which does not strip CR or LF, so any application forwarding a partially-attacker-controlled file path inherits the same issue.

This issue affects tesla: from 0.8.0 before 1.18.3.

Improper Encoding or Escaping of Output vulnerability in elixir-tesla tesla allows multipart part header injection via unescaped Content-Disposition parameter values.

Tesla.Multipart.part_headers_for_disposition/1 interpolates each disposition parameter as #{k}="#{v}" with no validation of CR (\r), LF (\n), or double-quote characters. The values come verbatim from the caller via Tesla.Multipart.add_field/4 (the name parameter), Tesla.Multipart.add_file/3, and Tesla.Multipart.add_file_content/4 (both the filename parameter and other disposition opts). A " in the value closes the quoted parameter early; a \r\n ends the Content-Disposition header line and starts a new part header (such as a forged Content-Type), or, after a second \r\n, ends the entire part header block and prepends bytes to the part body. The default-filename path in add_file/3 derives the filename via Path.basename/1, which does not strip CR or LF, so any application forwarding a partially-attacker-controlled file path inherits the same issue.

This issue affects tesla: from 0.8.0 before 1.18.3.

Summary

Improper Encoding or Escaping of Output vulnerability in elixir-tesla tesla allows multipart part header injection via unescaped Content-Disposition parameter values.

Tesla.Multipart.part_headers_for_disposition/1 interpolates each disposition parameter as #{k}="#{v}" with no validation of CR (\r), LF (\n), or double-quote characters. The values come verbatim from the caller via Tesla.Multipart.add_field/4 (the name parameter), Tesla.Multipart.add_file/3, and Tesla.Multipart.add_file_content/4 (both the filename parameter and other disposition opts). A " in the value closes the quoted parameter early; a \r\n ends the Content-Disposition header line and starts a new part header (such as a forged Content-Type), or, after a second \r\n, ends the entire part header block and prepends bytes to the part body. The default-filename path in add_file/3 derives the filename via Path.basename/1, which does not strip CR or LF, so any application forwarding a partially-attacker-controlled file path inherits the same issue.

This issue affects tesla: from 0.8.0 before 1.18.3.

Workarounds

Validate disposition parameter values before passing them to Tesla.Multipart.add_field/4, Tesla.Multipart.add_file/3, or Tesla.Multipart.add_file_content/4, rejecting any value that contains \r, \n, or ".

Configurations

The application must pass untrusted input into a disposition parameter of Tesla.Multipart.add_field/4, Tesla.Multipart.add_file/3, or Tesla.Multipart.add_file_content/4.

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