CVE-2026-111917 in Vikunja
Summary
by MITRE • 10/17/2026
Vikunja 2.3.0 before 2.7.0 contains an improper session validation vulnerability that allows attackers to keep WebSocket access after revocation because handleAuth never checks the JWT sid claim against the sessions table. Attackers holding a stolen access token can open or maintain connections to /api/v2/ws after session deletion or TOTP enrollment, continuing to receive the victim's notification.created pushes, including comment, task and project content.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/17/2026
The vulnerability identified in Vikunja versions prior to 2.7.0 represents a critical failure in session management logic within its WebSocket implementation. Specifically, the flaw resides in the handleAuth function which is responsible for validating authentication tokens during WebSocket connection establishment. The core technical deficiency is that this validation process does not verify the JWT sid claim against the active sessions table maintained by the application server. In standard secure implementations, when a user revokes access to an application or changes security settings such as enrolling in Two-Factor Authentication (TOTP), the system should invalidate all associated session tokens immediately. However, because Vikunja fails to cross-reference the token's unique identifier with the current list of valid sessions, it allows previously issued JSON Web Tokens to remain functionally active even after they have been logically revoked by the user or administrator.
This architectural oversight creates a significant window for attackers who possess stolen access tokens to maintain persistent unauthorized access to real-time data streams. Once an attacker obtains a valid JWT through methods such as phishing, cross-site scripting, or network interception, they can establish and sustain WebSocket connections to the /api/v2/ws endpoint. Even if the legitimate user logs out, deletes their session from account settings, or triggers a security reset via TOTP enrollment, the server continues to accept messages sent using the old token. This persistence allows the attacker to remain connected to the victim's real-time notification feed without detection through standard logout procedures.
The operational impact of this vulnerability is severe due to the sensitive nature of the data transmitted over these WebSocket connections. The /api/v2/ws endpoint pushes notifications related to user activity, including new comments on tasks, updates to task statuses, and changes in project configurations. By maintaining an active connection despite session revocation, an attacker can intercept a continuous stream of notification.created events. This provides real-time visibility into the victim's workflow, revealing specific details about ongoing projects, collaborative discussions, and individual task assignments. Such exposure compromises confidentiality and integrity, as attackers gain insight into business operations and personal interactions that were intended to be terminated upon session revocation.
From a classification perspective, this vulnerability aligns with CWE-613, which describes insufficient session expiration, although it is more accurately characterized by CWE-287, Improper Authentication, due to the failure to validate the current state of the user's session against authoritative server-side records. In terms of adversary behavior, this flaw facilitates ATT&CK technique T1504, Web Session Hijacking, as well as T1071, Application Layer Protocol, specifically within WebSocket communications where real-time data exfiltration occurs. The lack of immediate token invalidation upon session revocation undermines the fundamental security principle that user-initiated logout or security changes should result in immediate access termination.
To mitigate this vulnerability, it is imperative to update Vikunja to version 2.7.0 or later, where the handleAuth function has been corrected to properly validate JWT sid claims against the sessions table before allowing WebSocket connections. For organizations unable to patch immediately, implementing a reverse proxy that monitors for session revocation events and actively terminates associated WebSocket upgrades can provide temporary relief. Additionally, reducing token lifetimes through shorter expiration settings limits the window of opportunity for attackers to exploit stolen tokens before they naturally expire. Regular audits of authentication flows should ensure that all stateful resources are properly invalidated when user sessions are terminated or security credentials are rotated.