<?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-03T23:37:20.548813+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/cve-2026-48061</id>
    <title>CVE-2026-48061 — Litestar: AllowedHostsMiddleware bypasses host validation via client-controlled X-Forwarded-Host header</title>
    <updated>2026-10-03T23:37:20.550488+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> litestar-org litestar</p>
<p>Litestar is an Asynchronous Server Gateway Interface (ASGI) framework. In versions prior to 2.22.0, an attacker can bypass the allowed hosts validation by omitting the Host header and supplying an X-Forwarded-Host header set to a whitelisted domain. The AllowedHostsMiddleware trusts the X-Forwarded-Host header as a fallback when the Host header is absent. Since X-Forwarded-Host is a client-controllable header, this enables host header injection attacks such as password reset poisoning, cache poisoning, and server-side request routing manipulation. Any application using AllowedHostsConfig is affected when deployed without a reverse proxy that strips X-Forwarded-Host, or when accepting HTTP/1.0 connections. This issue has been fixed in version 2.22.0.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2026-48061"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-3qmc-cj7q-62hv</id>
    <title>GHSA-3qmc-cj7q-62hv — Litestar: AllowedHostsMiddleware bypasses host validation via client-controlled X-Forwarded-Host header</title>
    <updated>2026-10-03T23:37:20.550543+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: litestar</p>
<p>### Summary</p>
<p>`AllowedHostsMiddleware` trusts the `X-Forwarded-Host` header as a fallback when the `Host` header is absent. Since `X-Forwarded-Host` is a client-controllable header, an attacker can bypass the allowed hosts validation by omitting the `Host` header and supplying an `X-Forwarded-Host` header set to a whitelisted domain. This enables host header injection attacks such as password reset poisoning, cache poisoning, and server-side request routing manipulation.</p>
<p>### Details</p>
<p>In `AllowedHostsMiddleware.__call__`, the host value used for validation is resolved as follows:</p>
<p>https://github.com/litestar-org/litestar/blob/main/litestar/middleware/allowed_hosts.py#L68</p>
<p>```python
headers = MutableScopeHeaders(scope=scope)
if host := headers.get("host", headers.get("x-forwarded-host", "")).split(":")[0]:
    if self.allowed_hosts_regex.fullmatch(host):
        await self.app(scope, receive, send)
        return
```</p>
<p>When `Host` is absent (e.g., HTTP/1.0 clients, misconfigured proxies, or raw TCP connections), the middleware falls back to `X-Forwarded-Host` without any verification that the request actually passed through a trusted reverse proxy.</p>
<p>An attacker can send a request with no `Host` header and set `X-Forwarded-Host` to any whitelisted domain, bypassing the entire allowed hosts check. The application then processes the request as if it originated from a trusted host.</p>
<p>This is particularly dangerous when applications use the resolved host value for:
- Generating passw…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-3qmc-cj7q-62hv"/>
  </entry>
</feed>
