External risk intelligence

Vikunja Authorization Flaw Leads to Instance-Wide Data Exposure

CVE advisorySeverity: CRITICAL (CVSS 9.3)

CVE-2026-56765

Vikunja is a project management and to-do list application commonly deployed as a public-facing web service or API for user access. The vulnerabilities exist within web endpoints reachable by users, consistent with the typical deployment pattern of a web-based productivity application accessible over the internet.

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This advisory concerns an authorization flaw in Vikunja, a project management and to-do list application. The vulnerability could allow unauthorized access and modification of sensitive data, including file attachments across all projects, by bypassing permission checks.

  • Flaw allows unauthorized access to shared links and files.
  • Affects a project management tool often used externally.
  • Confirm relevance and assess exposure of your Vikunja instances.

Attack Path

How an attacker could exploit the issue

An attacker could exploit this vulnerability by first leveraging an authorization flaw in the LinkSharing.ReadAll endpoint to gain access to share hashes, potentially escalating privileges. Subsequently, they could use the GetTaskAttachment endpoint to download or delete any task attachment across the entire instance without proper ownership verification. This chained attack could lead to significant data exposure and manipulation.

  • No authentication required to start.
  • Vulnerable endpoints are exposed via web.
  • Risk of instance-wide data breach.

Live Threat

Current exploitation, exposure, and threat context

This vulnerability could allow an unauthenticated attacker to gain unauthorized access to sensitive information, including administrative shares and all file attachments across an entire Vikunja instance. When supported by the advisory, this could occur by exploiting authorization flaws in the LinkSharing.ReadAll endpoint and insecure permission checks in the GetTaskAttachment endpoint.

  • Sensitive system and user data could be exposed.
  • Access via network without authentication.
  • Unauthorized admin access and data exfiltration.

Operational Fix

Recommended remediation, mitigation, and detection steps

Application owners and infrastructure teams are likely responsible for addressing this authorization flaw in Vikunja. The first practical step involves identifying all instances of Vikunja, assessing their reachability and business criticality, and then determining the accountable owner to plan a risk-based remediation.

  • Identify application owners and assets.
  • Verify reachability and business criticality.
  • Plan remediation based on confirmed risk.

Supplementary metadata

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Frequently asked questions

What is Vikunja?

Vikunja is an open-source project management and to-do list application. It is designed to help teams and individuals track tasks, collaborate on projects, and manage file attachments. Because it functions as a web service, users typically interact with it through a browser or API to organize their work and share project resources across an organization.

What does CVE-2026-56765 mean?

This CVE describes an authorization vulnerability classified as CWE-639, often called Insecure Direct Object Reference (IDOR). In simple terms, the application fails to verify if a user has permission to access or modify a specific resource. In this case, the software trusts user-supplied inputs for file IDs, allowing someone to interact with attachments they do not own or are not authorized to see.

How is this vulnerability triggered?

An attacker can trigger this by interacting with specific web endpoints without needing to be logged in. By querying the system for share hashes or specific task attachment IDs, they can bypass standard access controls. Importantly, this does not require a valid user account; the flaw exists because the backend assumes the requester has permission simply by knowing or guessing an ID, rather than verifying ownership of that specific data.

Is my Vikunja instance at risk?

According to Halo Surface Signal, this vulnerability is particularly relevant if your instance is deployed as a public-facing web service. Because Vikunja is commonly accessed over the internet for collaboration, endpoints reachable from outside your network are at higher risk. If your instance is restricted to internal users only, the likelihood of unauthorized external access is lower, though internal access controls remain a concern.

What are the first steps to address this?

Begin by creating a complete inventory of all Vikunja instances running in your environment. Determine which of these are reachable via the internet and identify the business owner for each deployment. Once you have a clear picture of your assets and their criticality, coordinate with your infrastructure or application teams to prepare for remediation and verify that no unauthorized activity has occurred on your systems.

References