CVE-2026-50139 in goshs
Summary
by MITRE • 08/18/2026
goshs is a SimpleHTTPServer written in Go. Prior to version 2.1.0, `ShareHandler` reads the share token's `DownloadLimit` under `RLock`, releases the lock, serves the file, then re-acquires the lock to increment the counter. Concurrent requests all read the same `Downloaded`/`DownloadLimit` snapshot, all pass the check, and all are served — exceeding the operator's intended cap. Version 2.1.0 patches the issue.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in goshs prior to version 2.1.0 represents a classic race condition within its HTTP file serving logic, specifically affecting the enforcement of download limits for shared resources. As a SimpleHTTPServer implemented in Go, goshs utilizes standard concurrency primitives such as read-write locks (RLock) to manage state access across multiple goroutines handling concurrent requests. The core flaw resides in the ShareHandler function, which is responsible for validating whether a user has exceeded their allocated download quota before serving a file. This handler employs an RLock to safely read the current value of the Downloaded counter and compare it against the configured DownloadLimit. However, the implementation exhibits a critical time-of-check-to-time-of-use (TOCTOU) flaw by releasing this lock immediately after performing the validation check but prior to actually incrementing the download counter upon successful file transmission.
This architectural decision creates a significant window of vulnerability where concurrent requests can exploit the lack of atomicity in the read-modify-write cycle. When multiple clients initiate downloads simultaneously, each request acquires an RLock, reads the current state of the Downloaded variable which is still below the limit, and then releases the lock to proceed with serving the file content over the network. Because the counter increment occurs only after the file has been served and a new lock acquisition takes place, all concurrent requests effectively operate on a stale snapshot of the download count. Consequently, every request perceives itself as being within the allowed quota, passes the validation check, and proceeds to serve the data. This results in the total number of downloads exceeding the operator-defined cap, completely undermining the intended resource management policy.
The operational impact of this vulnerability is primarily related to resource exhaustion and unauthorized access control bypass. For operators relying on goshs to distribute files with strict download limits, such as licensed software or limited-time offers, this flaw allows users to circumvent these restrictions without authentication failures or explicit errors. In a high-concurrency environment, the discrepancy between the intended limit and actual downloads can be substantial, potentially leading to bandwidth exhaustion if large files are involved. Furthermore, while goshs is primarily a file server, the ability to bypass access controls could facilitate further exploitation in integrated systems where download limits correlate with broader security policies or billing mechanisms. The vulnerability does not typically lead to remote code execution but represents a significant failure in enforcing business logic constraints through proper concurrency control.
To mitigate this issue, it is essential to ensure that the check for the download limit and the subsequent increment of the counter are performed atomically within a single critical section protected by an exclusive lock rather than a shared read lock. By using a standard Mutex or upgrading from RLock to WLock during the entire validation-and-update sequence, the system prevents other goroutines from reading stale data while one request is in the process of updating state. Version 2.1.0 of goshs addresses this by restructuring the handler logic to maintain the lock throughout the check and increment operations, thereby ensuring that each download consumes a portion of the quota before subsequent requests can proceed. This aligns with industry best practices for handling shared mutable state in concurrent systems as outlined in CWE-362 regarding race conditions involving simultaneous access. Additionally, developers should adhere to ATT&CK technique T1078, which covers valid accounts and authentication bypasses, by ensuring that resource limits are enforced atomically to prevent circumvention through timing attacks or concurrency exploits.