CVE-2026-91980

Executive Summary

CVE-2026-91980 is an improper authorization / information disclosure flaw (CWE-200) in Vikunja, an open-source task and project management platform, affecting all versions before 2.6.0. The application fails to validate team-level access control when teams are attached to projects, allowing any authenticated user to supply arbitrary team IDs to the project teams endpoint and retrieve complete team rosters — including member names and administrator flags — for teams they do not belong to. Operational impact is limited to confidentiality (CVSS 4.3, C:L), but the leaked organizational structure and privileged-user mapping is high-value reconnaissance material for follow-on social engineering and privilege-escalation attacks.

Technical Analysis

The vulnerability resides in the access-control logic that governs the relationship between projects and teams in Vikunja's data model. Vikunja organizes work into projects, and access to a project can be delegated to teams; each team carries a roster of members, and individual membership records indicate whether a given user holds an administrative role within that team. The project-teams association endpoint is intended to be reachable only by users who already have legitimate rights over the affected project.

Per the NVD description, the pre-2.6.0 implementation "fails to validate team access when attaching teams to projects." In practical terms, when an authenticated user submits a request to attach a team to a project, the server does not verify that the caller is authorized to reference — or attach — the specific team ID supplied. Because team IDs are numeric/sequential identifiers that are trivially enumerable, this missing authorization check functions as an object-level authorization (IDOR-style) weakness layered on top of a broken function-level access control. The consequence is twofold:

1. Enumeration of all teams. By iterating candidate team IDs through the project-teams attachment flow, an attacker can determine which team IDs exist and are valid.
2. Disclosure of team membership. When a valid team ID is successfully attached, the response surfaces the team's roster, which the description explicitly states includes member names and admin flags.

The CVSS vector confirms the profile: AV:N (remotely reachable), AC:L (no special conditions), PR:L (a low-privileged authenticated account is sufficient), UI:N (no victim interaction), S:U (impact confined to the vulnerable component's security authority), C:L (limited confidentiality impact — structured metadata, not credentials or full record content), and no integrity or availability impact. The EPSS score of 0.00271 (~19.4th percentile) indicates that while the flaw is trivially exploitable by a motivated insider or authenticated tenant, there is currently no observed mass-exploitation activity, consistent with the absence of a public PoC (POC_STATUS: None) and no Nuclei template.

No public exploit code exists. The mechanism is nevertheless straightforward to reason about at the vulnerability-class level: authenticated request → attacker-controlled team identifier → missing ownership/authorization check → unauthorized data returned in the response body.

Exploitation Scenarios

Because no public PoC exists (POC_STATUS: None), the following chain is inferred strictly from the vulnerability class (broken object-level authorization / information disclosure) and the NVD description. No function names, parameters, or endpoints beyond those stated in the description are asserted.

1. Reconnaissance / target identification. The attacker obtains any valid low-privileged account on the Vikunja instance (self-registration if enabled, a compromised account, or a legitimate contractor account). They identify a target project they can reach and observe that team identifiers are simple, predictable numeric values.

2. Triggering the flaw class. The attacker issues requests to the project teams endpoint, attaching arbitrary team IDs rather than only teams they belong to. The server fails the missing authorization check — it "fails to validate team access when attaching teams to projects" — and accepts the attacker-supplied team ID.

3. Payload / execution method (class level). The "payload" is the manipulated team identifier itself. By iterating candidate IDs, the attacker enumerates all teams. For each valid team ID, the response discloses the complete team roster including member names and admin flags.

4. Post-exploitation impact. The attacker compiles a directory of teams, their members, and which members are administrators. There is no write, deletion, or code-execution primitive described — the impact is purely disclosure. However, the harvested roster enables targeted phishing/social engineering of named individuals, identification of high-value administrator accounts for credential-stuffing or password-spraying, and mapping of the org chart to plan lateral movement. Because the flaw is read-only and low-noise, it can be repeated over time to track membership changes.

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:L/I:N/A:N. Interpretation of subscores:

• Confidentiality (C:L): Limited — leaked data is organizational metadata (team names, member names, admin flags), not credentials or full content of projects or tasks.
• Integrity (I:N) / Availability (A:N): No impact described; the flaw does not modify or destroy data.
• Scope (S:U): Impact stays within the Vikunja authorization boundary.
• Privileges Required (PR:L): Any authenticated user qualifies; unauthenticated attackers cannot exploit it directly.

Blast radius: Every Vikunja deployment below 2.6.0 that hosts more than one team and permits authenticated user access. Multi-tenant or externally exposed instances are at highest risk because any single low-privileged account can enumerate the entire tenant's team structure.

Business impact: Direct impact is reputational and reconnaissance-oriented rather than disruptive. In regulated environments, disclosure of employee names and role assignments may itself constitute a privacy/access-control incident. The leaked administrator mapping materially lowers the cost of subsequent targeted attacks, making this a classic "low-severity, high-leverage" information-disclosure bug that security teams should not dismiss purely on CVSS.

Detection Guidance

Sigma Rule

title: Vikunja Team Access Control Bypass - Project Team Attachment Enumeration
id: 8f2c1a44-9091-4e7a-b6d2-7a1c5e3f9198
status: experimental
description: Detects authenticated requests that attach arbitrary/non-owned team IDs to projects in Vikunja (CVE-2026-91980), indicating team enumeration and roster disclosure.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-91980
author: valtersit.com
date: 2026-01-01
logsource:
  category: webserver
  product: vikunja
detection:
  selection_endpoint:
    cs-uri-stem|contains:
      - '/projects/'
    cs-uri-stem|endswith:
      - '/teams'
  selection_method:
    cs-method: 'POST'
  selection_team_param:
    cs-uri-query|contains: 'team_id'
  condition: selection_endpoint and selection_method and selection_team_param
fields:
  - c-ip
  - cs-username
  - cs-uri-stem
  - cs-uri-query
falsepositives:
  - Legitimate project administrators attaching teams they own
level: medium
tags:
  - attack.t1213
  - cve.2026-91980

YARA Rule

rule CVE_2026_91980_Vikunja_TeamEnumeration
{
    meta:
        description = "Detects Vikunja API traffic indicating team enumeration via arbitrary team ID attachment (CVE-2026-91980)"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-91980"
        date = "2026-01-01"
        cve = "CVE-2026-91980"

    strings:
        $ep1 = "/teams" ascii nocase
        $ep2 = "team_id" ascii nocase
        $proj = "/projects/" ascii nocase
        $member = "members" ascii nocase
        $admin = "admin" ascii nocase

    condition:
        $ep1 and $ep2 and $proj and any of ($member, $admin)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-91980 Vikunja Team Access Control Bypass - Project Team Attachment Enumeration"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/projects/"; http.uri; content:"/teams"; http.uri; content:"team_id"; reference:cve,CVE-2026-91980; reference:url,https://nvd.nist.gov/vuln/detail/CVE-2026-91980; classtype:attempted-recon; sid:99091980; rev:1;)

Elastic Detection

sequence by user.name with maxspan=5m
  [http where http.request.method == "POST" and
     wildcard(http.request.path, "/projects/*/teams")]
  [http where http.request.method == "POST" and
     wildcard(http.request.path, "/projects/*/teams") and
     wildcard(http.request.body, "*team_id*")]

Splunk SPL Query

index=web OR index=proxy sourcetype=access_combined
| search method=POST uri_path="*/projects/*/teams*" uri_query="*team_id*"
| stats count min(_time) as first_seen max(_time) as last_seen
        values(uri_query) as queries by src_ip, user
| where count > 5
| sort - count

Wazuh OSSEC Rule

<group name="vikunja,web,cve-2026-91980,">
  <rule id="919800" level="10">
    <decoded_as>json</decoded_as>
    <field name="http.method">POST</field>
    <field name="http.path" type="pcre2">/projects/[^/]+/teams</field>
    <field name="http.path" type="pcre2">team_id</field>
    <description>CVE-2026-91980: Vikunja team access control bypass - arbitrary team ID attached to project; possible roster enumeration/disclosure.</description>
    <mitre>
      <id>T1213</id>
    </mitre>
    <group>attack,access_control_disclosure,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 — CLAIMED. A single source (OSV) claims the issue is addressed in Vikunja 2.6.0, and OSV lists the affected package as unfixed for the queried range. This fix has not been independently confirmed, and no official vendor advisory text is available, so treat the version as the best-available indicator rather than a verified remediation target.

1) Immediate mitigations (until the fix is verified):

• Restrict creation of new accounts; disable open self-registration so the attacker population is limited to vetted users.
• Do not expose the Vikunja instance directly to the internet; place it behind an authenticated reverse proxy or VPN.
• Apply rate limiting and anomaly alerting on the project-teams endpoint to slow ID enumeration and create detection signal.
• Apply least-privilege team/project membership so that even leaked rosters reveal minimal information.
• Deploy the detection rules above and alert on repeated team-attachment attempts with varying team IDs.

2) Patch / upgrade steps:

