CVE-2026-55066

Executive Summary

CVE-2026-55066 is an authorization bypass vulnerability in Vikunja, an open-source self-hosted task management platform, affecting all versions prior to 2.4.0. The flaw resides in the bucket/task update workflow where the API endpoint accepts a user-supplied task_id parameter while authorization checks only validate the project, view, and bucket identifiers from the URL path — leaving task-level access control unaudited. This enables an authenticated attacker with low-privilege credentials to enumerate global sequential task identifiers and read task contents across tenants, as well as modify completion metadata on victim tasks. The vulnerability carries a CVSS score of 7.1 (High), driven primarily by confidentiality impact (High) and low attack complexity, with no public exploit currently available.

Technical Analysis

The vulnerability class is CWE-639: Authorization Bypass Through User-Controlled Key. This flaw arises when an application relies on user-supplied identifiers for resource access without verifying that the authenticated principal has sufficient permissions to interact with the identified resource.

In this specific case, the affected endpoint is POST /api/v1/projects/{project}/views/{view}/buckets/{bucket}/tasks. The URL structure includes three path parameters — project ID, view ID, and bucket ID. The authorization function TaskBucket.CanUpdate (located in pkg/models/kanban_task_bucket.go) validates that the authenticated user has rights to the project, view, and bucket referenced in the path. However, the request body also supplies a task_id parameter, and crucially, this task identifier is not subjected to a separate permission check.

The subsequent call chain is as follows:

1. updateTaskBucket is invoked with the URL parameters and the body-supplied task_id.
2. The function calls Task.ReadOne to retrieve the task record.
3. Because no task-scoped permission validation is performed at this point, the attacker receives the full contents of the victim's task.
4. If the attacker selects a "done" bucket in the request, the task's completion state is modified.

The root cause is a missing object-level authorization check. The application validates authorization at the container level (project/view/bucket) but fails to validate at the object level (the specific task being moved or read). This is a classic IDOR (Insecure Direct Object Reference) pattern where a user-controlled key — in this case, task_id — is trusted without proper ownership/ACL verification.

Two additional aggravating factors compound this issue:

Global sequential task identifiers: Vikunja assigns task IDs using a global auto-incrementing sequence. This means task IDs are predictable and low — ID 1, ID 2, ID 3, and so on. An attacker can trivially enumerate tasks by iterating through sequential integer values, discovering tasks belonging to other tenants/users without any brute-force or guessing effort.

Multiple vulnerable routes: The description notes that both v1 and v2 API routes share the same underlying model and authorization logic, meaning both API versions are exposed to the same flaw. This expands the attack surface and makes remediation more complex, as both route handlers must be patched.

Attack surface assessment: The vulnerability requires authentication — an attacker must have a valid low-privileged account on the affected Vikunja instance. This eliminates unauthenticated remote attackers but still leaves the system exposed to any user with even the most minimal permissions (e.g., a self-registered account on multi-tenant deployments). The network attack vector (AV:N) means the vulnerable endpoint is reachable over the network, and the low attack complexity (AC:L) indicates that no special conditions or race conditions are needed to exploit the flaw. No user interaction is required (UI:N), and the scope is unchanged (S:U) — meaning the compromise is contained to the vulnerable system's security authority.

The CVSS breakdown (7.1) is as follows: High confidentiality impact (C:H) because task contents (potentially sensitive project details, notes, attachments metadata) are disclosed; Low integrity impact (I:L) because only the completion/done state can be modified — not arbitrary task content; No availability impact (A:N).

Exploitation Scenarios

No public proof-of-concept exists as of the intelligence report date; however, the attack chain can be inferred with high confidence from the vulnerability class and the detailed description. The following exploitation scenario is constructed strictly from the mechanism described in the NVD data:

Step 1 — Reconnaissance & Target Identification

The attacker first identifies a target Vikunja instance. Because Vikunja is self-hosted, the attacker would either scan the internet for exposed instances (e.g., using the Shodan dorks listed in the METADATA section) or target a known organization's deployment. The attacker registers or obtains a low-privileged account on the target. On multi-tenant deployments (where multiple organizations use a single Vikunja instance), any tenant user can become a potential attacker.

Step 2 — Triggering the Authorization Bypass

With an authenticated session, the attacker crafts HTTP requests to the vulnerable endpoint. The attack leverages the mismatch between URL-based authorization (project/view/bucket — checked) and body-based task reference (unchecked). The attacker:

1. Creates or uses an existing bucket in their own accessible project/view context.
2. Sends a POST request to /api/v1/projects/{attacker_project}/views/{attacker_view}/buckets/{attacker_bucket}/tasks with a JSON body containing a task_id value that belongs to another user.
3. Since Task.ReadOne is called without a task-scoped ACL check, the server returns the full task record.

