Summary
ProjectSend contains an incorrect authorization vulnerability in its user management API that can allow a restricted API token holder to modify the credentials and security settings of the token owner. Under deployments where tokens with user-management permissions can reach the affected update operation, an attacker may set a new password, disable two-factor authentication, and sign in with the owner's broader privileges.
ProjectSend contains an incorrect authorization vulnerability in its user management API that can allow a restricted API token holder to modify the credentials and security settings of the token owner. Under deployments where tokens with user-management permissions can reach the affected update operation, an attacker may set a new password, disable two-factor authentication, and sign in with the owner's broader privileges.
Affected context
The issue occurs in ProjectSend deployments exposing the affected PATCH /api/v1/users/{user} endpoint to API tokens that have permissions such as manage_users and edit_users but are intended to have restricted scope. Risk increases when authorization checks do not adequately distinguish the token owner from the target user or do not prevent changes to sensitive credential and authentication attributes.
The issue occurs in ProjectSend deployments exposing the affected PATCH /api/v1/users/{user} endpoint to API tokens that have permissions such as manage_users and edit_users but are intended to have restricted scope. Risk increases when authorization checks do not adequately distinguish the token owner from the target user or do not prevent changes to sensitive credential and authentication attributes.
Exploit preconditions
- Attack surface: ProjectSend's user-management API - Required access: A valid API token with permissions that allow user
management and editing
- Target condition: The token must be able to address the token owner's user
record through the affected update operation
- Trigger point: A PATCH request that changes credential or authentication
settings
- Why exploitation is possible: Authorization enforcement permits a
restricted token to modify security-sensitive properties belonging to an
account with broader privileges
- Attack surface: ProjectSend's user-management API - Required access: A valid API token with permissions that allow user
management and editing
- Target condition: The token must be able to address the token owner's user
record through the affected update operation
- Trigger point: A PATCH request that changes credential or authentication
settings
- Why exploitation is possible: Authorization enforcement permits a
restricted token to modify security-sensitive properties belonging to an
account with broader privileges
Why this happens
The underlying bug is an authorization decision that grants access based on general user-editing permissions without applying sufficiently specific controls to sensitive fields or target identities. This violates CWE-863, Incorrect Authorization, because the application permits an authenticated principal to perform an operation outside the authority intended for that principal. Credential changes and two-factor authentication settings are treated as ordinary editable attributes rather than privileged security operations.
The underlying bug is an authorization decision that grants access based on general user-editing permissions without applying sufficiently specific controls to sensitive fields or target identities. This violates CWE-863, Incorrect Authorization, because the application permits an authenticated principal to perform an operation outside the authority intended for that principal. Credential changes and two-factor authentication settings are treated as ordinary editable attributes rather than privileged security operations.
Potential impact
- An attacker may take over the token owner's interactive account.
- The attacker could clear two-factor authentication and weaken account protection.
- The attacker may obtain the owner's full role permissions after signing in.
- The attacker could modify users, files, or other resources accessible to the owner.
- The compromise could support persistence or further privilege escalation.
- An attacker may take over the token owner's interactive account.
- The attacker could clear two-factor authentication and weaken account protection.
- The attacker may obtain the owner's full role permissions after signing in.
- The attacker could modify users, files, or other resources accessible to the owner.
- The compromise could support persistence or further privilege escalation.
General mitigation guidance
Mitigation generally focuses on enforcing authorization at both the target object and individual field levels. Sensitive operations such as password changes, two-factor authentication changes, role changes, and token administration should use dedicated authorization rules and, where appropriate, require reauthentication or an owner-specific verification step. API tokens should be narrowly scoped, credential updates should be denied by default for delegated management roles, and service accounts should operate with least privilege. Input schemas should explicitly separate ordinary profile attributes from security-sensitive fields, while audit logging and token revocation controls can limit exposure after suspected misuse.
Mitigation generally focuses on enforcing authorization at both the target object and individual field levels. Sensitive operations such as password changes, two-factor authentication changes, role changes, and token administration should use dedicated authorization rules and, where appropriate, require reauthentication or an owner-specific verification step. API tokens should be narrowly scoped, credential updates should be denied by default for delegated management roles, and service accounts should operate with least privilege. Input schemas should explicitly separate ordinary profile attributes from security-sensitive fields, while audit logging and token revocation controls can limit exposure after suspected misuse.
How teams detect issues like this
Detection can include static and dynamic analysis for API handlers that authorize broad update operations without field-level checks, especially routes accepting user identifiers and credential-related properties. Code review should look for authorization decisions based only on endpoint-level permissions, missing ownership checks, and shared update serializers for profile and security fields. Policy enforcement can require explicit authorization tests for password, MFA, role, and token changes, with negative tests confirming that delegated tokens cannot alter privileged accounts. Monitoring can flag unusual credential changes, MFA removal, or interactive logins following API activity.
Detection can include static and dynamic analysis for API handlers that authorize broad update operations without field-level checks, especially routes accepting user identifiers and credential-related properties. Code review should look for authorization decisions based only on endpoint-level permissions, missing ownership checks, and shared update serializers for profile and security fields. Policy enforcement can require explicit authorization tests for password, MFA, role, and token changes, with negative tests confirming that delegated tokens cannot alter privileged accounts. Monitoring can flag unusual credential changes, MFA removal, or interactive logins following API activity.
