<?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://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-01T23:52:36.569602+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" 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://vulnerability.circl.lu/vuln/cve-2026-67435</id>
    <title>CVE-2026-67435 — linuxfabrik-lib: fetch() forwards credential headers across a cross-origin redirect</title>
    <updated>2026-10-01T23:52:36.572211+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linuxfabrik monitoring-plugins</p>
<p>linuxfabrik-lib provides Python modules for database access, caching, shell execution, and API integrations. Prior to version 6.0.0, lib.url.fetch() followed cross-origin redirects while forwarding caller-supplied credential headers other than Authorization and Cookie, allowing a malicious redirect-capable server to receive headers such as X-Auth-Token from authenticated monitoring requests. This issue is fixed in version 6.0.0.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-67435"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-4jc5-g844-4x33</id>
    <title>GHSA-4jc5-g844-4x33 — linuxfabrik-lib: fetch() forwards credential headers across a cross-origin redirect</title>
    <updated>2026-10-01T23:52:36.572329+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: linuxfabrik-lib</p>
<p>### Summary
`lib.url.fetch()` follows HTTP redirects (`follow_redirects=True`). httpx strips only `Authorization` and `Cookie` when a redirect crosses the origin, so any other caller-supplied credential header (a session token such as Redfish's `X-Auth-Token`, an API key, ...) was still sent to the redirect target. A malicious or redirect-capable server can therefore answer an authenticated request with a `3xx` to an attacker-chosen host and receive the credential (server-side request forgery + token disclosure). The pre-httpx `urllib` implementation was worse: it forwarded every header, including `Authorization`, across cross-host redirects.</p>
<p>### Impact
Any plugin that authenticates to a host with a non-standard auth header and follows that host's redirects can be coerced into sending the credential, and an authenticated request, to another host the monitoring server can reach. The concrete case is the Redfish checks (`X-Auth-Token`), but the flaw is in the shared `fetch()` and affects every consumer.</p>
<p>### Patches
Fixed in linuxfabrik-lib 6.0.0 (commit 6573ff9). On a cross-origin redirect (any scheme/host/port change other than a plain same-host HTTP-to-HTTPS upgrade) `fetch()` now keeps only benign transport headers and drops every other caller-supplied header, so credentials never follow a redirect to a different origin.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-4jc5-g844-4x33"/>
  </entry>
</feed>
