Vikunja CVE-2026-68582

The primary bucket-disclosure attack requires the attacker to hold a valid project share-link token for any project on the instance (Vikunja's link-share feature must be enabled and at least one share link must exist); the attacker then supplies a cross-tenant {view} ID in the path of GET /api/v1/projects/{project}/views/{view}/tasks. The lower-impact existence oracle (404 vs non-404) additionally works for any ordinary authenticated user. Exploitation is LIMITED to metadata: only bucket titles and created_by user objects are exposed, task contents remain scoped to the share's own project, and no write access is possible. Affected only on versions 0.24.0 through 2.3.0.

Signals conflict sharply with the headline severity. The published CVSS 4.0 vector (9.3, AV:N/AC:L/PR:N/UI:N/VC:H/VI:H/VA:H) implies unauthenticated total compromise, but the description contradicts the impact metrics: it is a read-only disclosure limited to bucket titles and creator user objects, explicitly noting task contents are NOT disclosed and there is no write or availability impact - so VI:H/VA:H appear overstated and the true impact is confidentiality-only of low-sensitivity metadata. PR:N is also questionable because the primary bucket-read requires possession of a valid project share-link token (a low-privilege credential); only the existence oracle is reachable by any ordinary authenticated user. There is no KEV listing and no POC reference, so no evidence of active or automated exploitation. Realistically this is a legitimate multi-tenant isolation bug worth patching, but the actual risk is materially lower than a 9.3 - closer to a low/medium confidentiality leak - and the high score should be treated with skepticism pending vendor clarification.

An attacker obtains any project share link for a target Vikunja instance (e.g. a public or leaked link), then issues GET /api/v1/projects/{shareProject}/views/{view}/tasks while substituting {view} with view IDs belonging to other tenants' projects. Because the view is never re-authorized, the response returns those tenants' kanban bucket titles and creator user objects (username, name, id), and the 404-versus-non-404 behavior lets the attacker enumerate which project/view IDs exist. No public POC is referenced, but the attack requires only standard HTTP requests.