Step 3 — Task Enumeration and Exfiltration

Because task IDs are global sequential integers, the attacker iterates through numeric values: task_id=1, task_id=2, task_id=3, and so forth. Each request returns the victim task's full contents, including title, description, comments, assignees, labels, due dates, and any other metadata stored in the task record. This constitutes a high-impact confidentiality breach — the attacker can systematically harvest all tasks across every tenant on the instance.

Step 4 — Post-Exploitation Integrity Manipulation

Beyond data theft, the attacker can modify the completion state of victim tasks. By specifying a "done" bucket in the request body, the updateTaskBucket function updates the task's done status. This allows the attacker to:

• Mark victim tasks as completed, corrupting project status tracking.
• Mark completed tasks back to not-done, causing confusion and re-work.
• Potentially disrupt project workflows and milestones if task completion state feeds into higher-level project automation or reporting.

For an enterprise using Vikunja for project management, this could result in corrupted sprint data, inaccurate burndown charts, and loss of trust in the system's data integrity.

Constraints and Limitations: The attacker cannot modify arbitrary task content (only done state) and cannot delete tasks. Privilege escalation beyond data disclosure and completion-state tampering is not demonstrated by the vulnerability description.

Proof of Concept Intelligence

As of the publication date, no public proof-of-concept has been released for CVE-2026-55066. There is no known exploit code on public repositories, and no Nuclei template has been published. The EPSS score has not yet been assigned by FIRST.org.

However, exploitation remains highly likely for three reasons:

1. Mechanism clarity: The vulnerability class (CWE-639 / IDOR) is well-documented and trivial to exploit once understood. The NVD description supplies sufficient detail about the flaw (endpoint path, function names, missing authorization check) that a competent security researcher could develop a working exploit within hours.

2. Predictable identifiers: Global sequential task IDs eliminate the need for any brute-force enumeration strategy beyond simple integer iteration. This dramatically lowers the exploit development barrier.

3. Authenticated requirement only: The only gate is a valid account, which on many self-hosted deployments can be self-registered. The barrier to entry is low.

Resources defenders should monitor:

• The Vikunja GitHub repository (@vikunja/vikunja) for issues and pull requests referencing CVE-2026-55066 or related authorization fixes.
• Public exploit databases: Exploit-DB, Metasploit Framework modules, and GitHub code search for "CVE-2026-55066".
• Security researcher blogs and Twitter/X posts from researchers covering IDOR vulnerabilities in self-hosted tools.
• Nuclei template repositories (projectdiscovery/nuclei-templates) for a possible future template.
• The vendor's security advisory page and CHANGELOG for release 2.4.0 plus any subsequent security advisories.

Impact Assessment

Confidentiality Impact (High): The primary impact is unauthorized disclosure of task contents. Task management platforms in enterprise environments frequently contain sensitive project information, customer data, internal discussions, and personally identifiable information. The ability to enumerate and read all tasks across tenants represents a severe data breach scenario, especially on shared/multi-tenant deployments. The CVSS confidentiality sub-score is the primary driver of the overall 7.1 severity rating.

Integrity Impact (Low): The attacker can only modify the task completion/done state. While this alone may not cause catastrophic data corruption, in environments where task completion state triggers automated workflows (e.g., CI/CD pipelines, notification systems, reporting), this could cause cascading operational disruption.

Availability Impact (None): The vulnerability does not allow for denial-of-service or data destruction.

Affected Systems: All Vikunja deployments running versions prior to 2.4.0. This includes:

• Single-tenant installations where multiple users share a workspace — any user can read any other user's tasks.
• Multi-tenant installations where one instance serves multiple organizations — cross-tenant data exposure.
• Both v1 and v2 API consumers are affected since they share the same vulnerable model logic.

Blast Radius: The blast radius is proportionate to the number of tasks stored on the instance. On a busy Vikunja deployment, this could expose thousands or tens-of-thousands of tasks. The confidentiality breach alone may trigger regulatory notification obligations (GDPR, CCPA, HIPAA) if personal data is involved.

Business Impact:

• Loss of confidential project data (bids, strategies, client communications).
• Regulatory fines and legal liability from data breach notification.
• Reputational damage and loss of customer trust.
• Operational disruption from tampered task states.
• Supply-chain risk if Vikunja is used to manage software development projects containing proprietary code references or security-relevant information.

Detection Guidance

This section provides detection rules for network and host-based monitoring to identify exploitation attempts against CVE-2026-55066. Given that the vulnerability requires authenticated access and is a logic flaw (not a signature-based attack), the detection strategy focuses on behavioral anomalies: unusual task ID patterns, abnormal API usage, and cross-tenant access attempts.

