<?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://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-23T19:30:56.454435+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" 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://db.gcve.eu/vuln/fkie_cve-2026-111756</id>
    <title>fkie_cve-2026-111756</title>
    <updated>2026-10-23T19:30:56.457910+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>follow-redirects is a Node.js HTTP and HTTPS client wrapper that automatically follows redirects. From version 1.16.0 to before version 1.16.1, follow-redirects removes sensitive credential headers (Authorization, Proxy-Authorization, Cookie, and any caller-declared sensitiveHeaders) before following a redirect that crosses to a different host or downgrades to a less secure protocol. The removal routine iterates the caller's headers container with for...in and matches header names against a filter. This assumes the headers container is a plain object keyed by header names. Node's underlying http.request, which follow-redirects is a drop-in replacement for, also accepts headers as an alternating array of names and values. For an array, for...in yields the numeric indices "0", "1", "2" and so on, which never match a header-name filter, so nothing is removed. An application that sends array-form headers and follows an attacker-controlled cross-origin redirect therefore forwards its Authorization, Cookie, and Proxy-Authorization headers verbatim to the attacker-controlled destination, with no error or warning. The sensitiveHeaders option added to fix CVE-2026-40895 / GHSA-r4q5-vmmm-2653 is equally ineffective, because it relies on the same helper. This is an unauthenticated confidentiality vulnerability: any remote server the victim application contacts can harvest the victim's credential headers by responding with a cross-origin redirect. This issue has been patched in version…</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-111756"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-q3jh-wrc6-jgq8</id>
    <title>GHSA-q3jh-wrc6-jgq8 — follow-redirects array-form headers bypass cross-origin credential stripping</title>
    <updated>2026-10-23T19:30:56.458015+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> npm: follow-redirects</p>
<p>### Summary
follow-redirects removes sensitive credential headers (Authorization, Proxy-Authorization, Cookie, and any caller-declared `sensitiveHeaders`) before following a redirect that crosses to a different host or downgrades to a less secure protocol. The removal routine iterates the caller's headers container with `for...in` and matches header names against a filter. This assumes the headers container is a plain object keyed by header names. Node's underlying `http.request`, which follow-redirects is a drop-in replacement for, also accepts headers as an alternating array of names and values. For an array, `for...in` yields the numeric indices `"0"`, `"1"`, `"2"` and so on, which never match a header-name filter, so nothing is removed. An application that sends array-form headers and follows an attacker-controlled cross-origin redirect therefore forwards its Authorization, Cookie, and Proxy-Authorization headers verbatim to the attacker-controlled destination, with no error or warning. The `sensitiveHeaders` option added to fix CVE-2026-40895 / GHSA-r4q5-vmmm-2653 is equally ineffective, because it relies on the same helper. This is an unauthenticated confidentiality vulnerability: any remote server the victim application contacts can harvest the victim's credential headers by responding with a cross-origin redirect.</p>
<p>### Details
The cross-origin credential-stripping control is implemented by `removeMatchingHeaders(regex, headers)` at `index.js:630-640`:</p>
<p>```js
function…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-q3jh-wrc6-jgq8"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/rhsa-2026:88478</id>
    <title>RHSA-2026:88478 — Red Hat Security Advisory: Red Hat Hardened Images RPMs Security Update</title>
    <updated>2026-10-23T19:30:56.458122+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>follow-redirects: follow-redirects: Information disclosure via improper regular expression escaping in sensitive header filtering follow-redirects: follow-redirects: Information disclosure via array-formatted headers during cross-origin redirects storybook: Storybook: Arbitrary code execution via insufficient message-origin restrictions storybook: storybook: Arbitrary code execution via exposed WebSocket authentication token</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/rhsa-2026:88478"/>
  </entry>
</feed>
