Live › vulnerability › CVE-2026-111917
Go to dashboardVikunja 2.3.0 before 2.7.0 does not check the JWT session ID against active sessions on its WebSocket endpoint, so a revoked session keeps working. An attacker holding a stolen access token keeps receiving the victim's notification pushes, including comment, task and project content.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Self-hosted or managed Vikunja instances running versions from 2.3.0 up to but not including 2.7.0 with WebSocket notifications in use. Exposure requires that an attacker already holds a stolen access token, and the risk is continued reading of notifications after the session was revoked. Instances already on 2.7.0 or later are not affected.
No product ranges from the sources yet.
2.3.0 through 2.6.x are affected./api/v2/ws to users who could have had a session revoked.2.7.0 or later.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-111917")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.