Sigma Rule

title: Vikunja Task IDOR - Cross-Tenant Task Access via Bucket Move Endpoint
id: 6c5f9a2e-8b8d-4f7a-9e2b-3c1d4e5f6a7b
status: experimental
description: Detects potential IDOR exploitation against Vikunja's task bucket move endpoint, characterized by rapid sequential task ID requests from a single authenticated user.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-55066
author: Valtersit Threat Intelligence
date: 2026/02/15
tags:
    - attack.t1190
    - cve.2026.55066
    - cwe.639
logsource:
    category: webserver
    product: vikunja
detection:
    selection_auth:
        cs-method: POST
        cs-uri-query|contains: /api/v1/projects/
    selection_path:
        cs-uri-query|contains|all:
            - /buckets/
            - /tasks
    selection_taskid:
        cs-uri-query|re: 'task_id=\d+'
    filter_baseline:
        cs-uri-query|re: 'task_id=(\d{1,4})'  # baseline: low sequential IDs are suspicious
    condition: selection_auth and selection_path and selection_taskid and not filter_baseline
    timeframe: 5m
level: high
falsepositives:
    - Legitimate batch operations moving many tasks in bulk
    - Automated workflow integration that legitimately moves tasks across buckets
fields:
    - clientip
    - user
    - cs-uri-query

YARA Rule

rule Vikunja_CVE_2026_55066_IDOR_HTTP_Traffic
{
    meta:
        author = "Valtersit Threat Intelligence"
        description = "Detect HTTP request patterns consistent with CVE-2026-55066 IDOR exploitation against Vikunja"
        cve = "CVE-2026-55066"
        cwe = "639"
        severity = "high"
        date = "2026-02-15"
    strings:
        $endpoint_v1 = "/api/v1/projects/" ascii wide nocase
        $endpoint_v2 = "/api/v2/projects/" ascii wide nocase
        $bucket_task = "/buckets/" ascii wide nocase
        $task_suffix = "/tasks" ascii wide nocase
        $body_task_id = "task_id" ascii wide nocase
        $json_content = "content-type: application/json" ascii wide nocase
    condition:
        filesize < 10KB and
        (
            ($endpoint_v1 or $endpoint_v2) and
            $bucket_task and
            $task_suffix and
            $body_task_id and
            $json_content
        )
}

Suricata IDS Rule

alert http any any -> any any (
    msg:"ET EXPLOIT Vikunja CVE-2026-55066 IDOR Task Bucket Move Attempt";
    flow:established,to_server;
    http.method; content:"POST"; http.client_body;
    content:"task_id"; http.client_body; nocase;
    http.uri; content:"/api/v1/projects/";
    http.uri; content:"/buckets/";
    http.uri; content:"/tasks";
    http.uri; content:"/views/";
    pcre:"/task_id\\s*[=:]\\s*\\d+/Ui";
    classtype:attempted-user;
    reference:cve,2026-55066;
    reference:url,nvd.nist.gov/vuln/detail/CVE-2026-55066;
    sid:5506601;
    rev:1;
    metadata:created_at 2026-02-15, updated_at 2026-02-15;
)

Elastic Detection

// Detect rapid successive POST requests to Vikunja task endpoint with sequential task IDs
sequence by source.ip with maxspan=5m
    [http where request.method == "POST" and request.uri like "/api/v1/projects/*" 
     and request.uri like "*/buckets/*" and request.uri like "*/tasks" 
     and request.body contains "task_id"]
    [http where request.method == "POST" and request.uri like "/api/v1/projects/*" 
     and request.uri like "*/buckets/*" and request.uri like "*/tasks" 
     and request.body contains "task_id"]
    [http where request.method == "POST" and request.uri like "/api/v1/projects/*" 
     and request.uri like "*/buckets/*" and request.uri like "*/tasks" 
     and request.body contains "task_id"]
    [http where request.method == "POST" and request.uri like "/api/v1/projects/*" 
     and request.uri like "*/buckets/*" and request.uri like "*/tasks" 
     and request.body contains "task_id"]
    [http where request.method == "POST" and request.uri like "/api/v1/projects/*" 
     and request.uri like "*/buckets/*" and request.uri like "*/tasks" 
     and request.body contains "task_id"]
| stats count = count(*) by source.ip
| where count >= 5
| filter (source.ip not in ["bazel.inbound_allowlist"] )

Splunk SPL Query

