CVE-2026-54766

Executive Summary

CVE-2026-54766 is an improper authorization vulnerability (CWE-285) in Vikunja, an open-source self-hosted task management platform, affecting versions 0.21.0 through 2.4.0. The flaw resides in the project duplication operation, where an authenticated user with read access to a source project can place its duplicate beneath an arbitrary target parent project without possessing write permissions on that target. This permission bypass allows attacker-controlled content to be injected into other users' or teams' project hierarchies, potentially leading to unauthorized data placement, phishing opportunities, or disruption of project structures. The issue has been fixed in version 2.4.0; however, patch confidence is rated 0/4 as no patch evidence from tracked sources was available, and no public exploit code exists at the time of writing.

Technical Analysis

The vulnerability originates in the project duplication functionality, specifically in the file pkg/models/project_duplicate.go. The affected code path is triggered via the HTTP endpoint PUT /api/v1/projects/{project}/duplicate, which handles the mechanics of duplicating a source project into a target location.

The core authorization flaw lies in the validation logic implemented in the ProjectDuplicate.CanCreate method. When a duplication operation is initiated, this method is invoked to determine whether the authenticated user has sufficient privileges to perform the action. However, the implementation contains a critical logical error: instead of calling parent.CanWrite to verify that the requesting user has write permissions on the target parent project, the code invokes parent.CanCreate on an "unhydrated" Project object.

The term "unhydrated" refers to a Project object that contains only the minimal data supplied in the request body — specifically the parent_project_id field — without the full context of the actual parent project record from the database. This means the authorization check is performed against an incomplete, attacker-controlled representation of the parent project rather than the authoritative stored data.

The consequence of this discrepancy is that the parent.CanCreate check evaluates conditions that are not equivalent to a write-permission check. An attacker who can read a source project (which may be a project they legitimately own or have been granted read access to) can request duplication into a target parent project for which they lack write permissions. Since the check inspects properties of the supplied body data rather than the actual target project's permission configuration, the privilege boundary is bypassed.

It is important to note that the ordinary project creation path enforces the correct permission check (write permission on the parent). The duplication endpoint, however, deviates from this secure pattern, representing a classic case of inconsistent authorization enforcement across different code paths within the same application.

Attack Surface:

• Authenticated users only (requires a valid account on the Vikunja instance)
• Network-accessible instance (self-hosted deployments exposed to the internet or internal networks)
• The duplication API endpoint is the sole vector

The vulnerability does not require any special role beyond a standard authenticated user, making it accessible to the broadest possible attacker population within the application's user base.

Exploitation Scenarios

No public PoC is available; the attack chain is inferred from the vulnerability class and the technical description provided.

Step 1 — Reconnaissance and Target Identification:
An attacker with a valid user account on a Vikunja instance (versions 0.21.0 through 2.4.0) begins by enumerating projects available in the instance. The attacker identifies a source project they have read access to — this could be a project they own, a project shared with them via read-only access, or a public project. The attacker also identifies a target parent project that belongs to another user or team, into which they wish to inject content. The attacker does not have write permissions on this target parent project.

Step 2 — Triggering the Flaw:
The attacker crafts an HTTP request to the endpoint PUT /api/v1/projects/{project}/duplicate. In the request body, the attacker specifies the source project (using the project ID from the URL path) and provides a parent_project_id pointing to the target parent project. The attacker's account makes this request with valid session credentials.

Step 3 — Vulnerability-Class Exploitation:
Upon receiving the request, the application begins processing the duplication. It calls ProjectDuplicate.CanCreate, which erroneously invokes parent.CanCreate on an unhydrated Project object containing only the body-supplied parent_project_id. Because the check operates on this incomplete representation rather than loading the actual target parent project and verifying write permissions, the authorization check passes despite the attacker lacking write access. The application proceeds with the duplication, creating a new project beneath the attacker-chosen parent.

Step 4 — Post-Exploitation Impact:
Following successful exploitation, the attacker has injected their project — including any tasks, notes, or files contained within the duplicated source project — into another user's or team's project hierarchy. This achieves several malicious objectives:

• Data injection: Attacker-controlled content now appears within a legitimate project structure, potentially confusing users or misleading them into interacting with malicious content.
• Phishing vector: The attacker can populate the injected project with deceptive tasks or links that appear to originate from a trusted team context.
• Integrity compromise: The target parent project's structure is altered without authorization, potentially disrupting workflows or corrupting organizational data organization.
• Persistence: The injected project persists in the hierarchy until manually removed by a user with sufficient privileges.

Proof of Concept Intelligence

1) Why exploitation may still be possible:
The absence of a public PoC does not diminish the exploitability of this vulnerability. The flaw is a straightforward authorization bypass that can be triggered with a single, standard HTTP request using the documented API. Any attacker with basic HTTP client capabilities and a valid session token can craft the required request without needing specialized exploit frameworks. The logic error in the permission check is deterministic — it does not rely on race conditions, memory corruption, or complex state manipulation. Given the simplicity of the attack, exploitation is highly likely to be privately achieved by security researchers or attackers who analyze the open-source codebase.

