CVE-2026-91970

Executive Summary

CVE-2026-91970 is an uncontrolled resource consumption vulnerability (CWE-770) in the Planka migrator component of Vikunja, an open-source task and project management platform. In versions prior to 2.6.0, the migrator fails to enforce an aggregate memory budget across migration jobs, allowing an authenticated attacker to point a migration at an attacker-controlled server that advertises a large set of individually size-compliant attachments. The application downloads or processes these attachments until worker memory is exhausted, degrading or halting service for all users on the instance.

The vulnerability carries a CVSS:3.1 base score of 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), reflecting a network-reachable, low-complexity denial of service that requires only low privileges and no user interaction. EPSS is low (0.00368, ~30.4th percentile), and there is currently no public PoC, Nuclei template, or evidence of exploitation in the wild. Because the Planka migrator is a self-hosted feature requiring an authenticated account, real-world exploitation is most plausible against multi-tenant, internet-exposed Vikunja instances where low-privilege registration or compromised accounts are available.

Technical Analysis

Vikunja is a self-hosted, open-source to-do and project management application. The Planka migrator is one of several data-import integrations that allows operators to pull project data (boards, lists, cards, and their attachments) from an external Planka instance into Vikunja. Migration is normally an authenticated, operator-initiated action rather than an anonymous one.

The flaw class here is CWE-770: Allocation of Resources Without Limits or Throttling. Per the NVD description, the Planka migrator "fails to enforce aggregate memory budgets during migration jobs." This is the critical distinction: the per-attachment size check exists and is honored, but there is no ceiling on the cumulative memory consumed across the full set of attachments processed during a single migration job (or across concurrent jobs).

The attack mechanism therefore does not require a single oversized file. Instead, an attacker who controls the remote ("attacker-controlled") Planka server can advertise an arbitrary number of attachments, each crafted to be individually size-compliant (i.e., below whatever per-item limit the migrator enforces). When the migrator iterates over the advertised attachment list, it accumulates these objects in memory — for example by buffering download streams, holding decoded payloads, or queuing results for write — without an aggregate bound. Because no total-budget check interrupts the loop, memory usage grows monotonically with the count of advertised attachments until the worker exhausts available memory.

Downstream effects follow the standard uncontrolled-resource-consumption pattern:

• Worker process(es) handling the migration are killed by the OOM killer or panic.
• Depending on Vikunja's worker architecture, memory pressure and process restarts can cascade to shared services (API handlers, background job queue, database connection pool), producing denial of service for all users, not just the attacker.
• Instances with constrained memory (small VPS, containerized deployments with low limits) are most affected; a single migration job can be sufficient.

Attack surface / preconditions:

• Network reachability to the Vikunja instance (AV:N).
• A valid authenticated session (PR:L) — no admin role is specified as required by the description, only "authenticated attackers."
• Attacker control of a server the migrator will contact (the rogue Planka endpoint), which supplies the malicious attachment inventory.

Important accuracy note: The NVD description does not name specific functions, classes, endpoints, or configuration keys for the migrator. Consequently, this report deliberately avoids naming any implementation-level identifiers. Claims about exact per-attachment size limits, the precise data structure used to accumulate objects, or which worker pool is affected are not derivable from the available data and are therefore not asserted here. The vulnerability class and mechanism (aggregate-budget omission → OOM → DoS) are fully supported by the description.

The assigned CWE (CWE-770) and the CVSS subscore A:H (full availability impact) are consistent: integrity and confidentiality are unaffected (C:N/I:N), scope is unchanged (S:U), and the sole impact is availability loss.

Exploitation Scenarios

No public PoC or exploit code is available. The following chain is inferred from the vulnerability class (CWE-770) and the mechanism described in the NVD entry; it deliberately stays at the vulnerability-class level and does not invent implementation details.

1) Reconnaissance / target identification. The attacker identifies a Vikunja instance running a version prior to 2.6.0. This can be done passively (banner/version fingerprints, e.g., via Shodan dorks targeting Vikunja titles or HTML) or actively via the exposed web interface. The attacker then obtains an authenticated account — via self-registration if enabled, a compromised low-privilege credential, or an existing account in a multi-tenant deployment. No user interaction is required (UI:N), and privileges beyond "authenticated" are not specified as necessary (PR:L).

2) Triggering the specific flaw class. The attacker stands up or designates a server that speaks enough of the Planka import surface to be accepted as a migration source. On that server, the attacker advertises a large inventory of attachments, each deliberately kept under any per-item size threshold the migrator checks. The key is volume, not size — this defeats the per-attachment guard while exploiting the missing aggregate budget.

