CVE-2026-91984

Executive Summary

CVE-2026-91984 is an authorization flaw (CWE-639, Authorization Bypass Through User-Controlled Key) in the Vikunja task management platform prior to version 2.6.0. An authenticated attacker can supply a project_view_id in task-position POST/PUT requests that does not belong to the task's actual project, allowing the insertion of task position rows into arbitrary project views owned by other tenants. Because the flaw allows cross-tenant write access to positional metadata, it undermines project integrity and tenant isolation, though the CVSS impact is limited (4.3) due to the absence of direct confidentiality or availability impact.

Technical Analysis

Vikunja is an open-source, self-hostable task and project management application. Like most multi-tenant collaboration platforms, it organizes tasks within projects, and projects are presented through one or more "views" identified by a project_view_id. Task positions (ordering/ranking rows) are persisted per view so that UI sorting remains consistent for each user context.

The vulnerability, per the NVD description, is a missing server-side authorization check: when a client issues a POST or PUT request to a task-position endpoint and includes a user-controlled project_view_id, the application fails to verify that this view belongs to the same project as the task being repositioned. This is a textbook instance of CWE-639, "Authorization Bypass Through User-Controlled Key" (also commonly called IDOR — Insecure Direct Object Reference). The trust boundary being violated is the project/tenant boundary: the attacker controls a key (project_view_id) that references an object (a view) outside their authorization scope, and the server performs the write without cross-checking ownership.

Because the CVSS vector is AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, we can infer the following from the published metrics:

• AV:N — the vulnerable endpoint is reachable over the network (HTTP API), not limited to local access.
• PR:L — exploitation requires an authenticated account (any low-privilege user), not administrator rights.
• UI:N — no victim interaction is required.
• S:U — the impact is scoped to the vulnerable component (the metrics do not assert cross-security-authority scope).
• I:L — the primary demonstrated impact is a limited integrity violation: unauthorized insertion of task position rows.
• C:N / A:N — no direct data disclosure or denial-of-service is asserted by the CVSS vector.

Importantly, the description states the attacker can insert position rows "into arbitrary other tenant project views." This confirms a multi-tenant isolation failure, but it does not describe code disclosure, remote code execution, privilege escalation, or authentication bypass. The exploitation surface is limited to the task-position write path and the project_view_id parameter referenced verbatim in the NVD description.

No public exploit code, Nuclei template, or PoC is currently available, so the precise request body structure, endpoint path, and parameter encoding are not confirmed by public sources and are not asserted here. The mechanism should be understood at the vulnerability-class level: an object-reference key that is attacker-controlled and insufficiently validated against the object it is being written to.

Exploitation Scenarios

No public PoC is available; the following attack chain is inferred strictly from the vulnerability class (CWE-639) and the NVD description, and deliberately avoids inventing endpoints, parameters, or code identifiers beyond those named (project_view_id, task-position POST/PUT endpoints).

1. Reconnaissance / target identification. The attacker identifies a reachable Vikunja instance (self-hosted or cloud) running a version prior to 2.6.0. Because Vikunja exposes a REST API, the attacker enumerates the API surface to locate the task-position POST and PUT endpoints. Version fingerprinting drives targeting.

2. Authentication and baseline access. The attacker registers or obtains a low-privileged authenticated account (PR:L). The attacker needs at least one legitimate project/task of their own to observe the request shape used for task-position updates and to learn the format of project_view_id values. This is a normal authenticated user, so no special privileges are needed.

3. Triggering the flaw. Using their authenticated session, the attacker sends a POST or PUT task-position request for one of their tasks but substitutes the project_view_id value with the identifier of a view belonging to a different project or tenant. Because the server does not validate that the supplied project_view_id belongs to the task's project, the write is accepted.

4. Payload / execution. At the vulnerability-class level, the payload is simply a crafted API request carrying a foreign project_view_id. There is no memory corruption or code injection: the "exploit" is the use of a valid but unauthorized object reference. The server inserts task position rows into the target view.

5. Post-exploitation impact. The attacker achieves a cross-tenant integrity violation — the target project's view is polluted with attacker-supplied position rows. Depending on how the application renders or validates positions, this can corrupt task ordering, inject unexpected entries into another tenant's view, or otherwise tamper with data the attacker is not authorized to modify. Per the CVSS vector there is no direct confidentiality or availability impact; the observable effect is unauthorized modification (I:L). Cascading effects (e.g., data integrity trust issues or downstream workflow disruption) are plausible but not asserted by the data provided.

Impact Assessment

The CVSS 3.1 base score is 4.3 (Medium), vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N. Subscore interpretation:

• Attack Vector (Network) and Low Complexity make the bug easy to reach and repeat, but only for an authenticated actor.
• Low Privileges Required means essentially any registered user can attempt it — attractive for insider abuse or for users in shared multi-tenant deployments.
• No User Interaction removes the need to trick a victim.
• Scope Unchanged, Confidentiality None, Availability None cap the severity: this is an integrity-only flaw with limited demonstrated effect.

Business impact: For SaaS or shared-instance deployments, the tenant isolation break is the most serious consequence — customers expect that a user in tenant A cannot write into tenant B's project data. Even though the write is limited to position rows, such tampering can erode trust, produce misleading project views, and potentially interfere with ordering-dependent workflows. The EPSS score (0.00208, ~11.1th percentile) indicates a low probability of exploitation in the wild at this time, and CISA KEV does not list the CVE. There is no evidence of active threat-actor campaigns. Blast radius: any authenticated user of an affected instance, with cross-tenant reach; affected systems are Vikunja deployments below 2.6.0.

