In goshs versions up to 2.0.9, the ShareHandler uses a read lock to check the DownloadLimit and Downloaded count, then releases the lock before serving the file. After serving, it reacquires a write lock to increment the Downloaded count and potentially delete the share link if the limit is reached. This sequence allows concurrent goroutines to observe the same Downloaded count and all pass the limit check, resulting in multiple downloads exceeding the intended cap. The vulnerability is a classic race condition (CWE-362) in concurrent access to shared state. A proof of concept demonstrates that two concurrent requests can both succeed on a single-use token. The suggested fix is to acquire the write lock before serving, increment the counter, and only serve if the limit is not exceeded, refunding the increment if serving fails.

An attacker or multiple concurrent clients can redeem a share link token more times than the configured download limit, effectively bypassing the single-use or limited-use restriction. This increases the risk of unauthorized data exfiltration if the token is leaked or intercepted, as the intended one-time or limited access control is circumvented. The impact is limited to confidentiality as the integrity and availability are not affected.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The recommended fix is to modify the code to acquire the write lock before serving the file, increment the download count under this lock, and only proceed if the limit is not exceeded. If serving fails, the increment should be refunded. Until a patch is available, users should avoid using the share-link feature with download limits or implement external synchronization to prevent concurrent access. No official fix or patch links are currently provided.