CVE-2026-87816 in PasswordPusher
Summary
by MITRE • 09/09/2026
PasswordPusher before 2.11.1 contains a time-of-check-to-time-of-use race condition in view limit enforcement that allows unauthenticated attackers to bypass expire_after_views limits. Attackers can send concurrent requests to the show endpoint to access one-time secrets multiple times before the view count is incremented and the push expires.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
PasswordPusher versions prior to 2.11.1 are susceptible to a critical time-of-check-to-time-of-use race condition vulnerability within its view limit enforcement mechanism. This flaw specifically affects the logic that governs expire_after_views, a security feature designed to restrict access to shared secrets or files to a single use. The underlying technical issue stems from an atomicity failure in the application's backend processing of requests directed at the show endpoint. When multiple concurrent HTTP requests are sent by an unauthenticated attacker targeting the same secret link, the system fails to properly serialize these operations. Consequently, each request reads the current view count before any single request has successfully incremented it and updated the database state. This creates a window where the application perceives the limit as not yet reached for all incoming parallel requests, allowing multiple clients to retrieve the sensitive data simultaneously despite the configuration intending to permit only one access.
The operational impact of this vulnerability is significant because it completely undermines the core security promise of PasswordPusher's ephemeral sharing model. Users rely on these view limits to ensure that confidential information such as passwords, API keys, or private documents are not exposed beyond their intended lifespan and usage count. By exploiting this race condition, an attacker can bypass the expiration logic entirely, potentially accessing the secret multiple times in rapid succession. This behavior violates the principle of least privilege for data access and compromises confidentiality. In scenarios where secrets are meant to be used only once, such as one-time passwords or initial setup credentials, successful exploitation could allow unauthorized parties to capture these values before they can be rotated or invalidated by the legitimate user, leading to potential account compromise or further lateral movement within a targeted environment.
From a classification perspective, this vulnerability aligns with CWE-362, which describes concurrent execution using shared resources with improper synchronization. The lack of proper locking mechanisms when updating the view counter allows for the race condition to occur. Furthermore, in the context of the MITRE ATT&CK framework, this technique relates to resource hijacking and potentially privilege escalation if the accessed secrets grant elevated permissions. It also touches upon CWE-20 regarding improper input validation where concurrent inputs are not handled with appropriate atomic operations. The vulnerability highlights a common pitfall in web application development where state changes dependent on external triggers must be protected against timing attacks through robust transactional integrity or database-level locking strategies rather than relying solely on application-layer counters that can be manipulated via concurrency.
To mitigate this risk, organizations running PasswordPusher versions earlier than 2.11.1 should immediately upgrade to the patched version where atomic operations have been implemented for view counting. If upgrading is not immediately feasible, administrators can implement a temporary workaround by restricting access to the application through network-level controls such as firewalls or Web Application Firewalls that limit request rates from single IP addresses, thereby reducing the likelihood of successful concurrent requests. Additionally, enabling strict authentication requirements where possible reduces the attack surface for unauthenticated actors. It is also advisable to review logging mechanisms to detect patterns indicative of race condition exploitation, such as a high volume of rapid successive GET requests against the same secret ID. Regular security audits and code reviews focusing on concurrency handling in stateful operations are recommended to prevent similar vulnerabilities in future development cycles.