KEVWire

Security intelligence, with context.

Response snapshot Oct 27, 2026, 16:01 UTC

Back to the wire
Permalink
VulnerabilityGHSA-4hv6-xc92-j86g

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

Vikunja v2.6.0 introduced server-side sessions with revocation semantics: `DELETE /api/v2/user/sessions/{id}` documents "Revokes a specific session by its UUID", and enabling TOTP calls `DeleteAllUserSessions` to invalidate all sessions.

Published Updated

At a glance

Exploited
Not known
Severity
Not scored yet
Chance of exploitation
Not estimated
Sources
1 source

What to do

GitHub lists first patched versions: code.vikunja.io/api: 2.7.0. Confirm the affected range and upgrade guidance in the exact advisory.

Read GitHub-reviewed advisory GHSA-4hv6-xc92-j86g (opens a new tab)

What happened

### Summary

Vikunja v2.6.0 introduced server-side sessions with revocation semantics: `DELETE /api/v2/user/sessions/{id}` documents "Revokes a specific session by its UUID", and enabling TOTP calls `DeleteAllUserSessions` to invalidate all sessions. The WebSocket endpoint accepts any cryptographically valid user JWT without ever resolving its `sid` (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

Continue reading

User access JWTs carry a session reference: `NewUserJWTAuthtoken` (`pkg/modules/auth/auth.go:188`) sets `claims["sid"] = sessionID`, 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 `GET /api/v2/ws` authenticates through the first client message. `Connection.handleAuth` (`pkg/websocket/connection.go:168`) validates the token exclusively with `auth.GetUserIDFromToken` (`pkg/modules/auth/auth.go:292`):

```go func GetUserIDFromToken(tokenString string) (int64, error) { token, err := jwt.Parse(tokenString, func(_ *jwt.Token) (any, error) { return []byte(config.ServiceSecret.GetString()), nil }) ... typ, ok := claims["type"].(float64) if !ok || int(typ) != AuthTypeUser { return 0, jwt.ErrTokenInvalidClaims } ... } ```

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 `DELETE /api/v2/user/sessions/{id}` (or before TOTP enable, which runs `models.DeleteAllUserSessions`, `pkg/routes/api/v2/user_totp.go:208`) remains registered in the hub and keeps receiving every subscribed event, such as `notification.created` 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, so a session the user believes revoked retains a live, server-pushed data channel with no time bound.

### PoC

> [vikunja-ws-auth-ignores-session-revocation-PoC.zip](https://github.com/user-attachments/files/32741065/vikunja-ws-auth-ignores-session-revocation-PoC.zip)

The attached archive contains `deployment/deploy.sh` (local Vikunja v2.6.0 on loopback with SQLite) and `poc/poc.sh` running `poc/poc.py`:

1. Victim registers and logs in. Second user registers for later interaction. 2. Control: the victim's WebSocket authenticates and subscribes to `notification.created`. Negative control: a garbage token is rejected with `invalid_token`. 3. Every victim session is deleted via `DELETE /api/v2/user/sessions/{id}` (the list afterwards reports 0 remaining). 4.

Exploit A: a brand-new WebSocket connection authenticates successfully with the deleted-session token. 5. Exploit B: the second user comments on a task mentioning the victim. The victim's pre-revocation WebSocket connection receives the `notification.created` push with the full notification payload.

Result: 10 checks passed on two consecutive runs, each from a wiped database.

### Impact

Session revocation, the mechanism a user relies on when a device is lost or a token is suspected stolen, silently excludes the WebSocket channel.

A stolen or leaked access token can be converted into a push channel that survives every revocation action available to the user, including TOTP enrollment whose documented purpose is invalidating all sessions, and keeps delivering the victim's notifications (comment mentions, task and project metadata) until the attacker chooses to disconnect.

The fix is to resolve the `sid` claim against the sessions table during `handleAuth` and to re-validate or drop hub connections when their session is deleted.

Affected package ranges reported by GitHub: code.vikunja.io/api: >= 2.3.0, <= 2.6.0

Related technology

Sources

  1. Primary source

    GitHub-reviewed advisory GHSA-4hv6-xc92-j86g (opens a new tab)

    The public advisory supplies the description, affected package/version ranges, and any listed CVSS metric. GitHub review is not local review.

    Published Checked

  2. Primary source

    GitHub public advisory API page (opens a new tab)

    The API page supplied GHSA-4hv6-xc92-j86g, its actual identifiers, source dates, and structured metrics.

    Published Date not suppliedChecked

Cite this record

For factual claims, cite the primary sources above; cite KEVWire for its compilation, dates, and classifications.

APA

KEVWire. (2026, October 27). Vikunja: WebSocket authentication ignores server-side session state, so revoked sessions keep receiving live pushes. https://kevwire.com/record/GHSA-4hv6-xc92-j86g

MLA

"Vikunja: WebSocket authentication ignores server-side session state, so revoked sessions keep receiving live pushes." KEVWire, 27 Oct. 2026, kevwire.com/record/GHSA-4hv6-xc92-j86g.

Chicago

KEVWire. "Vikunja: WebSocket authentication ignores server-side session state, so revoked sessions keep receiving live pushes." Last modified October 27, 2026. https://kevwire.com/record/GHSA-4hv6-xc92-j86g.

Evidence summary (plain text)

Vikunja: WebSocket authentication ignores server-side session state, so revoked sessions keep receiving live pushes (Oct 9, 2026).
Vikunja v2.6.0 introduced server-side sessions with revocation semantics: `DELETE /api/v2/user/sessions/{id}` documents "Revokes a specific session by its UUID", and enabling TOTP calls `DeleteAllUserSessions` to invalidate all sessions. The WebSocket endpoint accepts any cryptographically valid user JWT without ever resolving its `sid` (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.

User access JWTs carry a session reference: `NewUserJWTAuthtoken` (`pkg/modules/auth/auth.go:188`) sets `claims["sid"] = sessionID`, 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).
Sources:
GitHub-reviewed advisory GHSA-4hv6-xc92-j86g: https://github.com/advisories/GHSA-4hv6-xc92-j86g
GitHub public advisory API page: https://api.github.com/advisories?type=reviewed&per_page=100&sort=updated&direction=desc
Record ID: GHSA-4hv6-xc92-j86g.
Record origin: Ingested record.
AI evidence: Not assessed.
Known exploitation: Not assessed.
Zero-day status: Not assessed. KEV membership alone does not establish zero-day status.
About this data

This record was ingested from a data source. Retrieved: Oct 27, 2026, 16:00 UTC. Ingestion is not an independent editorial investigation.

A CISA KEV listing documents known exploitation, not necessarily a zero-day; absence from the catalog does not prove a vulnerability has never been exploited.

Technology tags indicate possible relevance, not verified exposure. Confirm the affected product, version, and configuration against your own inventory; KEVWire does not scan your systems.

A personal reading checklist on this device, not verified remediation.

Record JSON

Your account

Email alerts

Email alerts are not available yet. To follow your stack today, use its RSS feed, which honors your filters, or connect an AI agent through the API.

Suggest an improvement

Ideas, missing sources, corrections, and bugs are all welcome. No account needed. Suggestions are reviewed by a person before anything changes.

Record details

Record detail