CVE-2026-41308

Vulnerability

Analysis

Password Pusher versions prior to 1.69.3 and 2.4.2 contain an authentication bypass vulnerability affecting file-type push creation. The root cause lies in inconsistent enforcement of authentication checks when the application is configured to allow anonymous access (allow_anonymous: true). The code previously only checked Settings.allow_anonymous to decide whether to authenticate, but did not separately enforce authentication for file pushes created via the JSON API. This meant an API endpoint that accepted a :files parameter or a kind: "file" parameter could create a file push without requiring the user to be logged in, even though such operations should be restricted to authenticated users [1][2].

Exploitation

An unauthenticated attacker can exploit this by sending a crafted POST request to the generic JSON API create path (e.g., /p.json or the v2 API endpoint) that includes either a files key or sets kind: "file". No prior authentication or session is needed. However, exploitation depends on the application configuration: file push functionality must be enabled, and anonymous creation must not be fully disabled (i.e., allow_anonymous must be true). If allow_anonymous is set to false, the vulnerability does not apply because all create actions already require authentication [1][2].

Impact

The primary impact is unauthorized creation of file-type pushes, leading to potential resource exhaustion (storage and bandwidth) from an unauthenticated actor. The advisory notes no direct data confidentiality impact from this issue alone, but the ability to store arbitrary data without authentication could be leveraged in combination with other weaknesses or for denial-of-service [2].

Mitigation

Both affected series have been patched: OSS v1 users should upgrade to v1.69.4 (or v1.69.3 if v1.69.4 is not available), and v2 users should upgrade to v2.4.2. The fix ensures authentication is consistently enforced for any create request that indicates file intent, across all supported API paths [1][3]. If immediate upgrade is not possible, administrators can mitigate the risk by disabling anonymous creation (allow_anonymous: false), disabling file push functionality entirely, or blocking untrusted API traffic at a reverse proxy or WAF [2].