CVE-2026-91970: Vikunja: Planka migration retains an unbounded aggregate of attacker-served attachments and can OOM the API
The always-registered Planka migration lets any ordinary user select a Planka server. Although Vikunja caps each JSON response, pagination loop, and attachment independently, it has no aggregate job budget. The conversion stage downloads every advertised non-link attachment and keeps every byte slice live until the complete hierarchy is inserted. A public attacker server can therefore drive memory beyond any finite service allocation. The final Docker run preserved default SSRF policy and OOM-killed the healthy API after five individually valid 20 MiB attachment responses.
References
- github.com/advisories/GHSA-wq92-8x3r-fm38
- github.com/go-vikunja/vikunja/pull/3688
- github.com/go-vikunja/vikunja/releases/tag/v2.6.0
- github.com/go-vikunja/vikunja/security/advisories/GHSA-wq92-8x3r-fm38
- nvd.nist.gov/vuln/detail/CVE-2026-91970
- www.vulncheck.com/advisories/vikunja-before-2.6.0-resource-exhaustion-via-planka-migration
Code Behaviors & Features
Detect and mitigate CVE-2026-91970 with GitLab Dependency Scanning
Secure your software supply chain by verifying that all open source dependencies used in your projects contain no disclosed vulnerabilities. Dependency Scanning using SBOM also detects vulnerabilities from proprietary advisories that this site does not include. Learn more about Dependency Scanning using SBOM →