CVE-2026-25480: 
Python vulnerability analysis and mitigation

CVE-2026-25480 is a cache poisoning / cache key collision vulnerability in the Litestar Python web framework's FileStore backend, titled "FileStore key canonicalization collisions allow response cache mixup/poisoning (ASCII ord + Unicode NFKD)." It affects Litestar versions up to and including 2.19.0, with version 2.20.0 being the first patched release. The vulnerability was published on February 8, 2026, by maintainer provinzkraut, and added to the GitHub Advisory Database on February 9, 2026. It carries a CVSS v3.1 base score of 6.5 (Medium) (Github Advisory, Litestar Advisory).

The root cause lies in the litestar.stores.file._safe_file_name() function, which maps cache keys to filenames using Unicode NFKD normalization followed by concatenation of ord() values for non-alphanumeric characters — without any delimiter between them (CWE-176: Improper Handling of Unicode Encoding; CWE-20: Improper Input Validation). This transformation is non-injective, meaning distinct input strings can produce identical filenames: for example, "k-" and "k45" both normalize to "k45" (since ord('-') == 45), and the Kelvin sign "K" (U+212A) normalizes via NFKD to "K", colliding with the ASCII letter K. Because the default response-cache key in Litestar includes the request path and sorted query parameters — both attacker-controlled — an unauthenticated remote attacker can craft URLs that collide with the cache keys of other URLs. A public proof-of-concept demonstrating the collision is included in the advisory (Github Advisory, Litestar Advisory).

Successful exploitation allows an unauthenticated remote attacker to cause one URL to serve the cached HTTP response of a different URL, resulting in cache poisoning or cache mixup. This can lead to confidentiality breaches — where cached content from one endpoint (potentially containing sensitive user data) is disclosed to users of another endpoint — and integrity issues, where users receive incorrect or unauthorized content. The severity of the impact depends on which endpoints have caching enabled and what sensitive data those responses contain; no availability impact has been identified (Github Advisory).

A proof-of-concept exploit is publicly available in the GitHub Security Advisory and demonstrates the collision behavior directly against the FileStore API (Litestar Advisory). There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.021% (0.000290 as reported by Feedly), placing it in the 6th percentile for exploitation likelihood. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires no authentication, no user interaction, and low attack complexity, making it straightforward for any network-accessible attacker to attempt against vulnerable deployments.

1. Reconnaissance: Identify web applications built on Litestar (versions ≤ 2.19.0) that use the FileStore backend for response caching. This can be done by inspecting HTTP response headers (e.g., x-litestar-cache) or reviewing publicly available source code/configuration.
2. Identify cached endpoints: Probe the target application to discover endpoints with response caching enabled (e.g., endpoints that return consistent responses and include cache-related headers).
3. Compute a colliding cache key: Craft a URL whose path or query parameters, after _safe_file_name() normalization, produce the same filename as a target cached endpoint. For example, if the target endpoint is /k45, craft a request to /k- (since ord('-') == 45 causes "k-" → "k45"). Alternatively, use Unicode characters that NFKD-normalize to ASCII equivalents (e.g., the Kelvin sign K U+212A collides with K).
4. Poison the cache: Send a request to the crafted colliding URL to populate the cache with attacker-influenced content, or trigger a cache read from the colliding key to retrieve cached content intended for a different URL.
5. Harvest or serve malicious content: Subsequent legitimate requests to the target URL will receive the cached response stored under the colliding key, resulting in information disclosure or delivery of incorrect content to other users (Github Advisory, Litestar Advisory).

• Network: Unusual HTTP requests to URL paths containing special characters, Unicode characters (e.g., Kelvin sign U+212A, other Unicode confusables), or numeric sequences that could be crafted to collide with legitimate cache keys; repeated requests to paths that differ only by such characters.
• Logs: Web server or application access logs showing requests to paths with percent-encoded or Unicode characters that map to the same normalized filename as a different cached endpoint; unexpected cache hits for URLs that should not share cached content.
• File System: In the FileStore cache directory, unexpected cache files being accessed or overwritten by requests from unrelated URL paths; cache files whose content does not match the expected response for the corresponding URL.

Upgrade Litestar to version 2.20.0 or later, which replaces the vulnerable _safe_file_name() function with a BLAKE2s hash (hashlib.blake2s(name.encode()).hexdigest()), eliminating all key collision possibilities (Litestar Release, Patch Commit). If immediate patching is not possible, disable FileStore-based response caching or restrict caching to non-sensitive endpoints that do not expose user-specific or confidential data. Additionally, review and audit cached content currently being served by affected applications to detect any potential cache poisoning incidents (Github Advisory).