2) Resources defenders should monitor for future PoC disclosure:

• GitHub Advisory Database: Vikunja is open-source and hosted on GitHub; the advisory will be tracked here.
• Vikunja's official release notes and security advisories on their website (vikunja.io) and GitHub releases page.
• VulnDB/CVE feeds: Monitor NVD and MITRE CVE lists for updates, including proof-of-concept references appended to the CVE record.
• Exploit databases: Exploit-DB, Metasploit framework updates, and Packet Storm Security for PoC scripts.
• Security researcher communication channels: Twitter/X accounts of prominent Go/web application security researchers, and security mailing lists such as oss-security.
• GitHub code search: Monitor for new repositories or gists containing exploit code for this CVE ID.

Impact Assessment

Business Impact:
The vulnerability enables an authenticated attacker to bypass write-permission checks and inject arbitrary project content into unauthorized locations within the Vikunja application. From a business perspective, this represents a medium-to-high integrity impact. The confidentiality and availability aspects are largely unaffected — the attacker cannot read data from projects they lack read access to, and the attack does not directly cause denial of service. However, the integrity of the project hierarchy is compromised, which in a task management context can lead to workflow disruption, misdirected team attention, and the introduction of malicious or deceptive content into trusted team spaces.

Affected Systems:

• Self-hosted Vikunja instances running versions 0.21.0 through 2.4.0 (excluding 2.4.0 which contains the fix).
• Deployments using the described duplication feature.
• CVSS score is N/A; severity assessment must rely on qualitative analysis.

Blast Radius:
The blast radius is constrained to the Vikunja application itself; the vulnerability does not provide access to the underlying host operating system or adjacent infrastructure. However, within the application, the impact extends across all users of the affected instance — any authenticated user can potentially impact any other user's project hierarchy. In multi-tenant or team-based deployments, this broadens the attack surface to the entire user base. The unpatched status and the fact that Vikunja is a popular self-hosted solution mean that many deployments may remain exposed for an extended period.

Detection Guidance

Sigma Rule

title: Suspicious Vikunja Project Duplication - Potential CVE-2026-54766 Exploitation
id: 9f3e1b2c-7d4a-4e8f-9c0b-2a5d8e7f1c3a
status: experimental
description: Detects project duplication API calls in Vikunja where the parent_project_id in the request body differs from the project in the URL path, potentially indicating an attempted authorization bypass (CVE-2026-54766).
tags:
    - attack.t1190
    - cve.2026.54766
logsource:
    category: webserver
    product: vikunja
detection:
    selection:
        http.method: PUT
        http.url|contains: '/api/v1/projects/'
        http.url|endswith: '/duplicate'
        http.body|contains: 'parent_project_id'
    condition: selection
level: high
falsepositives:
    - Legitimate administration tasks where an admin duplicates a project into a different parent
    - Regular project reorganization by users with write permissions on multiple projects
fields:
    - src_ip
    - user_agent
    - http.hostname
    - http.url
    - http.body

YARA Rule

rule CVE_2026_54766_Vikunja_Duplicate_Exploit {
    meta:
        author = "valtersit.com Threat Intelligence"
        description = "Detects Vikunja source files or traffic patterns associated with CVE-2026-54766 authorization bypass in project duplication"
        cve = "CVE-2026-54766"
        date = "2026-02-01"
    strings:
        $s1 = "/api/v1/projects/" ascii wide
        $s2 = "/duplicate" ascii wide
        $s3 = "parent_project_id" ascii wide
        $s4 = "ProjectDuplicate" ascii wide
        $s5 = "CanCreate" ascii wide
        $s6 = "parent.CanCreate" ascii wide
        $s7 = "project_duplicate.go" ascii wide
    condition:
        (uint16(0) == 0x5A4D and 3 of them) or  // PE file with 3+ strings
        (uint32(0) == 0x7F454C46 and 3 of them) or  // ELF file with 3+ strings
        (3 of them)
}

Suricata IDS Rule

alert http any any -> $HOME_NET any (
    msg:"ET EXPLOIT Vikunja CVE-2026-54766 Project Duplicate Authorization Bypass Attempt";
    flow:to_server,established;
    http.method;
    content:"PUT";
    http.uri;
    content:"/api/v1/projects/";
    distance:0;
    content:"/duplicate";
    distance:0;
    http.request_body;
    content:"parent_project_id";
    classtype:attempted-admin;
    sid:10054766;
    rev:1;
    metadata:created_at 2026_02_01, cve CVE-2026-54766, updated_at 2026_02_01;
)

Elastic Detection

sequence by source.ip with maxspan=30s
  [ network where event.type == "start" and destination.port == 443 ]
  [ http where request.method == "PUT" and url.path like "*api/v1/projects*" and url.path like "*duplicate" and url.path like "*" and request.body.type == "json" ]
  [ file where event.action == "create" and file.path like "*project*" ]

