Tesla CVE-2026-48596

Two specific conditions must both be met: (1) the application uses Tesla's multipart functionality (Tesla.Multipart) and calls add_content_type_param/2 with data derived from untrusted external input - such as a user-supplied charset, boundary, or other content-type parameter string - rather than hardcoded values; and (2) the attacker can control that input to include CR (\r) or LF (\n) characters. The CVSS AT:P (Attack Requirements: Present) formally encodes condition (1) as a prerequisite. What limits exploitation: the vulnerable code path is specific to multipart request construction and is not triggered by ordinary Tesla HTTP usage; applications passing only hardcoded or internally generated content-type params are unaffected. The AV:L (local) scoring suggests the scoring authority treated the attack vector as application-local rather than network-reachable - real-world risk depends on whether user-supplied web input reaches add_content_type_param/2, which in exposed applications would effectively be a network-vector attack. The integrity impact is confined to downstream HTTP services receiving the injected headers (SI:L), not the Elixir application itself.

The CVSS 4.0 base score of 2.1 (Very Low) reflects a tightly constrained attack surface. AV:L (local attack vector) indicates the attacker must have some form of local influence over data flowing into the vulnerable function, and AT:P (attack requirements present) confirms a prerequisite condition - specifically, the application must route untrusted external input to add_content_type_param/2. PR:N/UI:N means no authentication or user interaction is required beyond that precondition. The impact metrics show zero confidentiality, integrity, or availability impact on the vulnerable system itself (VC:N/VI:N/VA:N) and only low integrity impact on subsequent downstream systems (SI:L), consistent with header injection affecting the receiving HTTP server rather than the Elixir application. There is no CISA KEV listing and no publicly identified POC at time of analysis, placing exploitation probability in the low-to-negligible range. The practical risk is contingent entirely on application design: libraries that accept and forward user-controlled charset or boundary parameters into multipart requests are exposed; those that only pass hardcoded or internally generated values are not. The AV:L classification warrants vendor verification - the description implies attacker-controlled web input flows into the library, which in many deployments would constitute a network-reachable attack surface, potentially underscoring the CVSS score.

An attacker submits an HTTP request to a web application containing a charset field set to a value like "utf-8\r\nX-Injected: pwned". The application reads this value from the request and passes it directly to Tesla.Multipart.add_content_type_param/2 when constructing an outbound multipart request to a backend API. Tesla.Multipart.headers/1 joins the params verbatim, producing a Content-Type header that splits at the CRLF, and the injected header "X-Injected: pwned" is transmitted to the downstream service - potentially bypassing security checks, poisoning caches, or manipulating backend logic that trusts specific custom headers. No public exploit code has been identified at time of analysis.