<?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://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-28T17:52:55.883413+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" 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://db.gcve.eu/vuln/cve-2026-49468</id>
    <title>CVE-2026-49468 — LiteLLM: Authentication Bypass via Host Header Injection</title>
    <updated>2026-09-28T17:52:55.886206+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> BerriAI litellm, Red Hat Exploit Intelligence, Red Hat Ansible Automation Platform 2, Red Hat OpenShift AI (RHOAI)</p>
<p>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.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/cve-2026-49468"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-4xpc-pv4p-pm3w</id>
    <title>GHSA-4xpc-pv4p-pm3w — LiteLLM: Authentication Bypass via Host Header Injection</title>
    <updated>2026-09-28T17:52:55.886295+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: litellm</p>
<p>### Impact</p>
<p>A Host-header parsing flaw in the LiteLLM proxy could, under specific conditions, allow unauthenticated access to protected management routes.</p>
<p>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.</p>
<p>**Most deployments are not affected.** The bypass is blocked by any upstream layer that validates or normalizes `Host`, such as:</p>
<p>- a CDN or WAF, such as Cloudflare
- a reverse proxy with `server_name` allowlists
- a host-based load balancer</p>
<p>**LiteLLM Cloud customers are not affected.**</p>
<p>### Patches</p>
<p>Fixed in **`1.84.0`**. Upgrade to `1.84.0` or later. No configuration change is required.</p>
<p>### Workarounds</p>
<p>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.</p>
<p>### References</p>
<p>- Patched release: [`v1.84.0`](https://github.com/BerriAI/litellm/releases/tag/v1.84.0)</p>
<p>**Discovery Credit**: Le The Thang (KCSC) and Kim Ngoc Chung (One Mount Group)</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-4xpc-pv4p-pm3w"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/pysec-2026-388</id>
    <title>PYSEC-2026-388 — LiteLLM: Authentication Bypass via Host Header Injection</title>
    <updated>2026-09-28T17:52:55.886343+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: litellm</p>
<p>### Impact</p>
<p>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:</p>
<p>- a CDN or WAF, such as Cloudflare
 - a reverse proxy with `server_name` allowlists
- a host-based load balancer</p>
<p>**LiteLLM Cloud customers are not affected.**</p>
<p>### Patches</p>
<p>Fixed in **`1.84.0`**. Upgrade to `1.84.0` or later. No configuration change is required.</p>
<p>### 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.</p>
<p>### References</p>
<p>- 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)</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/pysec-2026-388"/>
  </entry>
</feed>
