Vikunja EUVD-2026-103304

Exploitation requires the attacker to possess a valid, non-expired Vikunja user access JWT (a stolen token) for the target user - there is no initial-access path here. The specific defect: the /api/v2/ws WebSocket endpoint authenticates the first client message via GetUserIDFromToken, which checks only JWT signature and token type and never resolves the token's 'sid' session-id claim against the sessions table. The condition that makes it impactful is reliance on server-side session revocation (DELETE /api/v2/user/sessions/{id}, introduced with server-side sessions in 2.6.0) or TOTP enrollment (which triggers DeleteAllUserSessions) as a trust boundary - both silently fail over WebSocket, and even a new WebSocket connection opened with a pre-revocation token is accepted. Limiting factors: affects only versions 2.3.0 through 2.6.0; requires prior token theft; and impact is limited to reading pushed notification content for the compromised account, not account takeover or data modification.

This is a genuine but moderate-priority confidentiality issue, not a critical emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and the 7.1 score reflect network-reachable, low-complexity exploitation, but PR:L is the key limiter: the attacker must already possess a cryptographically valid user access JWT (i.e. a stolen token), so this is a post-compromise session-persistence weakness (CWE-613), not an initial-access vector. Impact is confidentiality-only (VC:H, VI:N, VA:N) - the attacker reads the victim's notification.created pushes (comment, task and project content) but cannot modify data or deny service. No EPSS score, no CISA KEV listing, and no public POC were provided; per precision rules this is 'no public exploit identified at time of analysis.' The advisory originates from VulnCheck as coordinated research rather than observed in-the-wild activity, consistent with the absence of KEV/EPSS signals. The practical risk is real for environments relying on Vikunja's session-revocation or TOTP-enrollment features as a security boundary, because those actions silently fail to cut off live WebSocket access - but it depends entirely on an attacker first stealing a token, which bounds real-world urgency to medium.

An attacker who has stolen a victim's Vikunja user access token (e.g. via XSS, a leaked token, or a shared/compromised device) opens or keeps open a connection to /api/v2/ws. Even after the victim revokes the session via DELETE /api/v2/user/sessions/{id} or enables TOTP (which calls DeleteAllUserSessions), the WebSocket connection stays authenticated and keeps streaming the victim's notification.created events with full comment, task and project content. No public exploit code is identified, but the GHSA advisory documents the exact vulnerable code path.