CVE-2026-25478
Litestar ≤ 2.20.0
Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:NSummary
CVE-2026-25478 is a high-severity Permissive Cross-domain Security Policy with Untrusted Domains (CWE-942) vulnerability in Litestar Litestar. Its CVSS base score is 7.4 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Drive-by Compromise (T1189); ranked at the 31th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to AC-4 (Information Flow Enforcement) and SC-7 (Boundary Protection) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-25478 affects Litestar, an Asynchronous Server Gateway Interface (ASGI) framework, in versions prior to 2.20.0. The vulnerability arises in the CORSConfig.allowed_origins_regex component, where a regular expression is constructed from configured allowlist values without escaping metacharacters. This regex is then used with Python's fullmatch() function for origin validation, enabling malicious origins to match unexpectedly and bypass intended CORS restrictions. The issue is classified under CWE-942 (Permissive Cross-domain Policy with Untrusted Domains) and carries a CVSS v3.1 base score of 7.4 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N).
An attacker can exploit this vulnerability remotely over the network with low complexity and no required privileges, though it necessitates user interaction, such as tricking a victim into loading a malicious webpage. By crafting an origin string that exploits the unescaped metacharacters in the regex, the attacker can make their domain appear to match the application's allowlist. Successful exploitation changes the scope to high, allowing high-impact confidentiality violations, such as unauthorized access to sensitive data via cross-origin requests that bypass CORS protections.
Litestar addressed this issue in version 2.20.0, as detailed in the project's changelog, release notes, and a specific commit (eb87703b309efcc0d1b087dcb12784e76b003d5a). The GitHub security advisory (GHSA-2p2x-hpg8-cqp2) recommends upgrading to 2.20.0 or later to mitigate the vulnerability by properly escaping metacharacters in the regex construction.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-6496
Vulnerability Data
Litestar is an Asynchronous Server Gateway Interface (ASGI) framework. Prior to 2.20.0, CORSConfig.allowed_origins_regex 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.…
more
The check relies on allowed_origins_regex.fullmatch(origin). This vulnerability is fixed in 2.20.0.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V3.4.3V3.4.6V3.5.2
Mitigating Controls (NIST 800-53 r5) AI
Information flow enforcement requires approved authorizations and would reject policies permitting untrusted domains.
Boundary protection at external interfaces stops unauthorized cross-domain communication allowed by permissive policies.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Hardened configuration baselines and reviews directly prevent permissive CSP or cross-domain policies.
Secure SDLC activities include review and testing of web security policies to avoid untrusted domains.
Vulnerability identification processes can surface permissive policy misconfigurations.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can detect overly permissive cross-domain policies but does not prevent their initial introduction.
Network security policies can restrict cross-domain communication but do not specifically mandate strict CSP or cross-domain policy configuration.
Security of network services includes defining allowed endpoints, which can limit untrusted domains but does not directly address web-client policy files.
Web filtering can block untrusted domains at the network level, partially mitigating permissive cross-domain policies.
Application security requirements should specify secure CSP and cross-domain policy settings, directly addressing the weakness.
Secure architecture principles include defining trust boundaries, which can reduce permissive cross-domain allowances.