CVE-2026-112001 in ProjectSend
Summary
by MITRE • 10/18/2026
ProjectSend 2.0.0 before 2.7.0 contains an incorrect authorization vulnerability that allows restricted API token holders to change the token owner's credentials via PATCH /api/v1/users/{user}. Attackers with a token limited to manage_users and edit_users can set a new owner password, clear two-factor authentication, and sign in interactively with the owner's full role permissions.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified in ProjectSend versions prior to 2.7.0 represents a critical failure in access control mechanisms within its RESTful API implementation. Specifically, this flaw is classified as an insecure direct object reference combined with broken authorization logic, allowing attackers possessing restricted API tokens to escalate their privileges significantly. The core issue resides in the PATCH /api/v1/users/{user} endpoint, which fails to adequately verify whether the authenticated user associated with the provided token has sufficient permissions to modify the attributes of the target user account specified by the {user} identifier. This misconfiguration enables individuals holding tokens scoped only for managing and editing users to bypass intended restrictions and alter critical security settings belonging to other accounts, particularly those owned or controlled by administrators or higher-privileged entities.
From a technical perspective, the vulnerability exploits the lack of proper ownership validation during credential modification operations. When an attacker utilizes a token with manage_users and edit_users permissions, they can send a request to update the password field for any user ID accessible via the API. Crucially, this capability extends beyond simple password changes; it includes the ability to clear two-factor authentication settings associated with the target account. By removing these additional layers of security verification, the attacker effectively neutralizes multi-factor protection mechanisms that would otherwise prevent unauthorized access even if credentials were compromised. This action transforms a limited administrative token into a full-access vector for any targeted user account within the system.
The operational impact of this vulnerability is severe, as it facilitates complete account takeover without requiring knowledge of existing passwords or bypassing complex cryptographic challenges directly. Once an attacker successfully changes the password and disables two-factor authentication on a high-privilege account, they can interactively log in to the ProjectSend platform using standard web interfaces. This grants them full role permissions associated with that user, potentially including access to sensitive files, client data, billing information, and system configuration settings. The ability to impersonate legitimate users undermines the integrity of the entire application environment, leading to potential data breaches, unauthorized file modifications, or further lateral movement within connected systems if API keys are reused elsewhere.
This flaw aligns with CWE-269 Improper Privilege Management and CWE-862 Missing Authorization in standard vulnerability classification taxonomies. It also maps closely to the MITRE ATT&CK technique T1078 Valid Accounts, where adversaries leverage legitimate credentials or tokens to gain initial access and maintain persistence within a networked environment. The specific behavior of clearing two-factor authentication corresponds to techniques aimed at reducing detection risk by removing security controls that trigger alerts upon anomalous login attempts. Organizations relying on ProjectSend for file sharing must recognize that this vulnerability allows privilege escalation from limited administrative roles to full system compromise, highlighting the necessity of strict input validation and context-aware authorization checks in all API endpoints handling sensitive user data modifications.
Mitigation strategies primarily involve upgrading to ProjectSend version 2.7.0 or later, where these access control flaws have been addressed through improved permission verification logic. Until an upgrade is feasible, administrators should implement network-level controls such as web application firewalls that restrict access to the /api/v1/users/ endpoint based on IP reputation and behavioral analysis. Additionally, enforcing strict token scoping policies at the identity provider level can limit the blast radius of compromised tokens by ensuring they cannot be used for cross-user modifications unless explicitly authorized through multi-factor approval workflows. Regular auditing of API usage logs is also recommended to detect unusual patterns such as rapid password changes or two-factor authentication disablements originating from single IP addresses or token identifiers, which may indicate active exploitation attempts.