FileCodeBox: 5 Critical/High vulns in file share retrieval limits (TOCTOU, IDOR, reusable URL)

FileCodeBox Vulnerability Summary (Issue #482) Vulnerability Overview This issue consolidates 5 high/critical vulnerabilities found in the branch (the latest at the time of the audit), all related to the "retrieval count limit" ( ) of the file sharing feature, covering race conditions, reusable URLs, missing expiration checks, and share code enumeration. Vulnerability List Detailed Findings and POCs Vulnerability 1 — [CRITICAL] TOCTOU Race Condition Causes Complete Bypass of Retrieval Count Limit Location: ( ) + (L292-301) Issue: is a non-atomic read-modify-write: Each concurrent request loads a copy via , modifies it, and writes back all fields. N concurrent requests all read the same (e.g., 1), all decrement it by 1, and all write , causing the final to be overwritten by concurrent writes—this is a classic lost update. Impact: For a file with (allowing retrieval only once), an attacker can issue concurrent requests to retrieve the file N times, completely nullifying the count limit, and is also underestimated (each request writes 0 instead of accumulating). POC: Fix: Replace the check-decrement pattern with a database atomic operation ( ) or use a row lock. Vulnerability 2 — [HIGH] Reusable Download URL Bypasses Count Limit Location: ( ) Issue: The endpoint returns a count and a , but the endpoint only validates a short-lived token ( , ~1000-second window) and does not call (no count decrement). The URL obtained from a single can be reused indefinitely within the token window, and the count limit is only decremented once at . Impact: For a file with , an attacker can perform an infinite number of downloads after a single , rendering the count limit ineffective. POC: Fix: should also call (or decrement once at , with only validating token state). Vulnerability 3 — [HIGH] Missing Expiration Check ( ) Location: ( call) Issue: When calls , it explicitly uses , skipping the expiration check: In contrast: and use the default ; is the sole exception. After a file expires (time limit or count exhaustion), an attacker can still download it before the background cleanup task (every 600 seconds) deletes it. Impact: Expired files remain downloadable, violating the business rule that "expired means inaccessible." Fix: should also use (the default value). Vulnerability 4 — [HIGH] Share Code Enumeration (IDOR) Location: ( ) + Issue: The default share code is a 5-digit number (10000-99999), offering only 90,000 possibilities. The endpoint requires no authentication and does not call (no count decrement). Impact: An attacker can enumerate the entire space (~90,000 codes) to discover all shared files (name, size, type, expiration date), then use to obtain the download address. This can be completed rapidly using a multi-IP pool. POC: Fix: Increase the share code space (e.g., 10-character base36); include endpoint hits in the success count; require authentication if necessary. Vulnerability 5 — [HIGH] Count Limit Bypass (Missing State Machine) Location: + Issue: Same root cause as Vulnerability 2: count decrement occurs only at the endpoint, while does not decrement. is based on and remains unchanged within a ~1000-second window, allowing infinite downloads after a single . Impact: This represents the business logic gap of a "missing state machine" for the count limit. Fix: Same as Vulnerability 2. Summary of Fixes Use a single database with versioning to atomize expiration checks, decrement, and accumulation, eliminating TOCTOU / lost updates; Modify to not perform the decrement; instead, the actual endpoint is responsible for decrementing the count; Object storage files with valid numeric identifiers are decremented only at , and the endpoint does not duplicate the decrement; Restore the expiration check in ; after the fix, using the URL post-expiration returns 404; The endpoint counts successful accesses; New installations default to using Secret retrieval codes, while existing explicit configurations remain unaffected. Status This issue was marked as Closed (Fixed) on Jul 10. Fix commit: (fix: harden share retrieval and admin visibility). Post-fix verification: For , only one out of 20 concurrent requests succeeds; access is rejected upon time expiration or count exhaustion; the download URL fails on secondary use; finite numeric files are no longer exposed; the endpoint now counts successes, with full test coverage of 25 assertions (including 5 subtests).

Goal Reached Thanks to every supporter — we hit 100%!

FileCodeBox: 5 Critical/High vulns in file share retrieval limits (TOCTOU, IDOR, reusable URL)

More from this source