<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 06 Oct 2026 06:02:01 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-375472</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-375472</link>
      <description>EUVD-2026-375472</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-375472</guid>
    </item>
    <item>
      <title>fkie_cve-2026-48598</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-48598</link>
      <description>&lt;p&gt;Improper Encoding or Escaping of Output vulnerability in elixir-tesla tesla allows multipart part header injection via unescaped Content-Disposition parameter values.&lt;/p&gt;
&lt;p&gt;Tesla.Multipart.part_headers_for_disposition/1 interpolates each disposition parameter as #{k}=&amp;#34;#{v}&amp;#34; 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 &amp;#34; 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.&lt;/p&gt;
&lt;p&gt;This issue affects tesla: from 0.8.0 before 1.18.3.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Improper Encoding or Escaping of Output vulnerability in elixir-tesla tesla allows multipart part header injection via unescaped Content-Disposition parameter values.&lt;/p&gt;
&lt;p&gt;Tesla.Multipart.part_headers_for_disposition/1 interpolates each disposition parameter as #{k}=&amp;#34;#{v}&amp;#34; 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 &amp;#34; 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.&lt;/p&gt;
&lt;p&gt;This issue affects tesla: from 0.8.0 before 1.18.3.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-48598</guid>
    </item>
    <item>
      <title>GHSA-28jh-g32x-v9v4 — Tesla vulnerable to multipart part smuggling via unescaped `content-disposition` values</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-28jh-g32x-v9v4</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Hex: tesla&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;`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.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;`part_headers_for_disposition/1` in `lib/tesla/multipart.ex` formats each disposition parameter as `k=&amp;#34;v&amp;#34;` 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 `&amp;#34;` in the value closes the quoted parameter early, allowing extra `; key=&amp;#34;value&amp;#34;` 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;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…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Hex: tesla&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;`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.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;`part_headers_for_disposition/1` in `lib/tesla/multipart.ex` formats each disposition parameter as `k=&amp;#34;v&amp;#34;` 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 `&amp;#34;` in the value closes the quoted parameter early, allowing extra `; key=&amp;#34;value&amp;#34;` 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;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…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-28jh-g32x-v9v4</guid>
    </item>
  </channel>
</rss>
