<?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://cve.radiocsirt.org</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>Sat, 03 Oct 2026 08:45:43 +0000</lastBuildDate>
    <item>
      <title>BREW-aider-CVE-2026-54282 — Starlette: Unvalidated request path concatenated into authority poisons request.url.hostname</title>
      <link>https://cve.radiocsirt.org/vuln/brew-aider-cve-2026-54282</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: aider&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;When a client requests a path that does not start with `/`:&lt;/p&gt;
&lt;p&gt;```http
GET @google.com HTTP/1.1
Host: localhost
```&lt;/p&gt;
&lt;p&gt;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 = &amp;#34;localhost&amp;#34;` and `hostname = &amp;#34;google.com&amp;#34;`, with an empty path:&lt;/p&gt;
&lt;p&gt;```text
request.url          == &amp;#34;http://localhost@google.com&amp;#34;
request.url.hostname == &amp;#34;google.com&amp;#34;
request.url.path     == &amp;#34;&amp;#34;
```&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;This requires an ASGI server that forwards a request-target lacking a leading `/` into `scope[&amp;#34;path&amp;#34;]`.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Any application…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: aider&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;When a client requests a path that does not start with `/`:&lt;/p&gt;
&lt;p&gt;```http
GET @google.com HTTP/1.1
Host: localhost
```&lt;/p&gt;
&lt;p&gt;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 = &amp;#34;localhost&amp;#34;` and `hostname = &amp;#34;google.com&amp;#34;`, with an empty path:&lt;/p&gt;
&lt;p&gt;```text
request.url          == &amp;#34;http://localhost@google.com&amp;#34;
request.url.hostname == &amp;#34;google.com&amp;#34;
request.url.path     == &amp;#34;&amp;#34;
```&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;This requires an ASGI server that forwards a request-target lacking a leading `/` into `scope[&amp;#34;path&amp;#34;]`.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Any application…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/brew-aider-cve-2026-54282</guid>
    </item>
    <item>
      <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>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0933</link>
      <description>certfr-2026-avi-0933</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0933</guid>
    </item>
    <item>
      <title>Withdrawn: CLEANSTART-2026-AL63130 — Security fixes in litellm-database 1.96.0-r0</title>
      <link>https://cve.radiocsirt.org/vuln/cleanstart-2026-al63130</link>
      <description>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: litellm-database&lt;/p&gt;
&lt;p&gt;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&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: litellm-database&lt;/p&gt;
&lt;p&gt;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&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cleanstart-2026-al63130</guid>
    </item>
    <item>
      <title>EUVD-2026-329045</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-329045</link>
      <description>EUVD-2026-329045</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-329045</guid>
    </item>
    <item>
      <title>fkie_cve-2026-54282</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-54282</link>
      <description>&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-54282</guid>
    </item>
    <item>
      <title>GHSA-jp82-jpqv-5vv3 — Starlette: Unvalidated request path concatenated into authority poisons request.url.hostname</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-jp82-jpqv-5vv3</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: Starlette&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;When a client requests a path that does not start with `/`:&lt;/p&gt;
&lt;p&gt;```http
GET @google.com HTTP/1.1
Host: localhost
```&lt;/p&gt;
&lt;p&gt;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 = &amp;#34;localhost&amp;#34;` and `hostname = &amp;#34;google.com&amp;#34;`, with an empty path:&lt;/p&gt;
&lt;p&gt;```text
request.url          == &amp;#34;http://localhost@google.com&amp;#34;
request.url.hostname == &amp;#34;google.com&amp;#34;
request.url.path     == &amp;#34;&amp;#34;
```&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;This requires an ASGI server that forwards a request-target lacking a leading `/` into `scope[&amp;#34;path&amp;#34;]`.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Any application…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: Starlette&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;When a client requests a path that does not start with `/`:&lt;/p&gt;
&lt;p&gt;```http
GET @google.com HTTP/1.1
Host: localhost
```&lt;/p&gt;
&lt;p&gt;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 = &amp;#34;localhost&amp;#34;` and `hostname = &amp;#34;google.com&amp;#34;`, with an empty path:&lt;/p&gt;
&lt;p&gt;```text
request.url          == &amp;#34;http://localhost@google.com&amp;#34;
request.url.hostname == &amp;#34;google.com&amp;#34;
request.url.path     == &amp;#34;&amp;#34;
```&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;This requires an ASGI server that forwards a request-target lacking a leading `/` into `scope[&amp;#34;path&amp;#34;]`.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Any application…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-jp82-jpqv-5vv3</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:11058-1 — python311-starlette-1.3.1-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:11058-1</link>
      <description>&lt;p&gt;python311-starlette-1.3.1-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;python311-starlette-1.3.1-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:11058-1</guid>
    </item>
    <item>
      <title>PYSEC-2026-248</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-248</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: starlette&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: starlette&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-248</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:22360-1 — Security update for python-starlette</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:22360-1</link>
      <description>&lt;p&gt;Security update for python-starlette&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for python-starlette&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2026:22360-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-54282</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-54282</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:22.04:LTS: starlette, Ubuntu:24.04:LTS: starlette, Ubuntu:25.10: starlette, Ubuntu:26.04:LTS: starlette&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:22.04:LTS: starlette, Ubuntu:24.04:LTS: starlette, Ubuntu:25.10: starlette, Ubuntu:26.04:LTS: starlette&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-54282</guid>
    </item>
  </channel>
</rss>
