OpenProject CVE-2026-44733

Exploitation requires the attacker to first possess a valid, active session token for the target OpenProject user account - the CVE description explicitly states the flaw is only exploitable 'with an active session takeover,' which is corroborated by the CVSS AC:H and PR:L ratings. The /api/v3/users/me PATCH endpoint must be network-reachable, which is standard in any default OpenProject deployment. No special non-default configuration is required on the OpenProject side. What limits exploitation: the attacker cannot exploit this from zero - a prior session-compromise primitive (XSS, session fixation, token theft, etc.) is a hard prerequisite; without it, the endpoint is inaccessible. The vulnerability therefore does not enable initial access and is only relevant as a persistence mechanism post-session-takeover.

The CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N scores 5.9 Medium. The AC:H rating is consistent with the description's explicit prerequisite of an 'active session takeover' - the vulnerability cannot be exploited standalone and represents a secondary escalation primitive. PR:L reflects that a valid session (even a low-privilege user session) is required. The C:H rating captures that converting a session into a permanent credential change yields full ongoing confidentiality over that account. EPSS data was not provided in available intelligence; no KEV listing and no known POC further lower the urgency tier. The real-world risk profile is therefore: moderate impact but conditionally exploitable - an attacker who already has a session could use this to entrench persistence before the session expires, making it most dangerous in scenarios where session theft is already possible (e.g., XSS, session fixation, or stolen tokens). It is not an independent initial-access vector. No conflicting signals were observed, though the original CVSS I:L rating may understate integrity impact given that credential modification is typically considered a high-integrity event.

An attacker who has captured a victim's active session token - for example via an XSS vulnerability, session fixation, or a stolen cookie - sends a crafted PATCH request to /api/v3/users/me with a new password value but without supplying the current password. Because the server fails to enforce old-password verification, the password is accepted and changed, locking out the legitimate user and granting the attacker durable account access even after the original session token expires. No public proof-of-concept has been identified at time of analysis.