Описание
Tesla vulnerable to multipart part smuggling via unescaped content-disposition values
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
- Call
Tesla.Multipart.add_file_content/4with a filename containing\r\nX-Injected: evil. - POST the multipart body to any upstream via any Tesla adapter.
- The upstream receives
X-Injected: evilas 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
Ссылки
- https://github.com/elixir-tesla/tesla/security/advisories/GHSA-28jh-g32x-v9v4
- https://nvd.nist.gov/vuln/detail/CVE-2026-48598
- https://github.com/elixir-tesla/tesla/commit/bb1a2c3da2775924d96e3db8e315dcc4d5d2246e
- https://cna.erlef.org/cves/CVE-2026-48598.html
- https://osv.dev/vulnerability/EEF-CVE-2026-48598
Пакеты
tesla
>= 0.8.0, < 1.18.3
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
Improper Encoding or Escaping of Output vulnerability in elixir-tesla ...