Detection Guidance

Sigma Rule

title: Vikunja Cross-Tenant Task Position Tampering (CVE-2026-91984)
id: 6f2b1a4e-7c3d-4e9a-9b21-1d2c3e4f5a60
status: experimental
description: Detects POST/PUT requests to Vikunja task-position endpoints carrying a project_view_id, consistent with CWE-639 authorization bypass attempts (CVE-2026-91984).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-91984
author: valtersit.com
date: 2026/01/01
logsource:
  category: webserver
  product: vikunja
detection:
  selection_method:
    cs-method:
      - 'POST'
      - 'PUT'
  selection_uri:
    cs-uri-stem|contains:
      - '/task'
      - '/position'
  selection_param:
    cs-uri-query|contains: 'project_view_id'
  condition: selection_method and selection_uri and selection_param
fields:
  - c-ip
  - cs-method
  - cs-uri-stem
  - cs-uri-query
  - cs-username
falsepositives:
  - Legitimate task reordering by the owning user
level: medium
tags:
  - attack.t1190
  - cve.2026.91984

YARA Rule

rule CVE_2026_91984_Vikunja_ProjectViewID_Bypass
{
    meta:
        description = "Detects Vikunja task-position API requests abusing user-controlled project_view_id (CVE-2026-91984 / CWE-639)"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-91984"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $ep1 = "/task" ascii wide nocase
        $ep2 = "/position" ascii wide nocase
        $param = "project_view_id" ascii wide nocase
        $m1 = "POST" ascii
        $m2 = "PUT" ascii

    condition:
        ($ep1 or $ep2) and $param and ($m1 or $m2)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-91984 Vikunja task-position project_view_id authorization bypass attempt"; flow:established,to_server; http.method; content:"POST"; http.method; content:"PUT"; http.uri; content:"position"; http.uri; content:"project_view_id"; classtype:attempted-user; reference:cve,2026-91984; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-91984; sid:202691984; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=5m
  [http where http.request.method in ("POST", "PUT")
     and url.path : "*position*"
     and url.query : "*project_view_id*"]

Splunk SPL Query

index=web sourcetype=access_combined OR sourcetype=nginx:access
| search (method=POST OR method=PUT)
| search uri_path="*position*" OR uri_query="*project_view_id*"
| stats count min(_time) as first_seen max(_time) as last_seen values(uri_path) as paths values(uri_query) as queries by src_ip, user
| where count > 5
| sort - count

Wazuh OSSEC Rule

<group name="web,vikunja,cve-2026-91984,">
  <rule id="2026919" level="8">
    <if_sid>31100</if_sid>
    <id>^CVE-2026-91984</id>
    <description>CVE-2026-91984 - Vikunja task-position request carrying project_view_id (potential cross-tenant authorization bypass / CWE-639).</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>access_control,pci_dss_6.5.8,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED — single source claims patch, not independently confirmed). OSV indicates the issue is fixed in Vikunja 2.6.0, but this has not been independently verified and no vendor advisory or commit reference is provided in the intelligence data. Treat this guidance as provisional.

1) Immediate mitigations

• Restrict network exposure of the Vikunja API to trusted networks or place it behind an authenticating reverse proxy; the flaw requires an authenticated account (PR:L), so reducing the pool of accounts limits exposure.
• Review application logs for anomalous task-position POST/PUT requests that reference project_view_id values outside the requester's own projects.
• If multi-tenant isolation is critical and an independent fix cannot be verified, consider temporarily limiting the task-position write capability for untrusted users until a patched build is validated.
• Audit existing task positions in sensitive projects for unexpected or foreign entries.

2) Patch / upgrade steps

• Upgrade Vikunja to 2.6.0 or later if the single-source patch claim is verified in your environment. Because patch confidence is only 2/4, validate the fix: confirm that a task-position request using a project_view_id belonging to a different project is rejected with an authorization error.
• Track the official Vikunja release notes / repository for an explicit fixed version declaration before treating deployments as remediated.
• Back up task-position data before upgrading so any corruption or unauthorized inserts can be identified and rolled back.

3) Long-term hardening

• Enforce server-side authorization on every object reference: never trust client-supplied identifiers such as project_view_id. Resolve ownership by joining the supplied view to the task's owning project and reject mismatches (the correct implementation of CWE-639 remediation).
• Adopt an object-level access-control pattern (e.g., a centralized "can this user write to this object" policy) applied uniformly across all API endpoints.
• Add automated authorization regression tests that attempt cross-tenant object references for every write endpoint.
• Instrument and alert on cross-tenant object-reference attempts as a detection control, independent of the patch.

References

1. NVD — CVE-2026-91984: https://nvd.nist.gov/vuln/detail/CVE-2026-91984
2. CWE-639 — Authorization Bypass Through User-Controlled Key: https://cwe.mitre.org/data/definitions/639.html
3. OSV — advisory referencing Vikunja fix in 2.6.0 (cited patch source; unverified)
4. Vikunja project repository and release notes (verify the fixed version directly): https://github.com/go-vikunja/vikunja
5. MITRE ATT&CK — T1190 Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/

Threat actor / exploit-in-the-wild evidence: None. CISA KEV does not list CVE-2026-91984, EPSS is 0.00208 (~11.1th percentile), and no public PoC, Nuclei template, or exploit code was identified at time of writing.