<?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-03T08:47:18.500152+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/brew-aider-cve-2026-54282</id>
    <title>BREW-aider-CVE-2026-54282 — Starlette: Unvalidated request path concatenated into authority poisons request.url.hostname</title>
    <updated>2026-10-03T08:47:18.525087+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Homebrew: aider</p>
<p>### Summary</p>
<p>In affected versions, the HTTP request path is not validated before being used to reconstruct `request.url`. Because `request.url` is rebuilt by concatenating `{scheme}://{host}{path}` and re-parsing the result, a path that does not begin with `/` (for example `@google.com`) moves the authority boundary during re-parsing, so `request.url.hostname` and `request.url.netloc` become attacker-controlled. Code that reads `request.url.hostname` (rather than the `Host` header or `scope`) can therefore be misled into trusting an attacker-supplied host.</p>
<p>### Details</p>
<p>When a client requests a path that does not start with `/`:</p>
<p>```http
GET @google.com HTTP/1.1
Host: localhost
```</p>
<p>affected versions reconstruct the URL as `http://localhost@google.com`. Per [RFC 3986 §3.2.1](https://www.rfc-editor.org/rfc/rfc3986.html#section-3.2.1), the substring before `@` in the authority is `userinfo`, so re-parsing yields `username = "localhost"` and `hostname = "google.com"`, with an empty path:</p>
<p>```text
request.url          == "http://localhost@google.com"
request.url.hostname == "google.com"
request.url.path     == ""
```</p>
<p>The root cause is that the path is concatenated directly after the host without a separating `/`, and without validating that it begins with one. Only the `Host` header was validated when constructing `request.url`; the path was not.</p>
<p>This requires an ASGI server that forwards a request-target lacking a leading `/` into `scope["path"]`.</p>
<p>### Impact</p>
<p>Any application…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/brew-aider-cve-2026-54282"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0933</id>
    <title>certfr-2026-avi-0933 — De multiples vulnérabilités ont été découvertes dans les produits IBM. Certaines d'entre elles permettent à un attaquan…</title>
    <updated>2026-10-03T08:47:18.525166+00:00</updated>
    <content>certfr-2026-avi-0933</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2026-avi-0933"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/cleanstart-2026-al63130</id>
    <title>Withdrawn: CLEANSTART-2026-AL63130 — Security fixes in litellm-database 1.96.0-r0</title>
    <updated>2026-10-03T08:47:18.525186+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Withdrawn by the publisher.</strong></p>
<p><strong>Affected:</strong> CleanStart: litellm-database</p>
<p>Package litellm-database version 1.96.0-r0 fixes 5 vulnerabilities: CVE-2026-54282, CVE-2025-62727, CVE-2026-48818, CVE-2026-54283, CVE-2025-54121</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cleanstart-2026-al63130"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-329045</id>
    <title>EUVD-2026-329045</title>
    <updated>2026-10-03T08:47:18.525209+00:00</updated>
    <content>EUVD-2026-329045</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-329045"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-54282</id>
    <title>fkie_cve-2026-54282</title>
    <updated>2026-10-03T08:47:18.525221+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Starlette is a lightweight ASGI framework/toolkit. Prior to 1.3.0, the HTTP request path is not validated before being used to reconstruct request.url. Because request.url is rebuilt by concatenating {scheme}://{host}{path} and re-parsing the result, a path that does not begin with / (for example @google.com) moves the authority boundary during re-parsing, so request.url.hostname and request.url.netloc become attacker-controlled. Code that reads request.url.hostname (rather than the Host header or scope) can therefore be misled into trusting an attacker-supplied host. This vulnerability is fixed in 1.3.0.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-54282"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-jp82-jpqv-5vv3</id>
    <title>GHSA-jp82-jpqv-5vv3 — Starlette: Unvalidated request path concatenated into authority poisons request.url.hostname</title>
    <updated>2026-10-03T08:47:18.525243+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: Starlette</p>
<p>### Summary</p>
<p>In affected versions, the HTTP request path is not validated before being used to reconstruct `request.url`. Because `request.url` is rebuilt by concatenating `{scheme}://{host}{path}` and re-parsing the result, a path that does not begin with `/` (for example `@google.com`) moves the authority boundary during re-parsing, so `request.url.hostname` and `request.url.netloc` become attacker-controlled. Code that reads `request.url.hostname` (rather than the `Host` header or `scope`) can therefore be misled into trusting an attacker-supplied host.</p>
<p>### Details</p>
<p>When a client requests a path that does not start with `/`:</p>
<p>```http
GET @google.com HTTP/1.1
Host: localhost
```</p>
<p>affected versions reconstruct the URL as `http://localhost@google.com`. Per [RFC 3986 §3.2.1](https://www.rfc-editor.org/rfc/rfc3986.html#section-3.2.1), the substring before `@` in the authority is `userinfo`, so re-parsing yields `username = "localhost"` and `hostname = "google.com"`, with an empty path:</p>
<p>```text
request.url          == "http://localhost@google.com"
request.url.hostname == "google.com"
request.url.path     == ""
```</p>
<p>The root cause is that the path is concatenated directly after the host without a separating `/`, and without validating that it begins with one. Only the `Host` header was validated when constructing `request.url`; the path was not.</p>
<p>This requires an ASGI server that forwards a request-target lacking a leading `/` into `scope["path"]`.</p>
<p>### Impact</p>
<p>Any application…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-jp82-jpqv-5vv3"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/opensuse-su-2026:11058-1</id>
    <title>openSUSE-SU-2026:11058-1 — python311-starlette-1.3.1-1.1 on GA media</title>
    <updated>2026-10-03T08:47:18.525286+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>python311-starlette-1.3.1-1.1 on GA media</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/opensuse-su-2026:11058-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/pysec-2026-248</id>
    <title>PYSEC-2026-248</title>
    <updated>2026-10-03T08:47:18.525302+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: starlette</p>
<p>Starlette is a lightweight ASGI framework/toolkit. Prior to 1.3.0, the HTTP request path is not validated before being used to reconstruct request.url. Because request.url is rebuilt by concatenating {scheme}://{host}{path} and re-parsing the result, a path that does not begin with / (for example @google.com) moves the authority boundary during re-parsing, so request.url.hostname and request.url.netloc become attacker-controlled. Code that reads request.url.hostname (rather than the Host header or scope) can therefore be misled into trusting an attacker-supplied host. This vulnerability is fixed in 1.3.0.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/pysec-2026-248"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/suse-su-2026:22360-1</id>
    <title>SUSE-SU-2026:22360-1 — Security update for python-starlette</title>
    <updated>2026-10-03T08:47:18.525324+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Security update for python-starlette</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/suse-su-2026:22360-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-54282</id>
    <title>UBUNTU-CVE-2026-54282</title>
    <updated>2026-10-03T08:47:18.525339+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:22.04:LTS: starlette, Ubuntu:24.04:LTS: starlette, Ubuntu:25.10: starlette, Ubuntu:26.04:LTS: starlette</p>
<p>Starlette is a lightweight ASGI framework/toolkit. Prior to 1.3.0, the HTTP request path is not validated before being used to reconstruct request.url. Because request.url is rebuilt by concatenating {scheme}://{host}{path} and re-parsing the result, a path that does not begin with / (for example @google.com) moves the authority boundary during re-parsing, so request.url.hostname and request.url.netloc become attacker-controlled. Code that reads request.url.hostname (rather than the Host header or scope) can therefore be misled into trusting an attacker-supplied host. This vulnerability is fixed in 1.3.0.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-54282"/>
  </entry>
</feed>
