CVE-2026-112002 in ProjectSend
Summary
by MITRE • 10/18/2026
ProjectSend 2.5.0 before 2.7.0 contains an unverified password change vulnerability in PasswordController::update() that lets sessions of Social-provisioned accounts set local passwords without the current password. Attackers holding a stolen session cookie can send PUT /settings/password to create a durable local password, enroll their own second factor, and persistently take over the account.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified in ProjectSend versions prior to 2.7.0 represents a critical authentication bypass flaw located within the PasswordController::update() method. This security defect stems from an insufficient verification of the user's current credentials during the password update process. Specifically, when handling requests for social-provisioned accounts that utilize third-party identity providers such as Google or Facebook, the application fails to require proof of ownership via the existing local password before allowing a new one to be set. This architectural oversight creates a significant gap in the authentication lifecycle, allowing an attacker who has obtained a valid session cookie from a compromised account to bypass traditional credential verification mechanisms entirely.
From a technical perspective, the flaw exploits the logic flow within the PUT /settings/password endpoint. Normally, changing a password requires validating the old password against the stored hash to ensure that only the legitimate user can make such changes. However, in this vulnerable implementation, if the system detects that the account is linked to an external social provider, it skips or inadequately processes the check for the current local password. This allows any actor with a valid session token to send a crafted HTTP PUT request containing a new password and potentially new two-factor authentication details without ever knowing the user's original login credentials. The absence of this verification step effectively neutralizes the security boundary between authenticated sessions and administrative account modifications.
The operational impact of this vulnerability is severe, leading directly to full account takeover. An attacker possessing a stolen session cookie can not only set a durable local password but also enroll their own second-factor authentication methods. This dual action ensures persistent access even if the victim changes their social provider credentials or revokes the specific third-party authorization token. Once the attacker has established control over both the login and multi-factor authentication layers, they gain unrestricted access to all files, settings, and data associated with that ProjectSend account. This can result in significant data exfiltration, unauthorized file manipulation, and potential lateral movement if the compromised account has permissions within a broader network infrastructure.
This vulnerability aligns closely with CWE-287, which describes Improper Authentication, as well as CWE-640, Weak Password Recovery Mechanism for Forgotten Password, due to the bypass of standard recovery or update protocols. In terms of the MITRE ATT&CK framework, this behavior is indicative of T1539 Steal Web Session Cookie and T1078 Valid Accounts, where an adversary leverages stolen credentials to maintain persistent access. The ability to modify security settings like two-factor authentication further relates to T1098 Account Manipulation, as the attacker alters account properties to ensure continued control despite potential remediation attempts by the victim or administrator.
To mitigate this risk, immediate action is required for all administrators running ProjectSend versions 2.5.0 through 2.6.x. The primary mitigation strategy is to upgrade the software to version 2.7.0 or later, where the developers have addressed the logic flaw in PasswordController::update() by enforcing strict verification of current credentials regardless of social provider linkage. In addition to upgrading, organizations should implement robust session management practices, including short-lived session tokens and secure cookie attributes such as HttpOnly and Secure flags to reduce the risk of session hijacking. Furthermore, enabling multi-factor authentication for all administrative accounts adds a critical layer of defense that can prevent account takeover even if session cookies are compromised, provided the initial access does not allow modification of MFA settings themselves. Regular security audits and monitoring for unusual password change activities should also be employed to detect potential exploitation attempts early in the attack chain.