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.

Affected: Hex: 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…