Note: This EQL rule assumes IIS-style access logs or http traffic captured via Packetbeat. Adjust field names based on your Elastic indices (filebeat-*, packetbeat-*, etc.).

Splunk SPL Query

index=web OR index=http
    (sourcetype=iis OR sourcetype=access_combined OR sourcetype=apache_access)
    method=PUT
    uri_path="/api/v1/projects/*/duplicate"
| rex field=uri_path "^/api/v1/projects/(?<project>[^/]+)/duplicate$"
| rex field=body "parent_project_id[\"']?\s*[:=]\s*[\"']?(?<requested_parent>\d+)"
| eval potential_exploit = if((project != requested_parent) AND requested_parent != null, 1, 0)
| where potential_exploit = 1
| table _time, src_ip, user, uri_path, body, requested_parent, status
| sort - _time

Alternative query using raw body inspection:

index=web OR index=http
    method=PUT
    uri_path="/api/v1/projects/*/duplicate"
    body="*parent_project_id*"
| rex field=body ".{0,50}parent_project_id[\"']?\s*[:=]\s*[\"']?(?<target_parent_id>\d+)"
| rex field=uri_path "^/api/v1/projects/(?<source_project_id>\d+)"
| where target_parent_id != source_project_id
| table _time, src_ip, user_agent, uri_path, target_parent_id, source_project_id

Wazuh OSSEC Rule

<group name="cve_2026_54766,">
  <rule id="100547" level="10">
    <if_sid>31100</if_sid>
    <regex>\"/api/v1/projects/.{1,100}/duplicate\" </regex>
    <description>Vikunja CVE-2026-54766 Possible Project Duplicate Authorization Bypass</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>attack_exploitation,</group>
    <options>no_full_log</options>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 0/4 — UNPATCHED. No patch evidence from any tracked source is available. The NVD description indicates a fix exists in version 2.4.0, but this has not been independently confirmed by our tracked patch sources.

1) Immediate Mitigations (until patch is verified and applied):

• Upgrade to Vikunja 2.4.0 or later as soon as possible — this is the only known remediation provided by the vendor.
• Restrict network exposure: If the Vikunja instance does not need to be internet-facing, place it behind a VPN or internal network access controls. This reduces the attack surface to trusted internal users.
• Limit user accounts: Review all user accounts on the instance and disable or remove dormant or unneeded accounts to reduce the number of potential attackers.
• Implement WAF rules: Deploy a web application firewall (e.g., ModSecurity, AWS WAF) with custom rules to block PUT requests to the /api/v1/projects/*/duplicate endpoint from non-admin accounts, if feasible.

2) Patch/Upgrade Steps:

1. Verify the current version of your Vikunja deployment by checking the application version string or container image tag.
2. If running version 2.4.0 or later, you are already patched. Otherwise, proceed to step 3.
3. Download the latest release from the official Vikunja GitHub repository or container registry.
4. Follow the official upgrade documentation for your deployment method (Docker, binary, Kubernetes).
5. Backup the database and configuration files before upgrading.
6. After upgrading, verify the fix by attempting to duplicate a project into a parent you do not have write access to — this should now fail with an authorization error.
7. Monitor the Vikunja release channels for any subsequent security patches.

3) Long-Term Hardening:

• Enable multi-factor authentication (MFA) for all Vikunja user accounts to reduce the risk of account compromise.
• Implement least-privilege access: Regularly audit user roles and permissions to ensure users only have the minimum required access.
• Conduct periodic security reviews of self-hosted applications, including checking for outdated versions.
• Integrate threat intelligence feeds to receive early warning of new CVEs affecting your self-hosted stack.
• Maintain an asset inventory of all self-hosted services with their current versions and patch status.
• Establish a formal patching SLA — critical security patches should be applied within 72 hours of release.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-54766 — Official CVE record from NIST National Vulnerability Database. (Note: As of writing, the NVD entry reflects the description provided in this report.)
2. Vikunja Official Website: https://vikunja.io — Vendor site for release announcements and general product information.
3. Vikunja GitHub Repository: https://github.com/go-vikunja/vikunja — Source code repository where the vulnerable file pkg/models/project_duplicate.go resides and where version 2.4.0 (containing the fix) will be released.
4. MITRE ATT&CK Technique T1190: https://attack.mitre.org/techniques/T1190/ — Exploit Public-Facing Application, the associated MITRE tactic.
5. CWE-285 Improper Authorization: https://cwe.mitre.org/data/definitions/285.html — Common Weakness Enumeration entry for this vulnerability class.

Threat Actor Campaigns / Exploit-in-the-Wild: No known threat actor campaigns or exploit-in-the-wild activity has been reported for CVE-2026-54766 at the time of writing. CISA has not added this CVE to the Known Exploited Vulnerabilities (KEV) catalog. The absence of reported exploitation should not be interpreted as absence of risk — the vulnerability is trivially exploitable once discovered and the attack surface (authenticated users) is broad. Security teams should prioritize patching regardless of the lack of known in-the-wild activity.

Report generated by: vartersit.com Threat Intelligence
Classification: TLP:CLEAR