CVE-2026-91981 go-vikunja CVE debrief

Who should care

Defenders responsible for Vikunja deployments, especially those with publicly accessible v2 API endpoints, should assess exposure and prioritize verification and remediation. This includes IT teams managing Vikunja installations, security teams monitoring for potential threats, and operators relying on Vikunja for project management. Ensuring version 2.6.0 or later is installed is crucial, along with restricting access to v2 API endpoints and monitoring

Why it matters

The CVE-2026-91981 vulnerability in Vikunja versions before 2.6.0 allows for user enumeration and arbitrary username confirmation via the v2 API. Defenders should prioritize verifying their Vikunja version, assessing exposure, and restricting access to v2 API endpoints.

• User enumeration via projects endpoint
• Confirmation of arbitrary usernames via global search endpoint
• Potential for targeted attacks using enumerated usernames
• Verification of Vikunja version and exposure

Technical summary

The vulnerability in Vikunja versions before 2.6.0 is due to improper validation of link-share tokens in the v2 API user search endpoints. This allows attackers with a read-only share link to enumerate project users and confirm arbitrary usernames exist. The vulnerability is specific to the v2 API and does not affect other API versions. Defenders should prioritize verifying their Vikunja version and assessing exposure, especially for systems with publicly accessible v2 API endpoints. Technical details are limited to publicly available sources and may not be exhaustive.

Defensive priority

Defenders should prioritize verifying their Vikunja version and assessing exposure, especially for systems with publicly accessible v2 API endpoints.

Recommended defensive actions

• Verify Vikunja version and assess exposure
• Restrict access to v2 API endpoints
• Monitor for suspicious activity
• Review compensating controls for exposed systems
• Check relevant monitoring, detection, and logs for exposed assets
• Track exceptions and retest remediated assets
• Plan vendor-supported updates or mitigations through normal change control

Evidence notes

The CVE record and NVD entry provide details on the vulnerability in Vikunja versions before 2.6.0. The vulnerability allows for user enumeration and confirmation of arbitrary usernames via the v2 API. Evidence is limited to public sources and may not be comprehensive. Defenders should verify their Vikunja version, assess exposure, and monitor for suspicious activity.

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.