vulnerability / NVI-00012108 / Revision 2
Vikunja: Planka migration retains an unbounded aggregate of attacker-served attachments and can OOM the API
GitHub lists this reviewed advisory for code.vikunja.io/api. Published version ranges and source prerequisites are shown below; this is not an inspection of a visitor’s application.
This report has not inspected your inventory, configuration, deployed build, reachability or evidence. A catalog listing and a severity score do not establish exposure or compromise.
01 / Meaning
Why it matters
Published affected context helps an owner decide what evidence to gather. This report has not examined your application.
6.5 MEDIUM (3.1)
disclosure@vulncheck.com severity; no combined Null risk score.
7.1 HIGH (4.0)
disclosure@vulncheck.com severity; no combined Null risk score.
02 / Applicability
The affected context
Affected versions, configuration prerequisites and known exclusions are public. Confirm each one against the deployed service.
code.vikunja.io/api
source listed>= 2.5.0, < 2.6.0
# Planka migration retains an unbounded aggregate of attacker-served attachments and can OOM the API ## Summary 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. ## Impact and affected scope - **Type:** Resource Exhaustion Dos - **Affected component:** POST /api/v2/migration/planka/migrate; Asynchronous migration.requested worker for the Planka migrator - **Preconditions:** A low-privilege Vikunja user supplies an attacker-operated public Planka URL and token. That server controls project/board/card/attachment counts and streams each attachment body at or below Vikunja's normal per-file limit. - **Verified revision:** `d66ef3d1a39c6f7289593059a1a34afd1d05926
03 / Response
What to do next
- investigate
Identify the exact component and deployed version, examine the linked publisher’s conditions, and retain evidence of any mitigation.
Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system. NIST National Vulnerability Database
A fixed release is not deployment evidence.
Check current vendor support and compatibility. After making a change, verify the deployed build and relevant runtime conditions. Keep the evidence, owner and time. An updated lockfile alone does not prove what is running.
04 / Limits
What this report cannot establish
- Customer inventory, deployment, reachability and exploitation have not been inspected.
- NVD lastModified does not establish freshness of every associated CPE record.
05 / Provenance
Sources you can inspect
Each assertion retains its source. Mirrored records may repeat one underlying publisher; additional links are not independent corroboration.
- GHSA-wq92-8x3r-fm38 ↗
GitHub Advisory Database · vendor advisory
Observed . GitHub Advisory Database; CC-BY-4.0. Each advisory links its original attribution. Null normalizes fields.
- CVE-2026-91970 ↗
NIST National Vulnerability Database · official catalog
Observed . This product uses data from the NVD API but is not endorsed or certified by the NVD.
Public revision history
Only published revisions appear here. Routine fetches do not create a material-change event.
- Revision 2 ·
Source facts changed; compare the preserved prior revision.
- Revision 1 ·
First indexed by Null; source disclosure date is shown separately.