Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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. Details In AllowedHostsMiddleware.call, the host value used for validation is resolved as follows: https://github.com/litestar-org/litestar/blob/main/litestar/middleware/allowedhosts.py#L68 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. An attacker can send a request with no Host header and set X-Forwarded-Host to any whitelisted domain, bypassing the…
Recommended action: Upgrade to 2.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Litestar instances which use a template engine in conjunction with CSRF protection are vulnerable to HTML Injection which can be escalated to Cross Site Scripting due to the contents of the CSRF cookie being excluded from automatic escaping by the template engine when configured inline with documentation recommendations. We used the latest Litestar version available via PyPI for this disclosure. At the time of writing, that is version 2.21.0 and we have not validated this against the current latest commit on the main branch. Special Configurations Required For a web application to be vulnerable to this issue, it must: - Use templates to render the content which is returned to the user (e.g. Jinja, Mako, MiniJinja) - Have CSRF protection enabled - Have CSRF inputs enabled (i.e. a hidden form field which contains the CSRF token) Links to relevant documentation for the above configurations: - https://docs.litestar.dev/2/usage/templating.html -…
Recommended action: Upgrade to 2.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
FileStore maps cache keys to filenames using Unicode NFKD normalization and ord() substitution without separators, creating key collisions. When FileStore is used as response-cache backend, an unauthenticated remote attacker can trigger cache key collisions via crafted paths, causing one URL to serve cached responses of another (cache poisoning/mixup) Details litestar.stores.file.safefilename() normalizes input with unicodedata.normalize("NFKD", name) and builds the filename by concatenating c if alphanumeric else str(ord(c)) (no delimiter). This transformation is not injective, e.g.: - "k-" and "k45" both become "k45" (because - ord('-') == 45) - "k/\n" becomes "k4710", colliding with "k4710" - "K" (Kelvin sign) normalizes to "K", colliding with "K" When used in response caching, the default cache key includes request path and sorted query params, which are attacker-controlled. PoC Impact Vulnerability type: cache poisoning / cache key collision. Impacted deployments:…
Recommended action: Upgrade to 2.20.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
AllowedHosts host validation can be bypassed because configured host patterns are turned into regular expressions without escaping regex metacharacters (notably .). A configured allowlist entry like example.com can match exampleXcom Details In litestar.middleware.allowedhosts, allowlist entries are compiled into regex patterns in a way that allows regex metacharacters to retain special meaning (e.g., . matches any character). This enables a bypass where an attacker supplies a host that matches the regex but is not the intended literal hostname. PoC Server (pocallowedhostsserver.py) uvicorn pocallowedhostsserver:app --host 127.0.0.1 --port 8001 Client (pocallowedhostsclient.py) Expected (vulnerable behavior): Host: evil.com → 400 invalid host Host: exampleXcom → 200 ok (bypass) Impact Type: security control bypass (host allowlist) Who is impacted: apps relying on AllowedHosts to prevent Host header attacks (cache poisoning, absolute URL construction abuse, password reset link…
Recommended action: Upgrade to 2.20.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
CORS origin validation can be bypassed because the allowed-origins allowlist is compiled into a regex without escaping metacharacters (notably .). An allowed origin like https://good.example can match https://goodXexample, resulting in Access-Control-Allow-Origin being set for an untrusted origin Details CORSConfig.allowedoriginsregex is constructed using a regex built from configured allowlist values and used with fullmatch() for validation. Because metacharacters are not escaped, a malicious origin can match unexpectedly. The check relies on allowedoriginsregex.fullmatch(origin). PoC Server (poccorsserver.py) uvicorn poccorsserver:app --host 127.0.0.1 --port 8002 Client (poccorsclient.py) Expected (vulnerable behavior): Origin: https://evil.example → no ACAO Origin: https://goodXexample → ACAO: https://goodxexample/ (bypass) Impact Type: CORS policy bypass (cross-origin data exposure risk) Who is impacted: apps using CORS allowlists to restrict browser cross-origin reads.…
Recommended action: Upgrade to 2.20.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
While testing Litestar's RateLimitMiddleware, I discovered that rate limits can be completely bypassed by manipulating the X-Forwarded-For header. This renders IP-based rate limiting ineffective against determined attackers. The Problem Litestar's RateLimitMiddleware uses cachekeyfromrequest() to generate cache keys for rate limiting. When an X-Forwarded-For header is present, the middleware trusts it unconditionally and uses its value as part of the client identifier. Since clients can set arbitrary X-Forwarded-For values, each different spoofed IP creates a separate rate limit bucket. An attacker can rotate through different header values to avoid hitting any single bucket's limit. Looking at the relevant code in litestar/middleware/ratelimit.py around line 127, there's no validation of proxy headers or configuration for trusted proxies. Reproduction Steps Here's a minimal test case Testing the bypass Security Impact This vulnerability has several concerning implications: Brute…
Recommended action: Upgrade to 2.18.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Litestar does not escape url paths when logging exceptions. This makes logger vulnerable to CRLF injection if logging level is configured to debug or logexceptions is set to "always", which allows attackers to inject newlines and forge log entries. Details Litestar directly formats unquoted path into exception logs without validation or escaping when using default exception logging handler. https://github.com/litestar-org/litestar/blob/1e0dc7c4d67151c836208a3e360051e983b5083a/litestar/logging/config.py#L145-L150 Attackers can inject newlines in logs by embedding%0d%0a in url path. logexceptions="always" is not enabled by default. However, it is set in the examples of documentation (https://github.com/litestar-org/litestar/blob/1e0dc7c4d67151c836208a3e360051e983b5083a/docs/usage/logging.rst#logging). User will be impacted if they directly copy the logging config from docs. PoC logging: If stacktracks for 404 are configured to be ignored (disablestacktrace={404},), attacker may…
Recommended action: Upgrade to 2.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Local File Inclusion via Path Traversal in LiteStar Static File Serving A Local File Inclusion (LFI) vulnerability has been discovered in the static file serving component of LiteStar. This vulnerability allows attackers to exploit path traversal flaws, enabling unauthorized access to sensitive files outside the designated directories. Such access can lead to the disclosure of sensitive information or potentially compromise the server. Details The vulnerability is located in the file path handling mechanism within the static content serving function, specifically at line 70 in litestar/staticfiles/base.py. The function fails to properly validate the destination file path derived from user input, thereby permitting directory traversal. The critical code segment is as follows: Given the variables: The function outputs '/Users/brian/sandbox/testvuln/static', incorrectly assuming it is confined to the static directory. This incorrect validation facilitates directory traversal,…
Recommended action: Upgrade to 2.8.3, 2.7.2 or 2.6.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.