Sirdorblu

**Name of the Vulnerable Software and Affected Versions** Litestar versions prior to 2.20.0 **Description** Litestar is an Asynchronous Server Gateway Interface (ASGI) framework. Prior to version 2.20.0, the CORS origin validation process can be bypassed. This occurs because the allowed-origins allowlist is compiled into a regular expression without properly escaping metacharacters. Specifically, the `allowed origins regex` is constructed using configured allowlist values and used with `fullmatch()` for validation. A malicious origin can unexpectedly match due to the lack of escaping, potentially leading to cross-origin data exposure if `allow credentials` is set to True and authenticated endpoints return sensitive data. The vulnerable component is `CORSConfig.allowed origins regex` and the validation relies on `allowed origins regex.fullmatch(origin)`. The issue is related to the use of regular expressions for validating the `Origin` header. **Recommendations** Versions prior to 2.20.0 should be updated to version 2.20.0 or later to address this issue.

**Name of the Vulnerable Software and Affected Versions** Litestar versions prior to 2.20.0 **Description** Litestar’s allowed hosts validation can be bypassed because configured host patterns are converted into regular expressions without escaping regex metacharacters. Specifically, the `.` metacharacter retains its special meaning, allowing an attacker to supply a host that matches the regex but is not the intended literal hostname. This issue affects applications relying on the `AllowedHosts` middleware to prevent Host header attacks, potentially leading to security control bypasses. The vulnerable component is `litestar.middleware.allowed hosts`. The vulnerable parameter is the `allowed hosts` configuration. **Recommendations** Update to Litestar version 2.20.0 or later.

**Name of the Vulnerable Software and Affected Versions** Litestar versions prior to 2.20.0 **Description** Litestar is an Asynchronous Server Gateway Interface (ASGI) framework. When the FileStore is used as a response-cache backend, an unauthenticated remote attacker can trigger cache key collisions via crafted paths. This results in one URL serving cached responses of another, leading to cache poisoning or mixup. The issue arises because FileStore maps cache keys to filenames using Unicode NFKD normalization and ord() substitution without separators, creating key collisions. Specifically, characters like "-" and "k-" can normalize to "k45", and the Kelvin sign "K" can normalize to "K", causing collisions. The default cache key includes request path and sorted query parameters, which are attacker-controlled. **Recommendations** Versions prior to 2.20.0 should be updated to version 2.20.0 or later.