index=web sourcetype=access_combined 
| where like(uri_path, "/api/v%1/projects/%")
| where like(uri_path, "%/buckets/%")
| where like(uri_path, "%/tasks")
| where method="POST"
| rex field=_raw "task_id[^0-9]*?(?<taskid>\d+)"
| table _time clientip user taskid uri_path
| eventstats count BY clientip _time span=5m
| eval taskid_num = tonumber(taskid)
| sort taskid_num
| streamstats current=true last(taskid_num) as prev_taskid BY clientip
| eval diff = taskid_num - prev_taskid
| where diff <= 2 AND diff >= 0
| stats count AS sequential_requests BY clientip
| where sequential_requests > 10
| eval severity="high", alert="Possible CVE-2026-55066 IDOR exploitation"
| table _time clientip sequential_requests severity alert

Wazuh OSSEC Rule

<group name="web,accesslog,idor,">
    <rule id="550660" level="12">
        <decoded_as>web-access</decoded_as>
        <field name="method">POST</field>
        <field name="url">\./api/v1/projects/</field>
        <field name="url">\./buckets/</field>
        <field name="url">\./tasks</field>
        <match>task_id</match>
        <description>Vikunja CVE-2026-55066 - potential IDOR task access via bucket move</description>
        <group>cve-2026-55066,idOR,web_attack,</group>
        <mitre>
            <id>T1190</id>
        </mitre>
    </rule>

    <rule id="550661" level="15" frequency="10" timeframe="300">
        <if_matched_sid>550660</if_matched_sid>
        <same_source_ip />
        <description>Vikunja CVE-2026-55066 - repeated IDOR exploitation attempts from same source</description>
        <group>cve-2026-55066,idOR,web_attack,</group>
    </rule>
</group>

Mitigation & Patch Guidance

Patch Status: UNPATCHED (0/4 patch confidence). No tracked source confirms a verified patch release. The NVD description states the fix is included in version 2.4.0; however, because this version has not been independently verified by a patch-confidence source, treat this with caution and verify the vendor's official release.

1) Immediate Mitigations (before patching)

• Restrict network access: If Vikunja is only needed internally, ensure the web interface is not exposed to the public internet. Use a VPN or IP allowlist to restrict access to trusted networks.
• Disable self-registration: If Vikunja allows open user registration, disable it immediately. This prevents untrusted individuals from obtaining authenticated accounts required for exploitation.
• Audit existing users: Review all user accounts and remove inactive or unverified accounts. Focus on low-privilege accounts that are not actively used.
• Monitor API logs: Enable detailed API request logging and implement the detection rules above to identify potential exploitation in progress.
• Least-privilege enforcement: Ensure users with access to Vikunja only have the minimum roles required for their job function. Limit bucket-creating permissions to trusted administrators.

2) Patch/Upgrade Steps

• Verify the vendor's official release of version 2.4.0 from the Vikunja GitHub releases page (https://github.com/go-vikunja/vikunja/releases).
• Before upgrading, review the release notes and CHANGELOG for any breaking changes affecting your deployment.
• Backup the application database and configuration files before applying the upgrade.
• Deploy version 2.4.0 to a staging environment first and validate core functionality.
• Roll out to production during a maintenance window.
• After deployment, verify the fix by attempting to move a task from another user via the vulnerable pattern — it should be rejected with a permission error.
• If upgrading is not immediately possible, apply vendor-supplied hotfixes or backport patches if available.

3) Long-Term Hardening

• Enable mandatory per-task permissions: After upgrading, configure Vikunja's permission model to enforce object-level ACLs — this should be the default in 2.4.0 — and verify it in your configuration.
• Regular security reviews: Schedule periodic review of user accounts, roles, and permission assignments. Remove unnecessary privileges.
• Web Application Firewall (WAF): Deploy a WAF in front of Vikunja to add an additional layer of detection and blocking for IDOR-style attacks.
• Rate limiting: Implement API rate limiting to slow down enumeration attempts. Cap the number of API requests per user per minute.
• Network segmentation: Place Vikunja in a separate network segment from core business systems to limit lateral movement if compromised.
• Monitor CVE sources: Subscribe to the vendor's security announcements and monitor for any follow-up vulnerabilities or incomplete-fix advisories.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-55066
2. Vendor Repository: https://github.com/go-vikunja/vikunja (official source; release 2.4.0 contains the fix)
3. CWE-639 Reference: https://cwe.mitre.org/data/definitions/639.html (Authorization Bypass Through User-Controlled Key)
4. CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CVE-2026-55066 is NOT currently listed — no known exploitation in the wild)
5. Vikunja Security Advisories: https://vikunja.io/docs/security/ (vendor's security advisory page — monitor for official advisory publication)

Threat Actor Campaigns: No known threat actor campaigns or exploit-in-the-wild activity have been observed as of the intelligence report date. The vulnerability was disclosed as a coordinated/found security issue; active exploitation has not been confirmed. However, given the low exploitation barrier, act quickly — patching and monitoring are strongly recommended.