Gotify Server CVE-2026-102603

Requires the attacker to already possess a valid client token for the target Gotify user account (CVSS PR:L) - this is the exact prerequisite and the primary limiting factor; it is not unauthenticated. Given a valid token, exploitation works against default configurations of Gotify server prior to 3.0.0 because the POST /current/user/password endpoint performs no current-password check and no elevated re-authentication step. Limiting factors: token must be obtained first, so impact is gated by how exposed client tokens are in a given deployment; only versions before 3.0.0 are affected (the fix adds a time-bound client-session elevation requirement).

This is a moderate-severity account-takeover flaw (CWE-620, Unverified Password Change) rather than a top-tier priority. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) confirms the attacker must already hold a valid client token (PR:L), so this is NOT an unauthenticated internet-wide threat - it is a privilege/persistence escalation for someone who has already compromised a token. No EPSS score was provided in the input and the CVE is NOT in CISA KEV, so there is no signal of active exploitation. No public POC is referenced; the GitHub artifacts (PR #952, commit, advisory) are the vendor FIX, not weaponized exploit code, so they should not be mistaken for a POC. SSVC-style reasoning: exploitation is not observed, technical impact is partial (the attacker trades a token they already stole for durable password control), and it is not trivially automatable at scale because token theft is a prerequisite. Net: real but bounded - treat as a routine patch priority for Gotify operators, not an emergency. One caveat to verify: the client-token model means impact depends on what that token could already do.

An attacker who has obtained a user's Gotify client token (e.g., leaked from a misconfigured app, intercepted, or exfiltrated from a client device) sends a POST to /current/user/password with a new password, which the pre-3.0.0 server accepts without asking for the current password. The user is then locked out of password login, and recovery requires an administrator or direct database intervention. No public exploit is identified at time of analysis, and the attack requires a valid client token (not unauthenticated access).