CVE-2026-35595 go-vikunja CVE debrief

Who should care

Defenders responsible for Vikunja installations, operators of self-hosted task management platforms, vulnerability management teams, and security teams should assess exposure and verify their installations. They should review project permissions, monitor project changes, and ensure they are running version 2.3.0 or later to mitigate this vulnerability.

Why it matters

Defenders should care about this vulnerability as it allows users with inherited Write access to potentially escalate privileges by moving projects under their own project tree. This requires verification of Vikunja installation versions and review of project permissions.

• Potential privilege escalation for users with inherited Write access
• Changes to project permission inheritance chains
• Need for verification of Vikunja installation version

Technical summary

The CanUpdate check at pkg/models/project_permissions.go:139-148 only requires CanWrite on the new parent project when changing parent_project_id. However, Vikunja's permission model uses a recursive CTE that walks up the project hierarchy to compute permissions. Moving a project under a different parent changes the permission inheritance chain. When a user has inherited Write access (from a parent project share) and reparents the child project under their own project tree, the CTE resolves their ownership of the new parent as Admin (permission level 2) on the moved project.

Defensive priority

Defenders should prioritize verifying their Vikunja installations and ensuring they are running version 2.3.0 or later to mitigate this vulnerability.

Recommended defensive actions

• Verify Vikunja installation version and upgrade to 2.3.0 or later if necessary
• Review project permissions and inheritance chains
• Monitor project changes and user access
• Confirm whether affected product deployments exist in managed environments and assign an owner for follow-up
• Review the supplied official advisory or CVE record to validate affected scope, severity, and vendor guidance
• Plan vendor-supported updates or mitigations through normal change control where exposure is confirmed
• Check relevant monitoring, detection, and logs for exposed assets that need extra review

Evidence notes

The vulnerability is described in the CVE record and the NVD vulnerability detail page. The fix is available in version 2.3.0 of Vikunja. Defenders should verify Vikunja installation versions and review project permissions. Evidence is limited to public CVE details and NVD analysis. Further verification tasks are required to assess exposure.

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.