<?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 20:40:19 +0000</lastBuildDate>
    <item>
      <title>BREW-aider-CVE-2026-49468 — LiteLLM: Authentication Bypass via Host Header Injection</title>
      <link>https://cve.radiocsirt.org/vuln/brew-aider-cve-2026-49468</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: aider&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;A Host-header parsing flaw in the LiteLLM proxy could, under specific conditions, allow unauthenticated access to protected management routes.&lt;/p&gt;
&lt;p&gt;The auth layer derived the effective route from `request.url.path` in `litellm/proxy/auth/auth_utils.py::get_request_route()`, which Starlette reconstructs from the `Host` header. A crafted `Host` could therefore make the auth gate evaluate a different route from the one FastAPI dispatched.&lt;/p&gt;
&lt;p&gt;**Most deployments are not affected.** The bypass is blocked by any upstream layer that validates or normalizes `Host`, such as:&lt;/p&gt;
&lt;p&gt;- a CDN or WAF, such as Cloudflare
- a reverse proxy with `server_name` allowlists
- a host-based load balancer&lt;/p&gt;
&lt;p&gt;**LiteLLM Cloud customers are not affected.**&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;Fixed in **`1.84.0`**. Upgrade to `1.84.0` or later. No configuration change is required.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;If upgrading is not immediately possible, place the proxy behind an upstream component that validates or normalizes the `Host` header before forwarding (a CDN/WAF, a reverse proxy with explicit `server_name` allowlists, or a cloud load balancer with host-based routing rules), or otherwise restrict network access to the proxy listener.&lt;/p&gt;
&lt;p&gt;### References&lt;/p&gt;
&lt;p&gt;- Patched release: [`v1.84.0`](https://github.com/BerriAI/litellm/releases/tag/v1.84.0)&lt;/p&gt;
&lt;p&gt;**Discovery Credit**: Le The Thang (KCSC) and Kim Ngoc Chung (One Mount Group)&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: aider&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;A Host-header parsing flaw in the LiteLLM proxy could, under specific conditions, allow unauthenticated access to protected management routes.&lt;/p&gt;
&lt;p&gt;The auth layer derived the effective route from `request.url.path` in `litellm/proxy/auth/auth_utils.py::get_request_route()`, which Starlette reconstructs from the `Host` header. A crafted `Host` could therefore make the auth gate evaluate a different route from the one FastAPI dispatched.&lt;/p&gt;
&lt;p&gt;**Most deployments are not affected.** The bypass is blocked by any upstream layer that validates or normalizes `Host`, such as:&lt;/p&gt;
&lt;p&gt;- a CDN or WAF, such as Cloudflare
- a reverse proxy with `server_name` allowlists
- a host-based load balancer&lt;/p&gt;
&lt;p&gt;**LiteLLM Cloud customers are not affected.**&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;Fixed in **`1.84.0`**. Upgrade to `1.84.0` or later. No configuration change is required.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;If upgrading is not immediately possible, place the proxy behind an upstream component that validates or normalizes the `Host` header before forwarding (a CDN/WAF, a reverse proxy with explicit `server_name` allowlists, or a cloud load balancer with host-based routing rules), or otherwise restrict network access to the proxy listener.&lt;/p&gt;
&lt;p&gt;### References&lt;/p&gt;
&lt;p&gt;- Patched release: [`v1.84.0`](https://github.com/BerriAI/litellm/releases/tag/v1.84.0)&lt;/p&gt;
&lt;p&gt;**Discovery Credit**: Le The Thang (KCSC) and Kim Ngoc Chung (One Mount Group)&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/brew-aider-cve-2026-49468</guid>
    </item>
    <item>
      <title>EUVD-2026-337194</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-337194</link>
      <description>EUVD-2026-337194</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-337194</guid>
    </item>
    <item>
      <title>fkie_cve-2026-49468</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-49468</link>
      <description>&lt;p&gt;LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.84.0, a Host-header parsing flaw in the LiteLLM proxy could, under specific conditions, allow unauthenticated access to protected management routes. The auth layer derived the effective route from request.url.path in litellm/proxy/auth/auth_utils.py::get_request_route(), which Starlette reconstructs from the Host header. A crafted Host could therefore make the auth gate evaluate a different route from the one FastAPI dispatched. This vulnerability is fixed in 1.84.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.84.0, a Host-header parsing flaw in the LiteLLM proxy could, under specific conditions, allow unauthenticated access to protected management routes. The auth layer derived the effective route from request.url.path in litellm/proxy/auth/auth_utils.py::get_request_route(), which Starlette reconstructs from the Host header. A crafted Host could therefore make the auth gate evaluate a different route from the one FastAPI dispatched. This vulnerability is fixed in 1.84.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-49468</guid>
    </item>
    <item>
      <title>GHSA-4xpc-pv4p-pm3w — LiteLLM: Authentication Bypass via Host Header Injection</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-4xpc-pv4p-pm3w</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: litellm&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;A Host-header parsing flaw in the LiteLLM proxy could, under specific conditions, allow unauthenticated access to protected management routes.&lt;/p&gt;
&lt;p&gt;The auth layer derived the effective route from `request.url.path` in `litellm/proxy/auth/auth_utils.py::get_request_route()`, which Starlette reconstructs from the `Host` header. A crafted `Host` could therefore make the auth gate evaluate a different route from the one FastAPI dispatched.&lt;/p&gt;
&lt;p&gt;**Most deployments are not affected.** The bypass is blocked by any upstream layer that validates or normalizes `Host`, such as:&lt;/p&gt;
&lt;p&gt;- a CDN or WAF, such as Cloudflare
- a reverse proxy with `server_name` allowlists
- a host-based load balancer&lt;/p&gt;
&lt;p&gt;**LiteLLM Cloud customers are not affected.**&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;Fixed in **`1.84.0`**. Upgrade to `1.84.0` or later. No configuration change is required.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;If upgrading is not immediately possible, place the proxy behind an upstream component that validates or normalizes the `Host` header before forwarding (a CDN/WAF, a reverse proxy with explicit `server_name` allowlists, or a cloud load balancer with host-based routing rules), or otherwise restrict network access to the proxy listener.&lt;/p&gt;
&lt;p&gt;### References&lt;/p&gt;
&lt;p&gt;- Patched release: [`v1.84.0`](https://github.com/BerriAI/litellm/releases/tag/v1.84.0)&lt;/p&gt;
&lt;p&gt;**Discovery Credit**: Le The Thang (KCSC) and Kim Ngoc Chung (One Mount Group)&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: litellm&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;A Host-header parsing flaw in the LiteLLM proxy could, under specific conditions, allow unauthenticated access to protected management routes.&lt;/p&gt;
&lt;p&gt;The auth layer derived the effective route from `request.url.path` in `litellm/proxy/auth/auth_utils.py::get_request_route()`, which Starlette reconstructs from the `Host` header. A crafted `Host` could therefore make the auth gate evaluate a different route from the one FastAPI dispatched.&lt;/p&gt;
&lt;p&gt;**Most deployments are not affected.** The bypass is blocked by any upstream layer that validates or normalizes `Host`, such as:&lt;/p&gt;
&lt;p&gt;- a CDN or WAF, such as Cloudflare
- a reverse proxy with `server_name` allowlists
- a host-based load balancer&lt;/p&gt;
&lt;p&gt;**LiteLLM Cloud customers are not affected.**&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;Fixed in **`1.84.0`**. Upgrade to `1.84.0` or later. No configuration change is required.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;If upgrading is not immediately possible, place the proxy behind an upstream component that validates or normalizes the `Host` header before forwarding (a CDN/WAF, a reverse proxy with explicit `server_name` allowlists, or a cloud load balancer with host-based routing rules), or otherwise restrict network access to the proxy listener.&lt;/p&gt;
&lt;p&gt;### References&lt;/p&gt;
&lt;p&gt;- Patched release: [`v1.84.0`](https://github.com/BerriAI/litellm/releases/tag/v1.84.0)&lt;/p&gt;
&lt;p&gt;**Discovery Credit**: Le The Thang (KCSC) and Kim Ngoc Chung (One Mount Group)&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-4xpc-pv4p-pm3w</guid>
    </item>
    <item>
      <title>PYSEC-2026-388 — LiteLLM: Authentication Bypass via Host Header Injection</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-388</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: litellm&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;A Host-header parsing flaw in the LiteLLM proxy could, under specific conditions, allow unauthenticated access to protected management routes.
 
The auth layer derived the effective route from `request.url.path` in `litellm/proxy/auth/auth_utils.py::get_request_route()`, which Starlette reconstructs from the `Host` header. A crafted `Host` could therefore make the auth gate evaluate a different route from the one FastAPI dispatched.
 
**Most deployments are not affected.** The bypass is blocked by any upstream layer that validates or normalizes `Host`, such as:&lt;/p&gt;
&lt;p&gt;- a CDN or WAF, such as Cloudflare
 - a reverse proxy with `server_name` allowlists
- a host-based load balancer&lt;/p&gt;
&lt;p&gt;**LiteLLM Cloud customers are not affected.**&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;Fixed in **`1.84.0`**. Upgrade to `1.84.0` or later. No configuration change is required.&lt;/p&gt;
&lt;p&gt;### Workarounds
 
If upgrading is not immediately possible, place the proxy behind an upstream component that validates or normalizes the `Host` header before forwarding (a CDN/WAF, a reverse proxy with explicit `server_name` allowlists, or a cloud load balancer with host-based routing rules), or otherwise restrict network access to the proxy listener.&lt;/p&gt;
&lt;p&gt;### References&lt;/p&gt;
&lt;p&gt;- Patched release: [`v1.84.0`](https://github.com/BerriAI/litellm/releases/tag/v1.84.0)
 
**Discovery Credit**: Le The Thang (KCSC) and Kim Ngoc Chung (One Mount Group)&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: litellm&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;A Host-header parsing flaw in the LiteLLM proxy could, under specific conditions, allow unauthenticated access to protected management routes.
 
The auth layer derived the effective route from `request.url.path` in `litellm/proxy/auth/auth_utils.py::get_request_route()`, which Starlette reconstructs from the `Host` header. A crafted `Host` could therefore make the auth gate evaluate a different route from the one FastAPI dispatched.
 
**Most deployments are not affected.** The bypass is blocked by any upstream layer that validates or normalizes `Host`, such as:&lt;/p&gt;
&lt;p&gt;- a CDN or WAF, such as Cloudflare
 - a reverse proxy with `server_name` allowlists
- a host-based load balancer&lt;/p&gt;
&lt;p&gt;**LiteLLM Cloud customers are not affected.**&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;Fixed in **`1.84.0`**. Upgrade to `1.84.0` or later. No configuration change is required.&lt;/p&gt;
&lt;p&gt;### Workarounds
 
If upgrading is not immediately possible, place the proxy behind an upstream component that validates or normalizes the `Host` header before forwarding (a CDN/WAF, a reverse proxy with explicit `server_name` allowlists, or a cloud load balancer with host-based routing rules), or otherwise restrict network access to the proxy listener.&lt;/p&gt;
&lt;p&gt;### References&lt;/p&gt;
&lt;p&gt;- Patched release: [`v1.84.0`](https://github.com/BerriAI/litellm/releases/tag/v1.84.0)
 
**Discovery Credit**: Le The Thang (KCSC) and Kim Ngoc Chung (One Mount Group)&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-388</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1975 — LiteLLM: Schwachstelle ermöglicht Umgehen von Sicherheitsvorkehrungen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1975</link>
      <description>&lt;p&gt;Ein entfernter, anonymer Angreifer kann eine Schwachstelle in LiteLLM ausnutzen, um Sicherheitsvorkehrungen zu umgehen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein entfernter, anonymer Angreifer kann eine Schwachstelle in LiteLLM ausnutzen, um Sicherheitsvorkehrungen zu umgehen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1975</guid>
    </item>
  </channel>
</rss>