• Upgrade to Vikunja 2.6.0 or later, but first confirm the fix against the project's official release notes/changelog, since the patch is only single-sourced (OSV) here.
• After upgrading, re-run the enumeration attempt in a test environment to verify that unauthorized team IDs are rejected.
• Rotate any credentials for accounts whose admin status may have been disclosed if a compromise is suspected.

3) Long-term hardening:

• Enforce server-side object-level and function-level authorization on every endpoint, validating that the caller owns or has rights to every referenced object ID — never trusting client-supplied IDs.
• Adopt a centralized authorization middleware pattern to prevent recurring IDOR/broken-access-control classes.
• Use non-enumerable identifiers (e.g., UUIDs) for teams and projects as defense in depth.
• Add automated authorization regression tests to CI/CD for team and project endpoints.
• Continuously monitor Vikunja release channels and OSV for updates to this advisory.

References

• NVD — CVE-2026-91980: https://nvd.nist.gov/vuln/detail/CVE-2026-91980
• OSV advisory (single claimed patch source): https://osv.dev/vulnerability/CVE-2026-91980
• Vikunja project / releases (verify 2.6.0 fix): https://github.com/go-vikunja/vikunja
• CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor: https://cwe.mitre.org/data/definitions/200.html
• CISA KEV Catalog (NOT listed as of report date): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Exploitation evidence: No public PoC, no Nuclei template, and no exploit code were identified. EPSS of 0.00271 (~19.4th percentile) indicates low near-term exploitation likelihood. No CISA KEV listing and no known threat-actor campaigns are associated with CVE-2026-91980 at the time of writing. The absence of observed exploitation does not reduce the value of this disclosure to a motivated authenticated attacker, given its low complexity and reconnaissance value.