Vikunja Link-Share BOLA Lets Any Share Token Enumerate Usernames and Kanban Data Instance-Wide (CVE-2026-68582)

A newly published GitHub Security Advisory (GHSA-rj9j-8772-4h6c, CVE-2026-68582) details a broken object-level authorization (BOLA) flaw in Vikunja, the open-source project/task management tool. The task-collection endpoint GET /api/v1/projects/{project}/views/{view}/tasks resolves the requested kanban view directly from the URL path before checking whether the caller is authorized for it. For link-share tokens, the task query is correctly scoped to the share's own project, but the view object is not re-validated against that project — a valid share link to any single project can be pointed at any other project's view ID and will return that view's kanban buckets, including each bucket's created_by user object (username, display name, user ID).

Why It Matters

Link sharing is on by default in Vikunja and links are often distributed semi-publicly, so the barrier to exploitation is low — no privileged account is required. Because Vikunja auto-provisions a default project and kanban view for every user, an attacker who iterates sequential project/view IDs can effectively enumerate usernames and user IDs for most or all accounts on an instance, alongside bucket titles for every kanban view. The advisory notes that the same missing authorization check also creates a 404-vs-non-404 existence oracle for project/view IDs, usable by link shares and ordinary authenticated users. The researcher's analysis indicates victim task contents are not exposed through this path — the leak is limited to bucket structure and creator identity — but cross-tenant PII disclosure and reconnaissance at this scale is still a meaningful breach of the isolation the permission model is supposed to provide, particularly for self-hosted, multi-tenant Vikunja deployments.

What Defenders Should Do Now

• Identify any self-hosted Vikunja instances in your environment and check the vendor advisory for a patched release before applying it.
• If link sharing cannot be disabled immediately, treat existing share links as higher-risk and consider rotating/revoking them, especially on multi-tenant or publicly reachable instances.
• Review access logs for authenticated requests to /api/v1/projects/*/views/*/tasks that reference project IDs outside what a given share token or user should have, and watch for sequential ID-sweeping patterns (rapid, incrementing project/view IDs from a single client) indicative of enumeration.
• At a design level, this is a reminder to audit any endpoint where an authorization branch (e.g., a link-share code path) re-derives a resource from attacker-controlled URL parameters instead of validating it against the already-scoped principal — the same class of bug can recur elsewhere in similar object-sharing features.

This is a same-day, developing item — the advisory's proof-of-concept and recommended fix are detailed, but downstream patch availability and real-world exploitation reports should be monitored as they emerge. See the original GitHub Security Advisory for full technical detail: GHSA-rj9j-8772-4h6c.