Vulnerabilities

Security incident · CVE-2026-111917

Vikunja: WebSocket authentication ignores server-side session state, so revoked sessions keep receiving live pushes

Published Oct 9, 2026 · catalog updated Oct 18, 2026 · Vikunja: WebSocket authentication ignores

Open the advisory

Exploitation likelihood is not on this record for CVE-2026-111917. A missing EPSS score is not a low risk. Compare Vikunja: WebSocket authentication ignores with the linked advisory before you change production.

Severity

High7.1

Known exploitation

Not in CISA/VulnCheck KEV

EPSS

Not in the current FIRST EPSS dataset

Remediation

Advisory link

Affected products

Go code.vikunja.io/api

### Summary Vikunja v2.6.0 introduced server-side sessions with revocation semantics: documents "Revokes a specific session by its UUID", and enabling TOTP calls to invalidate all sessions. The WebSocket endpoint accepts any cryptographically valid user JWT without ever resolving its (session id) claim against the sessions table. A connection authenticated before revocation stays authenticated and continues to receive live pushes indefinitely, and even brand-new WebSocket connections are accepted with a token whose session was deleted. The revocation feature therefore does not cover the WebSocket boundary at all. ### Details User access JWTs carry a session reference: ( ) sets , and the API login-session documentation describes the claim as tying the JWT to a server-side session. On the HTTP side nothing consumes the claim per request either (REST access tokens simply expire after their short TTL, a design the maintainers documented when fixing GHSA-96q5, and refresh tokens are correctly invalidated when the session row is deleted). The WebSocket endpoint authenticates through the first client message. ( ) validates the token exclusively with ( ): The function verifies signature and token type only. No session lookup occurs anywhere in the WebSocket path, and no re-validation happens after the initial auth. Consequently: 1. A connection authenticated before (or before TOTP enable, which runs , ) remains registered in the hub and keeps receiving every subscribed event, such as with the full notification object including comment, task and project content. 2. A new connection opened after the deletion, using the same pre-revocation token, authenticates successfully. 3. Session deletion is observable only in the REST surface. The user's session list empties, the refresh token dies on next use, but the WebSocket channel never notices. For REST the exposure is bounded by the 10-minute access-token TTL. For WebSocket it is not: a connection lives until the client closes it