3) Payload / execution method (vulnerability-class level). The attacker submits a migration request from the Vikunja UI/API, supplying the address of the attacker-controlled source (PR:L, AV:N, AC:L). When the migration worker begins processing, it enumerates the advertised attachments and accumulates their contents in memory. Because no aggregate memory ceiling halts the loop, consumption grows with the number of advertised items until the worker hits the process or container memory limit. Depending on deployment isolation, this manifests as an OOM kill, a crash, or a prolonged stall. No code execution, injection, or credential theft is involved — the "payload" is simply the unbounded native resource demand.

4) Post-exploitation impact. Availability is degraded or lost for all users (A:H) as worker memory is exhausted and shared resources are starved or restarted. Recovery typically requires restarting the affected service and, for stateful-but-crashed workers, cleaning up in-flight jobs. There is no confidentiality or integrity impact (C:N/I:N), so this is a pure DoS primitive — attractive for disruption, extortion pressure, or as a smokescreen for other activity. Repeated submissions can sustain the outage. Because the trigger is an authenticated feature, forensic attribution depends on correlating the migration request with the attacker's account and the external source address.

Detection anchor: The most reliable signal is a migration job whose source address is external/untrusted and whose advertised attachment count is anomalously high, followed by worker memory growth and OOM events. See Detection Guidance.

Impact Assessment

• CVSS:3.1 = 6.5 (Medium). Vector: AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H.

  • AV:N — exploitable across the network against the web interface.
  • AC:L — no special conditions beyond an authenticated account and a reachable source.
  • PR:L — requires only low privileges (an authenticated user).
  • UI:N — no victim interaction needed.
  • S:U — impact stays within the vulnerable component's security scope.
  • C:N/I:N — no confidentiality or integrity effect.
  • A:H — total loss of availability; the metric driving the score.

• Blast radius. The description states the outcome is "denial of service for all users," so the impact is instance-wide, not confined to the attacker's tenant. Multi-user and multi-team deployments, and any instance whose worker memory is shared with request handling, face the largest blast radius. Single-user instances are affected but with lower business consequence.

• Business impact. Task/project management is a collaboration and operational hub for many teams; sustained unavailability can halt work coordination, block integrations, and prevent access to project history. For customer-facing or SaaS-hosted Vikunja, this translates to SLA breaches and reputational cost. Because exploitation is cheap (volume, not payload size), repeat and concurrent attempts are low-effort, and recovery (restart + job cleanup) can be repeated by the attacker while the account remains active.

• Likelihood / exploitation status. EPSS 0.00368 (~30.4th percentile) and no PoC, Nuclei template, or CISA KEV listing indicate low observed exploitation. The real risk is concentrated among internet-exposed instances that allow low-privilege registration or tolerate compromised accounts. The low EPSS should not drive complacency: the barrier to exploitation is simply an account plus an attacker-controlled source server.

• Patch confidence 2/4 (CLAIMED). OSV is the single source claiming the 2.6.0 fix. This should be validated against the vendor repository/release notes before treating the instance as remediated; absent independent confirmation, treat 2.6.0 as a reported fix and verify behavior in staging.

Detection Guidance

Detection should focus on the observable precursors and consequences of the flaw class: anomalous migration requests against external sources, spikes in attachment counts per migration, and worker memory/OOM events.

Sigma Rule

title: Vikunja Planka Migrator Resource Exhaustion (CVE-2026-91970)
id: 8f3c2a51-1e7a-4f0b-9b6d-6a2c9d0e7f21
status: experimental
description: Detects anomalous Vikunja Planka migration jobs that may exhaust worker memory (CWE-770 / CVE-2026-91970).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-91970
author: valtersit.com
date: 2026/01/01
logsource:
  product: vikunja
  service: application
detection:
  selection_migration:
    msg|contains:
      - 'migrator'
      - 'planka'
  selection_high_volume:
    attachment_count|gte: 500
  selection_oom:
    msg|contains:
      - 'out of memory'
      - 'OOMKilled'
      - 'runtime: out of memory'
  condition: (selection_migration and selection_high_volume) or selection_oom
falsepositives:
  - Legitimate large migrations from trusted internal Planka servers
level: medium
tags:
  - attack.impact
  - attack.t1499
  - cve.2026.91970

YARA Rule

