Description

A vulnerability was detected in vastsa FileCodeBox up to 2.3. This vulnerability affects the function update_file_usage of the file apps/base/views.py of the component Pickup Limit Handler. Performing a manipulation results in race condition. It is possible to initiate the attack remotely. The exploit is now public and may be used. Upgrading to version 2.5.0 is able to resolve this issue. The patch is named 8d7d856c62d73badd0797eb4daec8d2ff10a403a. Upgrading the affected component is recommended.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.3",
  "pubDate": "2026-08-30T13:16:56.447Z",
  "pubdate": "2026-08-30T13:16:56.447Z",
  "executiveSummary": "A race condition vulnerability has been identified in FileCodeBox versions up to 2.3, specifically within the 'Pickup Limit Handler' component.\nThe vulnerability resides in the update_file_usage function of apps/base/views.py, which manages file usage counters.\nThis flaw allows a remote, unauthenticated attacker to manipulate file usage limits through concurrent request execution.\nThe primary risk implication is the potential for an attacker to bypass file access or download restrictions enforced by the application.\nSince the exploit is currently public, the risk of active exploitation is significant, necessitating immediate action.\nThe vulnerability is resolved in version 2.5.0 via patch 8d7d856c62d73badd0797eb4daec8d2ff10a403a.\nOrganizations using affected versions should prioritize upgrading the component to the patched release to mitigate unauthorized resource access or manipulation.",
  "technicalDetails": "The vulnerability is a time-of-check to time-of-use (TOCTOU) race condition located within the update_file_usage function in apps/base/views.py.\nThis function is responsible for tracking and decrementing the 'Pickup Limit' (the number of times a file can be accessed) when a user retrieves a file from the server.\nThe root cause of the vulnerability is the lack of proper atomicity or synchronization primitives when checking the current limit and updating the record in the database.\nUnder standard operations, the application retrieves the current usage count, verifies it has not reached zero, and then proceeds to decrement the value and initiate the file transfer.\nBy sending a series of rapid, concurrent requests, an attacker can trigger multiple threads to execute the check logic simultaneously before any individual thread has finalized the update to the usage count.\nBecause the threads read the same initial state, they each validate the limit independently, allowing multiple downloads or accesses to proceed even when the intended configuration should have exhausted the allowance after the first successful request.\nThis behavior effectively allows an attacker to bypass the defined download limits or file access quotas enforced by the system.\nThe attack is remotely exploitable, requiring no specific credentials, as it leverages the logic flaw in the handling of public-facing file retrieval operations.\nThe post-exploitation impact includes the potential for unauthorized data exfiltration or mass downloading of restricted files by circumventing the 'Pickup Limit' security control.\nThe implementation of the fix, identified as commit 8d7d856c62d73badd0797eb4daec8d2ff10a403a in version 2.5.0, introduces the necessary locking or atomic database operations required to ensure that each usage update request is processed sequentially or safely, thereby closing the window of opportunity for the race condition to occur.\nThe vulnerability demonstrates the criticality of handling state changes in concurrent web environments, particularly where business logic relies on decrementing counter-based restrictions."
}