GHSA-28jh-g32x-v9v4

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...