CVE-2026-123528: Security vulnerability

Published Nov 8, 2026

Updated

Vikunja before 2.7.1 contains an insufficient session expiration vulnerability that allows holders of revoked access tokens to keep authenticating because SetupTokenMiddleware skips session and account-status checks. Attackers with a stolen token can, after logout, password reset, or account disabling, mint OAuth sessions via /oauth/authorize or tk API tokens for persistent access.

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade Vikunja to a version that resolves this vulnerability.
Fixed in 2.7.1

Event History

Nov 8, 2026

CVE Published

via NVD·02:16 AM

Data Sourced

via NVD·02:16 AM

DescriptionSeverityWeakness

Frequently Asked Questions

Who is exposed to this issue?

Vikunja deployments running versions before 2.7.1 are exposed if an attacker possesses a valid access token that is later revoked or should otherwise become unusable.

What does an attacker need to exploit it?

The attacker needs a stolen access token. They can use it after logout, password reset, or account disabling because the affected middleware does not enforce session expiration or account-status checks.

What persistent access can a stolen revoked token provide?

A holder of the token can mint OAuth sessions through /oauth/authorize or create tk_ API tokens, allowing continued authentication after the original token should no longer be valid.

What should be done if token revocation is relied on for containment?

Upgrade Vikunja to 2.7.1 or later. Until then, logout, password resets, and account disabling should not be assumed to invalidate a previously stolen access token.

CVE-2026-123528: Security vulnerability

Remediation

Event History

Frequently Asked Questions

Who is exposed to this issue?

What does an attacker need to exploit it?

What persistent access can a stolen revoked token provide?

What should be done if token revocation is relied on for containment?

Company

Resources

Contact

Frequently Asked Questions

Who is exposed to this issue?

What does an attacker need to exploit it?

What persistent access can a stolen revoked token provide?

What should be done if token revocation is relied on for containment?