rule CVE_2026_91970_Vikunja_Planka_Migrator_DoS
{
    meta:
        description = "Detects indicators of Vikunja Planka migrator resource exhaustion (CVE-2026-91970)"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-91970"
        date = "2026-01-01"
    strings:
        $planka_route  = "/api/v1/migration/planka" ascii wide nocase
        $migration     = "migration" ascii wide
        $attachment    = "attachment" ascii wide
        $oom_marker    = "out of memory" ascii wide nocase
    condition:
        (
            ($planka_route or ($migration and $attachment))
        )
        or $oom_marker
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-91970 Vikunja Planka Migrator Resource Exhaustion Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/migration"; nocase; http.uri; content:"planka"; nocase; http.request_body; content:"attachment"; nocase; classtype:attempted-dos; reference:cve,2026-91970; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-91970; metadata:service http; sid:202691970; rev:1;)

Elastic Detection

sequence by user.name with maxspan=10m
  [ process where event.action == "start" and process.name : "*vikunja*" and process.args : "*migration*" and process.args : "*planka*" ]
  [ process where event.category == "process" and event.action in ("end", "stop") and process.exit_code != 0 ]

Splunk SPL Query

index=vulnerabilities sourcetype=vikunja:app OR sourcetype=application
| search ("planka" AND "migration") OR ("out of memory" OR "OOMKilled")
| stats count min(_time) as first_seen max(_time) as last_seen
        by host, src_ip, user, msg
| where count >= 1
| sort - last_seen

Wazuh OSSEC Rule

<group name="vikunja,cve-2026-91970,">
  <rule id="202691970" level="10">
    <decoded_as>json</decoded_as>
    <field name="msg">\.*(planka|migration)\.*</field>
    <options>no_full_log</options>
    <description>CVE-2026-91970: Vikunja Planka migration job detected - possible resource exhaustion attempt.</description>
    <mitre>
      <id>T1499</id>
    </mitre>
  </rule>

  <rule id="202691971" level="12">
    <decoded_as>json</decoded_as>
    <field name="msg">\.*(out of memory|OOMKilled)\.*</field>
    <description>CVE-2026-91970: Vikunja worker out-of-memory event - possible active denial of service.</description>
    <mitre>
      <id>T1499</id>
    </mitre>
  </rule>
</group>

Note: these rules are heuristic and based on the vulnerability class. Field names such as msg, src_ip, and user are illustrative log-schema placeholders; analysts must map them to their actual Vikunja/collector schema before deployment.

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED — single source claims patch, not independently confirmed). The OSV entry indicates versions before 2.6.0 are affected and that a fix is claimed in 2.6.0. Because this is single-source and unverified, treat 2.6.0 as a reported remediation and validate it in a staging environment before relying on it.

1) Immediate mitigations (while validating the patch):

• Restrict network exposure of the Vikunja instance; place it behind authentication, a VPN, or an allowlist so unauthenticated/low-privilege actors cannot reach the migrator.
• Disable or restrict self-registration if it is not operationally required; audit and revoke stale low-privilege accounts.
• Apply container/process memory limits (cgroups, Kubernetes memory limits) so an OOM kills only the worker rather than destabilizing the host or shared services.
• Limit who can initiate migrations (role-based controls); require an approval or admin-only path if supported.
• Constrain what source hosts the migrator may contact (egress allowlisting / SSRF-style source restrictions) so it cannot reach arbitrary attacker-controlled servers.
• Monitor for and rate-limit repeated migration jobs; alert on the detection rules above.

2) Patch / upgrade steps:

• Confirm the claimed fix by reviewing the Vikunja repository release notes/changelog for 2.6.0 and any associated commit(s) referencing aggregate memory budgeting in the Planka migrator.
• Back up the database and configuration, then upgrade to Vikunja ≥ 2.6.0 following the project's documented upgrade procedure.
• After upgrade, re-test a controlled migration (including a high-attachment-count source) to confirm memory is now bounded and the worker no longer exhausts memory.
• If 2.6.0 cannot be independently verified as fixed, treat the instance as still vulnerable and keep the immediate mitigations in place.

3) Long-term hardening:

• Enforce aggregate resource budgets (total bytes, total items, wall-clock time) on all import/migration jobs, not just per-item limits — this is the root-cause class fix.
• Run migrations in isolated, memory-capped worker processes or separate queue workers with circuit breakers.
• Adopt defense-in-depth egress controls so import features cannot be pointed at arbitrary attacker-controlled servers (limit SSRF surface).
• Add continuous monitoring and alerting for OOM events and anomalous migration volume as standing detections.
• Track vendor advisories and confirm the CVE's fix provenance; upgrade promptly once the patch is independently validated.

References

• NVD — CVE-2026-91970: https://nvd.nist.gov/vuln/detail/CVE-2026-91970
• OSV — advisories referencing Vikunja Planka migrator resource exhaustion (single-source patch claim; search the OSV database for CVE-2026-91970): https://osv.dev/
• MITRE CWE-770 — Allocation of Resources Without Limits or Throttling: https://cwe.mitre.org/data/definitions/770.html
• MITRE ATT&CK T1499 — Endpoint Denial of Service: https://attack.mitre.org/techniques/T1499/
• Vikunja project repository and release notes (verify the 2.6.0 changelog and any commit addressing aggregate migration memory budgets): https://github.com/go-vikunja/vikunja

Threat actor / exploitation status: No known threat actor campaigns, public PoC, exploit code, or CISA KEV listing are associated with CVE-2026-91970 at the time of writing. EPSS 0.00368 (~30.4th percentile) indicates low predicted exploitation. The primary exposure is unpatched, internet-reachable Vikunja instances that permit low-privilege accounts.