Spotted what might be an issue in uv.lock around line 1.
Starlette's StaticFiles component contains a HIGH severity SSRF vulnerability on Windows systems. When handling malicious UNC paths (e.g., \attacker.com\share), os.path.realpath() initiates outbound SMB connections before path validation rejects them. This prematurely leaks the underlying service account's NTLMv2 credentials, enabling offline cracking or credential relay attacks. Although the request ultimately returns a 404, the credential exposure poses critical authentication risks requiring immediate remediation.
Something like this might fix it:
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -10,4 +10,4 @@
dependencies = [
'fastapi',
- 'starlette==0.52.1'
+ 'starlette>=1.1.0'
]
# Apply fix:
# 1. Update the dependency constraint as shown above
# 2. Regenerate the lock file: uv lock --upgrade-package starlette
# 3. Apply to environment: uv syncFor reference: rule CVE-2026-48818. Rated high.
If I have misread how this is used, sorry for the noise — feel free to close.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.
Spotted what might be an issue in
uv.lockaround line 1.Starlette's StaticFiles component contains a HIGH severity SSRF vulnerability on Windows systems. When handling malicious UNC paths (e.g., \attacker.com\share), os.path.realpath() initiates outbound SMB connections before path validation rejects them. This prematurely leaks the underlying service account's NTLMv2 credentials, enabling offline cracking or credential relay attacks. Although the request ultimately returns a 404, the credential exposure poses critical authentication risks requiring immediate remediation.
Something like this might fix it:
For reference: rule
CVE-2026-48818. Rated high.If I have misread how this is used, sorry for the noise — feel free to close.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.