CVE-2026-91981

Executive Summary

CVE-2026-91981 is an information disclosure vulnerability in Vikunja, a self-hosted, open-source task and project management platform. Versions prior to 2.6.0 fail to properly validate link-share tokens on the v2 API user-search endpoints, allowing an attacker who possesses a read-only share link to enumerate project users and confirm the existence of arbitrary usernames. The impact is limited to confidentiality (CVSS 4.3, C:L) — no integrity or availability loss — but the leaked user enumeration data is a valuable reconnaissance primitive for follow-on credential attacks.

Technical Analysis

Vikunja exposes a REST API organized into versioned namespaces (the NVD description references a "v2 API"). The platform supports "link shares" — tokenized, permission-scoped URLs that grant external parties limited access to a project without requiring a full user account. A link share is intended to be read-only and scoped to a single project's resources.

The vulnerability lies in the authorization logic for two user-search endpoints. According to the NVD description, the v2 API:

1. Project users endpoint — When accessed with a read-only share token, this endpoint returns the list of users belonging to a project. The token validation fails to confirm that user-listing is a permitted operation for a link-share principal, so an external share holder can enumerate the full project membership.
2. Global search endpoint — This endpoint accepts a username query and returns a result indicating whether that username exists. Again, link-share token validation is insufficient, so an attacker with only a read-only share can perform username enumeration on an application-wide scope.

The root cause maps to CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) — specifically an authorization/access-control gap where the token is authenticated (the share link is valid) but the scope of the authentication is not enforced against the requested resource. The flaw is a broken object- or function-level authorization pattern: the presence of a valid share token is treated as sufficient to satisfy the request, without checking that the token's permission set (read-only, single project) covers the user-enumeration operations being invoked.

Key properties:

• Attack vector: Network (AV:N).
• Privileges required: Low (PR:L) — the attacker must already hold a read-only share link, which is a low-bar secret typically distributed to external collaborators.
• User interaction: None (UI:N).
• Complexity: Low (AC:L).
• Confidentiality impact: Low (C:L) — usernames and project membership are exposed, but no passwords, tokens, or task data.
• Scope: Unchanged (S:U) — the vulnerable component and impacted component are the same.

The EPSS score is 0.00241 (15.4th percentile), indicating a low predicted probability of exploitation in the wild over the next 30 days. There is no public PoC, no Nuclei template, and no exploit code available. CISA KEV does not list this CVE.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class (broken token-scope authorization) and the endpoint behavior described in the NVD description. Only endpoints explicitly named in the description are referenced.

1) Reconnaissance / target identification. The attacker identifies a Vikunja instance (self-hosted deployments are commonly reachable on the internet or a partner network). The attacker obtains a read-only share link — for example, one legitimately issued to an external contractor, leaked in a document, or shared too broadly. This share link carries a token that the v2 API accepts as an authenticated principal.

2) Triggering the flaw class. With the share token, the attacker calls the v2 API projects endpoint that lists the users of the project the share belongs to. Because token validation does not enforce the read-only link-share scope against the user-listing operation, the response returns the project's user roster. The attacker then pivots to the global search endpoint, submitting arbitrary usernames; the endpoint confirms whether each username exists, again without rejecting the link-share principal.

3) Execution method (vulnerability class). This is a broken authorization / insecure direct object reference at the API layer. No payload crafting, injection, or memory corruption is required — the attacker simply issues well-formed authenticated API requests (using the share token as the credential) against the user-search endpoints and reads the responses. The "exploit" is the absence of a scope check.

4) Post-exploitation impact. The attacker accumulates a list of valid usernames and project members (a username/account harvesting set). This enables subsequent targeted phishing, password-spraying, credential-stuffing, and social-engineering campaigns against the organization, and reveals internal project-membership structure. No data modification, deletion, or service disruption occurs.

Impact Assessment

• Confidentiality: Low — disclosure of usernames and project membership. Usernames are commonly reused as corporate email identifiers, making them a high-value phishing anchor.
• Integrity: None — the flaw is read-only; no write path is described.
• Availability: None.
• Blast radius: Any Vikunja deployment running a version below 2.6.0 that issues read-only share links. Because Vikunja is frequently self-hosted by internal teams, exposure may be limited to internal networks, but internet-facing instances carry higher risk.
• Business impact: Direct operational impact is modest (information disclosure only). The strategic impact is reconnaissance value — feeding credential attacks and enabling organizational mapping (who belongs to which project). Combined with a weak-password policy, username enumeration meaningfully raises the success rate of credential-stuffing.
• CVSS justification: The 4.3 score reflects low privileges required (a share link), low complexity, no user interaction, and low confidentiality impact with no integrity/availability effect. EPSS reinforces a low exploitation likelihood, so prioritization should be moderate.

Detection Guidance

Because the exploit uses legitimate authentication (a valid share token) against normal API endpoints, detection must focus on behavioral anomalies — user-search patterns and project-user enumeration from share-link principals — rather than signature matching.

