<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-07T01:53:43.001568+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-322099</id>
    <title>EUVD-2026-322099</title>
    <updated>2026-10-07T01:53:43.049749+00:00</updated>
    <content>EUVD-2026-322099</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-322099"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-47070</id>
    <title>fkie_cve-2026-47070</title>
    <updated>2026-10-07T01:53:43.049787+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>Sensitive Data Exposure vulnerability in benoitc hackney allows Retrieve Embedded Sensitive Data. The HTTP/3 redirect handler in src/hackney_h3.erl passes the original request headers unchanged to the redirect target without performing any cross-origin check. When a client issues an HTTP/3 request with follow_redirect enabled and includes Authorization or Cookie headers, a server responding with a 3xx redirect to a different host will cause the client to forward those credentials verbatim to the new origin.</p>
<p>The main hackney.erl module has maybe_strip_auth_on_redirect/2 (guarded by the location_trusted option) to address CVE-2018-1000007, but hackney_h3.erl is missing this protection entirely.</p>
<p>This issue affects hackney: from 3.1.1 before 4.0.1.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-47070"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-h73q-4w9q-82h4</id>
    <title>GHSA-h73q-4w9q-82h4 — Hackney: Cross-origin Redirect Leaks Authorization, Cookie, and Request Body</title>
    <updated>2026-10-07T01:53:43.049825+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Hex: hackney</p>
<p>### Summary</p>
<p>The HTTP/3 redirect handler in `src/hackney_h3.erl` forwards the original request headers (`Authorization`, `Cookie`, `Proxy-Authorization`) and, for 307/308 responses, the original request body to the redirect target without checking whether the target host matches the origin. When `follow_redirect` is enabled and a server responds with a cross-origin `Location`, hackney delivers the caller's credentials verbatim to the attacker-controlled host. The main hackney HTTP/1 client has `maybe_strip_auth_on_redirect/2` (the fix for CVE-2018-1000007); the H3 client was added later without it.</p>
<p>### Details</p>
<p>In `src/hackney_h3.erl`, `handle_redirect/11` (line 165) extracts the redirect target from the server-controlled `Location` header via `get_redirect_location/1` and resolves it with `resolve_redirect_url/2`, which accepts any absolute `http://` or `https://` URL. It then calls `do_request_with_redirect/8` passing the original `Headers` list unchanged. For 307/308 responses, `redirect_method/2` preserves the original method and body, so the POST body is also forwarded.</p>
<p>No comparison is made between the original URL's scheme, host, or port and the redirect target. The downstream `connect/3` opens a new QUIC connection to whatever the `Location` header named, and `build_request_headers/4` serializes the unmodified headers into the QPACK-encoded request.</p>
<p>### PoC</p>
<p>1. Issue an HTTP/3 POST to an attacker-controlled origin with `follow_redirect =&gt; true` and an `Authorizati…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-h73q-4w9q-82h4"/>
  </entry>
</feed>
