<?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>Wed, 30 Sep 2026 17:31:56 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-54282 — Starlette: Unvalidated request path concatenated into authority poisons request.url.hostname</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-54282</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Kludex 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; Kludex 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://vulnerability.circl.lu/vuln/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://vulnerability.circl.lu/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://vulnerability.circl.lu/vuln/ghsa-jp82-jpqv-5vv3</guid>
    </item>
    <item>
      <title>PYSEC-2026-248</title>
      <link>https://vulnerability.circl.lu/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://vulnerability.circl.lu/vuln/pysec-2026-248</guid>
    </item>
  </channel>
</rss>
