<?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>Sun, 18 Oct 2026 18:44:06 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-209348</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-209348</link>
      <description>EUVD-2026-209348</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-209348</guid>
    </item>
    <item>
      <title>fkie_cve-2025-21620</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-21620</link>
      <description>&lt;p&gt;Deno is a JavaScript, TypeScript, and WebAssembly runtime with secure defaults. When you send a request with the Authorization header to one domain, and the response asks to redirect to a different domain, Deno&amp;#39;sfetch() redirect handling creates a follow-up redirect request that keeps the original Authorization header, leaking its content to that second domain. This vulnerability is fixed in 2.1.2.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Deno is a JavaScript, TypeScript, and WebAssembly runtime with secure defaults. When you send a request with the Authorization header to one domain, and the response asks to redirect to a different domain, Deno&amp;#39;sfetch() redirect handling creates a follow-up redirect request that keeps the original Authorization header, leaking its content to that second domain. This vulnerability is fixed in 2.1.2.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-21620</guid>
    </item>
    <item>
      <title>GHSA-f27p-cmv8-xhm6 — fetch: Authorization headers not dropped when redirecting cross-origin</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-f27p-cmv8-xhm6</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: deno_fetch, crates.io: deno&lt;/p&gt;
&lt;p&gt;### Summary
When you send a request with the `Authorization` header to one domain, and the response asks to redirect to a different domain, Deno&amp;#39;s`fetch()` redirect handling creates a follow-up redirect request that keeps the original `Authorization` header, leaking its content to that second domain.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The [right behavior](https://fetch.spec.whatwg.org/#ref-for-cors-non-wildcard-request-header-name) would be to drop the `Authorization` header instead, in this scenario. The same is generally applied to `Cookie` and `Proxy-Authorization` headers, and is done for not only host changes, but also protocol/port changes. Generally referred to as &amp;#34;origin&amp;#34;.&lt;/p&gt;
&lt;p&gt;The [documentation](https://docs.deno.com/runtime/reference/web_platform_apis/#:~:text=Deno%20does%20not%20follow%20the,leaking%20authenticated%20data%20cross%20origin.) states: 
&amp;gt; Deno does not follow the same-origin policy, because the Deno user agent currently does not have the concept of origins, and it does not have a cookie jar. This means Deno **does not need** to protect against leaking authenticated data cross origin&lt;/p&gt;
&lt;p&gt;### Reproduction
```ts
const ac = new AbortController()&lt;/p&gt;
&lt;p&gt;const server1 = Deno.serve({ port: 3001, signal: ac.signal }, (req) =&amp;gt; {
  return new Response(null, {
    status: 302,
    headers: {
      &amp;#39;location&amp;#39;: &amp;#39;http://localhost:3002/redirected&amp;#39;
    },
  })
})&lt;/p&gt;
&lt;p&gt;const server2 = Deno.serve({ port: 3002, signal: ac.signal }, (req) =&amp;gt; {
  const body = JSON.stringify({
    url: req.url,
    hasAuth:…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: deno_fetch, crates.io: deno&lt;/p&gt;
&lt;p&gt;### Summary
When you send a request with the `Authorization` header to one domain, and the response asks to redirect to a different domain, Deno&amp;#39;s`fetch()` redirect handling creates a follow-up redirect request that keeps the original `Authorization` header, leaking its content to that second domain.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The [right behavior](https://fetch.spec.whatwg.org/#ref-for-cors-non-wildcard-request-header-name) would be to drop the `Authorization` header instead, in this scenario. The same is generally applied to `Cookie` and `Proxy-Authorization` headers, and is done for not only host changes, but also protocol/port changes. Generally referred to as &amp;#34;origin&amp;#34;.&lt;/p&gt;
&lt;p&gt;The [documentation](https://docs.deno.com/runtime/reference/web_platform_apis/#:~:text=Deno%20does%20not%20follow%20the,leaking%20authenticated%20data%20cross%20origin.) states: 
&amp;gt; Deno does not follow the same-origin policy, because the Deno user agent currently does not have the concept of origins, and it does not have a cookie jar. This means Deno **does not need** to protect against leaking authenticated data cross origin&lt;/p&gt;
&lt;p&gt;### Reproduction
```ts
const ac = new AbortController()&lt;/p&gt;
&lt;p&gt;const server1 = Deno.serve({ port: 3001, signal: ac.signal }, (req) =&amp;gt; {
  return new Response(null, {
    status: 302,
    headers: {
      &amp;#39;location&amp;#39;: &amp;#39;http://localhost:3002/redirected&amp;#39;
    },
  })
})&lt;/p&gt;
&lt;p&gt;const server2 = Deno.serve({ port: 3002, signal: ac.signal }, (req) =&amp;gt; {
  const body = JSON.stringify({
    url: req.url,
    hasAuth:…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-f27p-cmv8-xhm6</guid>
    </item>
  </channel>
</rss>
