<?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://vulnerability.circl.lu</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>Mon, 28 Sep 2026 18:17:52 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-12648</title>
      <link>https://vulnerability.circl.lu/vuln/bdu:2026-12648</link>
      <description>bdu:2026-12648</description>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/bdu:2026-12648</guid>
    </item>
    <item>
      <title>fkie_cve-2026-55553</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-55553</link>
      <description>&lt;p&gt;urllib is an HTTP client for Node.js that supports authentication, redirects, timeouts, and other request features. Prior to 4.9.1 and 2.44.1, urllib follows redirects through followRedirect but reuses caller-supplied options across origins. In src/HttpClient.ts, #requestInternal recursively calls this.#requestInternal(nextUrl.href, options, requestContext), causing options.headers and auth or digestAuth values to be reused when the redirect target has a different scheme, host, or port. Authorization, Cookie, Proxy-Authorization, x-api-key, x-auth-token, and x-access-token can therefore be sent to an attacker-controlled redirected origin, exposing credentials intended for the original origin and potentially allowing reuse against the original partner API or related services. No user interaction is required. This issue is fixed in versions 2.44.1 and 4.9.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;urllib is an HTTP client for Node.js that supports authentication, redirects, timeouts, and other request features. Prior to 4.9.1 and 2.44.1, urllib follows redirects through followRedirect but reuses caller-supplied options across origins. In src/HttpClient.ts, #requestInternal recursively calls this.#requestInternal(nextUrl.href, options, requestContext), causing options.headers and auth or digestAuth values to be reused when the redirect target has a different scheme, host, or port. Authorization, Cookie, Proxy-Authorization, x-api-key, x-auth-token, and x-access-token can therefore be sent to an attacker-controlled redirected origin, exposing credentials intended for the original origin and potentially allowing reuse against the original partner API or related services. No user interaction is required. This issue is fixed in versions 2.44.1 and 4.9.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-55553</guid>
    </item>
    <item>
      <title>GHSA-hq3h-g68c-hp78 — urllib's cross-origin redirects preserve credential-bearing request headers, leading to potential credential leakage</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-hq3h-g68c-hp78</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: urllib&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;urllib supports redirect-following through `followRedirect`, which is expected behavior for an HTTP client. The issue is that, when following a redirect to a **different origin**, urllib preserves the caller-supplied request headers verbatim, including credential-bearing headers such as `Authorization`, `Cookie`, `Proxy-Authorization`, and custom auth headers (`x-api-key`, `x-auth-token`, `x-access-token`).&lt;/p&gt;
