CVE-2026-68581 go-vikunja CVE debrief

Who should care

Vikunja instance administrators, users with API tokens, security teams responsible for monitoring and responding to potential API token abuse, and operators managing user access and authentication in Vikunja deployments. These stakeholders should verify exposure, restrict authenticated user search access, and update to version 2.4.0 or later to mitigate the vulnerability.

Why it matters

CVE-2026-68581 allows an authenticated attacker to manipulate API tokens of another user in Vikunja instances up to version 2.3.0, enabling lateral movement and privilege escalation. Defenders should verify exposure, restrict authenticated user search access, and update to version 2.4.0 or later.

• An attacker can list API-token metadata of another user
• An attacker can issue new API tokens owned by another user
• An attacker can delete target-owned API tokens
• Verification of API token management and user search access controls is required

Technical summary

Vikunja's API token management model treats link-share principals as users, allowing an authenticated attacker to list, issue, and delete API tokens of another user by creating a link share with a colliding ID. This vulnerability exists in Vikunja versions up to 2.3.0 and is fixed in version 2.4.0. The issue arises because Vikunja accepts both regular-user JSON Web Tokens (JWTs) and link-share JWTs through its generic authenticated API route group. A link-share JWT resolves to a models.LinkSharing principal whose GetID() method returns the numeric link_shares.id. The API-token management model then treats that generic numeric value as a users.id when it creates, lists, and deletes API tokens. Because users.id  

Defensive priority

High priority for Vikunja instance administrators and users with API tokens

Recommended defensive actions

• Update Vikunja to version 2.4.0 or later
• Review and revoke any suspicious API tokens
• Monitor API token creation and deletion logs
• Restrict authenticated user search access
• Verify API token management and user search access controls
• Review compensating controls for exposed systems while remediation is scheduled and verified
• Track exceptions, retest remediated assets, and close the item only after evidence is documented

Evidence notes

The vulnerability exists in Vikunja versions up to 2.3.0. The issue is fixed in version 2.4.0. An attacker can exploit this vulnerability by obtaining a target's numeric user ID through authenticated user search and creating link shares on an attacker-writable project.

Sources and references

Methodology and review provenance

AI-assisted synthesis based on stored public vulnerability evidence. System validation, approval state, and publication status do not by themselves establish human review of this revision. PatchSiren helps prioritize defensive review and does not prove exposure or remediation on any system.