Sigma Rule

title: Vikunja v2 API User Enumeration via Read-Only Share Token
id: 8f3c1a2e-7b64-4d9a-9c2f-vikunja200
status: experimental
description: Detects access to Vikunja v2 API user-search/project-user endpoints, indicative of CVE-2026-91981 enumeration.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-91981
author: valtersit.com
date: 2026/01/01
tags:
  - attack.t1213
  - cve.2026.91981
logsource:
  category: webserver
  product: vikunja
detection:
  selection_endpoints:
    cs-uri-stem|contains:
      - '/api/v2/projects/'
      - '/api/v2/user'
      - '/api/v2/search'
  selection_share_token:
    cs-uri-query|contains: 'share='
  condition: selection_endpoints and selection_share_token
falsepositives:
  - Legitimate share-link users browsing project members
level: low

YARA Rule

rule CVE_2026_91981_Vikunja_UserEnumeration
{
    meta:
        description = "Detects Vikunja v2 API user-search / project-user enumeration requests associated with CVE-2026-91981"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-91981"
        date = "2026-01-01"
    strings:
        $api_v2 = "/api/v2/" ascii nocase
        $proj = "projects/" ascii nocase
        $search = "search" ascii nocase
        $share = "share" ascii nocase
    condition:
        $api_v2 and ($proj or $search) and $share
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-91981 Vikunja v2 API User Enumeration via Share Token"; \
  flow:established,to_server; \
  http.method; content:"GET"; \
  http.uri; content:"/api/v2/"; \
  http.uri; content:"search"; nocase; \
  http.uri; content:"share"; nocase; \
  reference:cve,2026-91981; \
  classtype:attempted-recon; sid:202691981; rev:1;)

Elastic Detection

network where
  http.request.method == "GET" and
  startsWith(http.request.url.path, "/api/v2/") and
  (http.request.url.path : "*projects*" or http.request.url.path : "*search*") and
  http.request.url.query : "*share*"

Splunk SPL Query

index=web sourcetype=vikunja_access
  uri_path IN ("/api/v2/*")
  (uri_query="*share*")
  (uri_path="*/projects/*" OR uri_path="*/search*")
| stats count values(uri_path) as paths values(uri_query) as queries by src_ip
| where count > 10
| sort - count

Wazuh OSSEC Rule

<group name="web,vikunja,cve-2026-91981,">
  <rule id="2026919" level="6">
    <if_sid>31100</if_sid>
    <url>/api/v2/</url>
    <match>share</match>
    <regex>projects|search</regex>
    <description>CVE-2026-91981: Possible Vikunja v2 API user enumeration via read-only share token</description>
    <group>cve_2026_91981,recon,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED — single source claims a patch via OSV; not independently confirmed by the vendor advisory or a second source).

1. Immediate mitigations

   • Restrict issuance and distribution of read-only share links; audit existing share links and revoke any that are stale or over-shared.
   • Place internet-facing Vikunja instances behind an authenticated reverse proxy or VPN to reduce reachable attack surface.
   • Rate-limit the v2 API search and project-user endpoints at the reverse-proxy/WAF layer to blunt bulk enumeration.
   • Monitor logs for repeated user-search requests originating from share-token principals.

2. Patch / upgrade steps

   • Upgrade to Vikunja 2.6.0 or later where the token-scope validation is claimed to be corrected. Because patch confidence is only CLAIMED, verify via the upstream Vikunja release notes and changelog that 2.6.0 contains the authorization fix before treating the issue as closed.
   • Validate the fix by re-testing: with a read-only share token, confirm the projects user-listing endpoint and the global search endpoint no longer return user data or username-existence confirmation.
   • If 2.6.0 is unavailable or the fix is unconfirmed, treat the deployment as vulnerable and apply compensating controls.

3. Long-term hardening

   • Enforce strict, resource-level scope checks for all link-share tokens (deny-by-default authorization), so a share token can only reach the single project resource it was issued for.
   • Adopt least-privilege design for anonymous/link-share principals and add automated authorization regression tests for share-token endpoints.
   • Monitor upstream Vikunja security advisories and subscribe to the project's release feed; establish a patch SLA based on internet exposure.

References

• NVD — CVE-2026-91981: https://nvd.nist.gov/vuln/detail/CVE-2026-91981
• OSV — claimed fix entry for Vikunja (single-source; source of patch claim): https://osv.dev/
• Vikunja project releases / changelog (verify 2.6.0 fix): https://vikunja.io/ (see project repository releases)
• MITRE ATT&CK T1213 — Data from Information Repositories: https://attack.mitre.org/techniques/T1213/
• CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor: https://cwe.mitre.org/data/definitions/200.html

Exploit-in-the-wild evidence: None. No public PoC, no Nuclei template, no exploit code, and CISA KEV does not list this CVE. EPSS 0.00241 (15.4th percentile) indicates low predicted exploitation activity. No known threat actor campaigns are associated with this CVE as of the available data.