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

Vikunja introduced server-side session revocation in v2.6.0, allowing sessions to be deleted via REST API calls. User JWTs include a session ID claim ('sid') intended to tie tokens to server-side sessions. However, the WebSocket endpoint authenticates tokens by verifying only the signature and token type, without checking the session ID against the sessions table. Consequently, WebSocket connections authenticated before session revocation remain active and continue receiving live push notifications, and new WebSocket connections can be established using revoked tokens. This bypasses session revocation controls on the WebSocket channel, allowing continued data push to revoked sessions indefinitely until the client disconnects.

The vulnerability allows an attacker with a stolen or leaked access token to maintain a persistent WebSocket connection that continues to receive live notifications and data pushes even after the session has been revoked. This undermines session revocation controls, including those triggered by TOTP enrollment, potentially exposing sensitive notification content indefinitely. The impact is limited to confidentiality as the attacker can receive data but cannot modify it. The REST API access tokens expire after 10 minutes, but the WebSocket connection persists without time bound.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The fix involves validating the session ID claim against the sessions table during WebSocket authentication and re-validating or dropping WebSocket connections when their sessions are revoked. Until a patch is available, users should be aware that session revocation does not affect active WebSocket connections.