GHSA-28JH-G32X-V9V4

Vulnerability from github – Published: 2026-07-10 00:04 – Updated: 2026-07-10 00:04
VLAI
Summary
Tesla vulnerable to multipart part smuggling via unescaped `content-disposition` values
Details

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
Severity
2.1 (Low)
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Hex",
        "name": "tesla"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.8.0"
            },
            {
              "fixed": "1.18.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48598"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-10T00:04:37Z",
    "nvd_published_at": "2026-06-02T20:16:38Z",
    "severity": "LOW"
  },
  "details": "### Summary\n\n`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.\n\n### Details\n\n`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.\n\nThe 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.\n\n### PoC\n\n1. Call `Tesla.Multipart.add_file_content/4` with a filename containing `\\r\\nX-Injected: evil`.\n2. POST the multipart body to any upstream via any Tesla adapter.\n3. The upstream receives `X-Injected: evil` as a standalone header line on the affected part.\n\n### Impact\n\nLow 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.\n\n### Workarounds\n\nValidate disposition parameter values before passing them to the multipart API, rejecting any value that contains `\\r`, `\\n`, or `\"`.\n\n### Resources\n\n* Introduction commit: https://github.com/elixir-tesla/tesla/commit/6ebfdb9abe9c6f119408045b933d82462decd351\n* Patch commit: https://github.com/elixir-tesla/tesla/commit/bb1a2c3da2775924d96e3db8e315dcc4d5d2246e",
  "id": "GHSA-28jh-g32x-v9v4",
  "modified": "2026-07-10T00:04:37Z",
  "published": "2026-07-10T00:04:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/elixir-tesla/tesla/security/advisories/GHSA-28jh-g32x-v9v4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48598"
    },
    {
      "type": "WEB",
      "url": "https://github.com/elixir-tesla/tesla/commit/bb1a2c3da2775924d96e3db8e315dcc4d5d2246e"
    },
    {
      "type": "WEB",
      "url": "https://cna.erlef.org/cves/CVE-2026-48598.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/elixir-tesla/tesla"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/EEF-CVE-2026-48598"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Tesla vulnerable to multipart part smuggling via unescaped `content-disposition` values"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.