Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Remote, unauthenticated, low-complexity header spoofing defeats rate limiting to enumerate codes and read others' files (C:H); no integrity or availability impact and no scope change.
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
Lifecycle Timeline
4DescriptionCVE.org
FileCodeBox before 2.4 contains a rate-limit bypass vulnerability in the IPRateLimit class that allows unauthenticated attackers to circumvent request throttling by supplying attacker-controlled X-Real-IP and X-Forwarded-For headers without verification of trusted reverse proxy origin. Attackers can supply unique spoofed IP values on each request to enumerate all possible share codes and retrieve other users' files without authentication.
AnalysisAI
Unauthenticated information disclosure in FileCodeBox before 2.4 lets remote attackers defeat the IPRateLimit anti-bruteforce control by spoofing X-Real-IP and X-Forwarded-For headers, which the application trusted without verifying the request originated from a configured reverse proxy. By rotating a unique fake IP on every request, an attacker resets their throttling counter indefinitely and can brute-force the short share codes to download other users' files. CVSS 4.0 is 8.7 (high), the fix shipped in release V2.4, and no public exploit or CISA KEV listing was identified at time of analysis.
Technical ContextAI
FileCodeBox is a self-hosted Python (FastAPI-style) file- and text-sharing application where uploads are retrieved by short share codes. The vulnerable IPRateLimit dependency derived the client identity directly from request.headers 'X-Real-IP' or 'X-Forwarded-For', falling back to request.client.host. Because these HTTP headers are attacker-controllable and were accepted without checking whether request.client.host is an approved proxy, the per-IP request counter keyed off a value the attacker fully controls. This is a textbook CWE-348 (Use of Less Trusted Source / reliance on untrusted input for a security decision): a spoofable header is used as the authority for rate-limit accounting. The commit (1b6d8e72) adds a get_client_ip() routine that only honors forwarded headers when request.client.host matches a new trustedProxies allowlist, and separately hardens code generation by switching from the predictable random module to the secrets module, indicating the underlying share codes were also weak (5-digit numeric, get_random_num returning 10000-99999).
RemediationAI
Upgrade to FileCodeBox V2.4, which adds a trustedProxies allowlist so forwarded IP headers are only honored when the direct connection originates from a configured proxy (release: https://github.com/vastsa/FileCodeBox/releases/tag/V2.4, commit 1b6d8e72). After upgrading, explicitly populate the new trustedProxies setting with your reverse proxy's address(es); leaving it empty causes the app to key rate limiting off the real socket address, which is correct for direct deployments but will collapse all users behind a proxy into one IP. If you cannot upgrade immediately, place FileCodeBox behind a reverse proxy (nginx/Caddy/Traefik) configured to strip or overwrite inbound X-Real-IP and X-Forwarded-For with the true client address so the app cannot be fed spoofed values, and restrict network access to the retrieval endpoint; the trade-off is that you must ensure the proxy always rewrites, not appends, these headers. Given the small numeric share-code space, also consider migrating to the secret/string code style (secrets-based generation) introduced in the same release to raise brute-force cost.
Same weakness CWE-348 – Use of Less Trusted Source
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-46069
GHSA-q7qg-rc6j-fpwp