ProjectSend CVE-2026-112001

The attacker must already possess a valid ProjectSend API token whose abilities are limited to manage_users and edit_users; exploitation is performed by that token issuing PATCH /api/v1/users/{user} against its own token owner's account to set a chosen password and clear two-factor authentication. Limiting factors: this is not remote-unauthenticated - a provisioned, privileged-but-restricted token is a hard prerequisite (PR:H), the target account is specifically the token owner, and only ProjectSend versions 2.0.0 up to (not including) 2.7.0 are affected; upgrading to 2.7.0 (or applying commit db65731) closes it. No end-user interaction is required.

This is a genuine privilege-escalation issue but not a drop-everything emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:N, VC/VI/VA:H, score 8.6) correctly captures a network-reachable, low-complexity flaw whose single real barrier is PR:H - the attacker must already hold a valid ProjectSend API token scoped to manage_users and edit_users. The vulnerability lets that deliberately restricted token exceed its granted abilities by resetting its own owner's password and clearing 2FA (confirmed by the GHSA advisory and the patch diff, which adds ownCredentialChanges() guards and token revocation on password reset). No EPSS score, KEV listing, or public POC was provided, so there is no public exploit identified at time of analysis and no evidence of active exploitation - the real-world signals all point to opportunistic abuse by an already-privileged-but-constrained insider or by anyone who captures a limited token, rather than mass exploitation. Note the tension worth flagging: the input Tags label this 'Authentication Bypass', but CWE-863 and the description make clear it is an incorrect-authorization / privilege-escalation flaw (a limited token exceeding its abilities), not an unauthenticated auth bypass - verify terminology before triaging as pre-auth.

An operator is issued an API token intentionally limited to the manage_users and edit_users abilities, expecting it cannot touch its own owner's login. Because the API fails to block self-credential changes, the token holder sends a PATCH to /api/v1/users/{owner} setting a new password and clearing the owner's two-factor authentication, then logs into the web UI interactively as the owner with the full role the token was never meant to grant. No public exploit code is known, but the request is trivial to craft for anyone holding such a token.