ProjectSend EUVD-2026-103455

Exploitation requires that the target account is Social-provisioned (auth_source = Social / signs in through an external provider) AND that the attacker already possesses a valid, active session cookie for that account - these are the exact prerequisites, not generic network access. The flaw is reachable only through the authenticated /settings/password (PUT) endpoint, so a local account with a normal password is unaffected. Limiting factors: the attacker must first steal a live session (via XSS, interception, or device access), the vulnerable code path only triggers for provider/SSO-provisioned accounts, and the installation must be running a version in 2.5.0 before 2.7.0; patched 2.7.0 instead emails a reset link to the account's own address, which a stolen session cannot read.

This is a genuine account-takeover flaw with moderate-but-real risk, best treated as a priority where ProjectSend is deployed with social/provider sign-in. The authoritative CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N) and score of 7.6 (High) are internally consistent with the description: network-reachable, low attack complexity, but gated by an attack requirement (AT:P) and low privileges (PR:L) - the attacker must already hold a valid session cookie for a Social-provisioned account, which is why this is not scored as unauthenticated-trivial. Impact is high on confidentiality and integrity (full, durable account takeover) with no availability impact (VA:N), matching the described outcome. No EPSS score, KEV listing, or POC is present in the provided intelligence, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the practical barrier is session-cookie theft (XSS, network interception, malware, or shared-device exposure), which makes this a strong escalation/persistence primitive rather than a mass-exploitable remote hole. One data-quality conflict: the input Tags label this 'Information Disclosure,' but the description and CWE-620 (unverified password change) describe authentication bypass and persistent account takeover, not disclosure - the tag is mislabeled and should not drive triage.

An attacker who has obtained a valid session cookie for a Social-provisioned (provider/SSO) ProjectSend account - for example via XSS, session interception, or a reused device - sends a crafted PUT /settings/password request. Because PasswordController::update() did not require the current password for provider accounts, the attacker sets a local password, enrolls their own second factor, and converts a temporary session hijack into durable, independent control of the account. No public exploit code is identified in the provided data, but the request is simple and the behavior is deterministic.