Joplin Server CVE-2026-105785

Exploitation requires the attacker to ALREADY possess the victim's CSRF, account-confirmation, or email-change token, obtained through a separate disclosure channel independent of this vulnerability - Joplin Server does not itself expose that token. Given that token, the attacker submits it to the public (unauthenticated) password-reset endpoint of Joplin Server versions prior to 3.7.2, where the pre-patch TokenModel stored tokens without a 'purpose' and UserModel.resetPassword accepted any token returned by userFromToken. The dominant limiting factor - and the reason for AC:H - is this hard dependency on an out-of-band token leak; there is no self-contained remote exploitation path. Deployments running Joplin Server 3.7.2 or later (which enforce TokenPurpose.PasswordReset) are not affected.

This is a genuine but conditional authentication-logic flaw (CWE-620, unverified password change) rather than a mass-exploitable critical issue. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N, base 4.8 MEDIUM) is internally consistent with the description: the attack is network-reachable and requires no authentication of the attacker (PR:N), but carries high attack complexity (AC:H) because it is strictly gated on the attacker first obtaining the victim's CSRF or account-confirmation token through a SEPARATE disclosure channel - Joplin itself does not leak that token. No EPSS score, CISA KEV entry, or POC was provided in the intelligence set, so exploitation probability signals are absent; per the precision rules this is 'no public exploit identified at time of analysis.' The SSVC/kill-chain picture is not automatable (it needs a pre-leaked, victim-specific token) and the technical impact is partial (password replacement plus deletion of sessions/API apps), which aligns with the low-to-medium real-world priority implied by the 4.8 base score. The one point worth flagging: the official vector rates confidentiality and integrity only Low and availability None, yet a successful attack is effectively a full account takeover (attacker-set password) combined with destruction of the victim's sessions and API applications - the real impact is arguably higher than C:L/I:L/A:N suggests, so treat the raw base score as a floor, not a ceiling. Net: a legitimate fix-worthy bug, but not a drop-everything emergency absent a known companion token-disclosure vector.

An attacker who has already captured a victim's purpose-less CSRF or email-confirmation token from a separate leak (e.g., referrer/log exposure, XSS, or a misconfigured proxy) replays that token against the public Joplin Server password-reset endpoint. Because TokenModel stored tokens without a purpose and UserModel.resetPassword accepted any token from userFromToken, the server treats the CSRF/confirmation token as a valid reset token, letting the attacker set a new password and take over the account while deleting the victim's active sessions and API applications. No public exploit code was identified at time of analysis, and high attack complexity (AC:H) reflects the required out-of-band token.