&lt;p&gt;If the redirect target is attacker-controlled or outside the trust boundary of the original target, credentials intended for the original origin can be delivered to the redirected origin. In a local multi-library reproduction, urllib v4.9.0 was the only tested client that stripped no headers on cross-origin redirect.&lt;/p&gt;
&lt;p&gt;## Affected behavior&lt;/p&gt;
&lt;p&gt;Confirmed against urllib v4.9.0. The relevant code is in `#requestInternal` ([`src/HttpClient.ts:639-656`](https://github.com/node-modules/urllib/blob/master/src/HttpClient.ts#L639-L656)):&lt;/p&gt;
&lt;p&gt;```ts
     // https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections
      if (RedirectStatusCodes.includes(res.statusCode) &amp;amp;&amp;amp; maxRedirects &amp;gt; 0 &amp;amp;&amp;amp; requestContext.redirects &amp;lt; maxRedirects) {
        if (res.headers.location) {
          requestContext.redirects++;
          const nextUrl = new URL(res.headers.location, requestUrl.href);
          // Ensure the response is consumed
          await response.body.arrayBuffer();
          debug(
            &amp;#39;Request#%d got response, status: %s, headers: %j, timing: %j, redirect to %s&amp;#39;…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: urllib&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;urllib supports redirect-following through `followRedirect`, which is expected behavior for an HTTP client. The issue is that, when following a redirect to a **different origin**, urllib preserves the caller-supplied request headers verbatim, including credential-bearing headers such as `Authorization`, `Cookie`, `Proxy-Authorization`, and custom auth headers (`x-api-key`, `x-auth-token`, `x-access-token`).&lt;/p&gt;
&lt;p&gt;If the redirect target is attacker-controlled or outside the trust boundary of the original target, credentials intended for the original origin can be delivered to the redirected origin. In a local multi-library reproduction, urllib v4.9.0 was the only tested client that stripped no headers on cross-origin redirect.&lt;/p&gt;
&lt;p&gt;## Affected behavior&lt;/p&gt;
&lt;p&gt;Confirmed against urllib v4.9.0. The relevant code is in `#requestInternal` ([`src/HttpClient.ts:639-656`](https://github.com/node-modules/urllib/blob/master/src/HttpClient.ts#L639-L656)):&lt;/p&gt;
&lt;p&gt;```ts
     // https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections
      if (RedirectStatusCodes.includes(res.statusCode) &amp;amp;&amp;amp; maxRedirects &amp;gt; 0 &amp;amp;&amp;amp; requestContext.redirects &amp;lt; maxRedirects) {
        if (res.headers.location) {
          requestContext.redirects++;
          const nextUrl = new URL(res.headers.location, requestUrl.href);
          // Ensure the response is consumed
          await response.body.arrayBuffer();
          debug(
            &amp;#39;Request#%d got response, status: %s, headers: %j, timing: %j, redirect to %s&amp;#39;…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-hq3h-g68c-hp78</guid>
    </item>
    <item>
      <title>RHSA-2026:69248 — Red Hat Security Advisory: Red Hat Developer Hub 1.9.9 release.</title>
      <link>https://vulnerability.circl.lu/vuln/rhsa-2026:69248</link>
      <description>&lt;p&gt;undici: undici: Denial of Service via unrequested WebSocket subprotocol encoding/asn1: golang: Go encoding/asn1: Denial of Service via excessive recursion in Unmarshal ip-address: ip-address: Server-Side Request Forgery via IPv4-mapped/NAT64 IPv6 address misclassification urllib: urllib: Credential leakage via cross-origin redirects net/http: golang: Go net/http: Unencrypted HTTP/2 connections vulnerable to Denial of Service html/template: golang: Go html/template: Cross-Site Scripting via pathological input encoding/xml: golang: Go: Denial of Service via XML decoding recursion depth issue net/url: golang: golang net/url: Denial of Service from quadratic complexity in path resolution crypto/tls: golang: Golang crypto/tls: Denial of Service via indefinite KeyUpdate messages nanoid: nanoid: Denial of Service via negative size input in non-secure module functions axios: axios: Denial of Service via uncontrolled recursion in form data processing pymdown-extensions: Pymdown-extensions: Denial of Service via Regular Expression Vulnerability brace-expansion: DoS via unbounded intermediate arrays, bypassing the CVE-2026-14257 mitigation ip-address: ip-address: Inconsistent IP address parsing leads to Server-Side Request Forgery (SSRF) and trust-boundary bypass nanoid: nanoid: Predictable ID generation due to integer overflow fast-uri: fast-uri: Server-Side Request Forgery via repeated hostname percent-decoding fast-uri: fast-uri: Host confusion via skipped IDN canonicalization fast-…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;undici: undici: Denial of Service via unrequested WebSocket subprotocol encoding/asn1: golang: Go encoding/asn1: Denial of Service via excessive recursion in Unmarshal ip-address: ip-address: Server-Side Request Forgery via IPv4-mapped/NAT64 IPv6 address misclassification urllib: urllib: Credential leakage via cross-origin redirects net/http: golang: Go net/http: Unencrypted HTTP/2 connections vulnerable to Denial of Service html/template: golang: Go html/template: Cross-Site Scripting via pathological input encoding/xml: golang: Go: Denial of Service via XML decoding recursion depth issue net/url: golang: golang net/url: Denial of Service from quadratic complexity in path resolution crypto/tls: golang: Golang crypto/tls: Denial of Service via indefinite KeyUpdate messages nanoid: nanoid: Denial of Service via negative size input in non-secure module functions axios: axios: Denial of Service via uncontrolled recursion in form data processing pymdown-extensions: Pymdown-extensions: Denial of Service via Regular Expression Vulnerability brace-expansion: DoS via unbounded intermediate arrays, bypassing the CVE-2026-14257 mitigation ip-address: ip-address: Inconsistent IP address parsing leads to Server-Side Request Forgery (SSRF) and trust-boundary bypass nanoid: nanoid: Predictable ID generation due to integer overflow fast-uri: fast-uri: Server-Side Request Forgery via repeated hostname percent-decoding fast-uri: fast-uri: Host confusion via skipped IDN canonicalization fast-…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/rhsa-2026:69248</guid>
    </item>
  </channel>
</rss>
