Description

Vikunja before 2.6.0 fails to properly restrict access to the link-share hash field in single-share read endpoints, allowing read-only members to obtain the share's secret credential. Attackers can exchange the disclosed hash for a link-share JWT at the share's permission level to escalate privileges and perform unauthorized writes or administrative actions.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-15T16:17:57.010Z",
  "pubdate": "2026-09-15T16:17:57.010Z",
  "executiveSummary": "Vikunja versions prior to 2.6.0 contain an improper access control vulnerability within single-share read endpoints.\nThe vulnerability permits low-privileged, read-only members to access the sensitive link-share hash field, which serves as a secret credential for shared resources.\nAn attacker can exploit this exposure by harvesting the hash and utilizing it to authenticate against the link-share interface, effectively upgrading their authorization level to that of the share's configured permissions.\nThis privilege escalation allows unauthorized actors to perform write operations, modify resource states, or conduct administrative actions that exceed their originally assigned role.\nThe flaw stems from a failure to enforce authorization checks on sensitive metadata fields during object retrieval, posing a significant risk to data integrity and access control enforcement within collaborative instances.\nExploitation requires existing read-only access to a shared resource, but the impact is severe, potentially leading to full unauthorized control over the affected shared entities.",
  "technicalDetails": "The vulnerability is rooted in an authorization enforcement failure within the API endpoints responsible for single-share retrieval in Vikunja versions before 2.6.0. Specifically, the backend logic incorrectly includes the private link-share hash in the JSON response body when processed by read-only users.\nIn a secure configuration, the link-share hash acts as a secret token required to obtain a JSON Web Token (JWT) that defines the session's permission level. By leaking this secret to users who should only have passive read access, the application inadvertently provides the mechanism required for authorization bypass.\nThe attack flow proceeds as follows: First, an attacker with legitimate read-only access to a Vikunja share initiates a request to the single-share read endpoint. Because the application logic fails to filter the response based on the requester's permission set, the server serializes the object including the 'hash' field.\nSecond, the attacker parses the response to extract the secret hash string. Third, the attacker transmits this hash to the authentication or token-exchange service, which evaluates the hash as a valid credential for the associated share.\nFinally, the service issues a link-share JWT with escalated privileges. This JWT grants the attacker the ability to interact with the share at the level permitted by the original link-share creator, which typically includes write access or administrative privileges. With this escalated JWT, the attacker can perform unauthorized actions such as modifying project tasks, deleting data, or changing share configurations, depending on the scope of the original share.\nThe vulnerability is a classic case of Broken Object Level Authorization (BOLA) combined with an information disclosure flaw. The server relies on client-side state or incomplete server-side validation to assume that read-only access does not extend to the cryptographic material governing the resource's authorization model. Since the API does not perform a secondary validation check to ensure the requester has administrative ownership of the share object, the integrity of the share's permission model is completely compromised upon the disclosure of the secret hash."
}