Vikunja - CraftedSignal Threat Feed

Authorization Flaws in Vikunja Expose Share Hashes and Allow Attachment Manipulation

hello@craftedsignal.io — Fri, 10 Jul 2026 15:18:05 +0000

CVE-2026-56765 details two critical authorization flaws affecting Vikunja versions prior to 2.2.1. The first vulnerability resides in the LinkSharing.ReadAll API endpoint, which inadvertently exposes sensitive share hashes to any authenticated user possessing read access. This exposure allows an attacker to obtain hashes for admin-level shares, facilitating a privilege escalation to gain unauthorized access to administrative functions or content. The second flaw is an Insecure Direct Object Reference (IDOR) found in the GetTaskAttachment endpoint. While this endpoint performs initial permission checks based on user-supplied task IDs, it subsequently fetches attachments by sequential ID without proper ownership verification. This oversight enables an attacker to bypass access controls, leading to the unauthorized download and deletion of all file attachments across every project within the Vikunja instance, resulting in severe data breach and data loss risks.

Attack Chain

An authenticated attacker, with at least read access to the Vikunja instance, sends a request to the LinkSharing.ReadAll API endpoint.
The LinkSharing.ReadAll endpoint responds by exposing sensitive share hashes, including those associated with admin-level shares, to the attacker.
The attacker utilizes the obtained admin-level share hashes to bypass intended access controls and escalate their privileges to gain unauthorized access to administrative functions or content.
(Potentially independently or chained) The attacker sends requests to the GetTaskAttachment endpoint, supplying arbitrary task IDs.
The GetTaskAttachment endpoint performs permission checks against the supplied task ID but then fetches attachments by sequential ID from the backend data store.
The endpoint fails to verify ownership or authorization for the attachments retrieved by sequential ID, allowing the attacker to bypass access controls.
The attacker iterates through sequential attachment IDs, downloading all file attachments across all projects throughout the entire Vikunja instance, leading to data exfiltration.
The attacker can also leverage the same IDOR to send delete requests for these sequential attachment IDs, resulting in the deletion of all file attachments across all projects instance-wide.

Impact

Successful exploitation of CVE-2026-56765 leads to critical security consequences impacting the entire Vikunja instance. Attackers can escalate their privileges to administrative levels, gaining unauthorized control over the platform's features and data. More significantly, the IDOR vulnerability allows for an instance-wide data breach, enabling attackers to download all user-uploaded file attachments from every project. This could expose sensitive business documents, personal information, or proprietary data. Furthermore, the ability to delete all file attachments across all projects poses a severe data destruction risk, potentially leading to irreversible data loss and significant operational disruption.

Recommendation

Patch Vikunja installations to version 2.2.1 or later immediately to remediate CVE-2026-56765.
Review access logs for the LinkSharing.ReadAll and GetTaskAttachment endpoints for suspicious or excessive access patterns.
Implement API gateway logging to capture full HTTP request and response bodies for deeper analysis of unexpected data exposure or IDOR attempts on CVE-2026-56765 related endpoints.

Vikunja Unauthenticated Instance-Wide Data Breach via Link Share and IDOR

hello@craftedsignal.io — Tue, 30 Jan 2024 12:00:00 +0000

An unauthenticated attacker can exploit two chained vulnerabilities in Vikunja, a self-hosted to-do list application, to achieve instance-wide data exfiltration and destruction. The vulnerability lies in versions 2.2.0 and earlier. The first vulnerability involves the disclosure of link share hashes, including those with administrative privileges, via the ReadAll endpoint for link shares. The second vulnerability is a cross-project attachment IDOR (Insecure Direct Object Reference) that arises from improper permission checks in the ReadOne/GetTaskAttachment endpoint. By chaining these vulnerabilities, an attacker can escalate privileges from a read-only link share to an administrative role, enumerate all attachments across all projects, and then download or delete any attachment, regardless of project membership or access controls. This poses a significant risk to the confidentiality and integrity of data stored within Vikunja instances.

Attack Chain

Attacker obtains a URL for a public link share (e.g., via social engineering or accidental exposure).
Attacker authenticates to the Vikunja API using the read-only link share hash via POST /shares/{hash}/auth to obtain a JWT.
The attacker enumerates all link shares for the project associated with the initial share using GET /projects/{id}/shares. The API discloses all share hashes, including those with admin privileges.
The attacker authenticates using an admin-level share hash via POST /shares/{admin_hash}/auth to escalate privileges.
The attacker identifies an accessible task ID within the project using GET /projects/{id}/tasks. This task is only used to bypass initial checks.
The attacker exploits the attachment IDOR by sending requests like GET /tasks/{accessible_task}/attachments/{1..N} to enumerate attachment IDs sequentially across all projects. The server checks permissions against the specified task but serves attachments based solely on the attachment ID.
The attacker downloads attachments from any project by iterating through attachment IDs.
If the attacker escalated to an admin share, they can delete attachments from other projects using DELETE /tasks/{accessible_task}/attachments/{TARGET_ATTACHMENT_ID} causing data loss.

Impact

Successful exploitation of these vulnerabilities leads to a complete breach of data confidentiality and integrity. An attacker, starting with just a publicly shared link, can download every file attachment across all projects, potentially exposing sensitive documents, images, and other confidential information. The vulnerability allows for the deletion of arbitrary attachments, leading to significant data loss. The impact is amplified by the minimal attack prerequisites and the wide blast radius, affecting all projects and users within the Vikunja instance. Given that link shares are designed for external collaboration, a single leaked link can compromise the entire Vikunja instance.

Recommendation

Apply the recommended fixes as outlined in the advisory (https://github.com/advisories/GHSA-2pv8-4c52-mf8j). Specifically, ensure that the Hash field is cleared in ReadAll responses for link shares.
Implement the suggested fix for the attachment IDOR by verifying task ownership in the ReadOne method within pkg/models/task_attachment.go.
Deploy the Sigma rule to detect suspicious attachment downloads across projects based on sequential attachment ID enumeration.
Deploy the Sigma rule to detect link share enumeration, as this is the initial step in the attack chain.
Monitor web server logs for unusual patterns of API requests, particularly to the /projects/{id}/shares and /tasks/{accessible_task}/attachments/{1..N} endpoints.

Vikunja TOTP Two-Factor Authentication Bypass via OIDC Login

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

Vikunja, a self-hostable to-do list application, is vulnerable to a two-factor authentication bypass (CVE-2026-34727) affecting versions 2.2.2 and earlier. The vulnerability arises in the OIDC (OpenID Connect) login flow when the EmailFallback option is enabled. If a local user has TOTP (Time-Based One-Time Password) enabled and their email address matches a user authenticating through the OIDC provider, the TOTP check is skipped. This allows an attacker who can authenticate to the OIDC provider with a matching email address to bypass the TOTP requirement and gain unauthorized access to the Vikunja account. This issue stems from the OIDC callback handler (pkg/modules/auth/openid/openid.go) issuing a JWT without verifying TOTP status.

Attack Chain

The attacker identifies a Vikunja instance with OIDC enabled and EmailFallback set to true.
The attacker identifies a valid local user with TOTP enabled and determines the user's email address.
The attacker creates or compromises an account on the configured OIDC provider that uses the same email address as the target Vikunja user.
The attacker initiates the OIDC login flow to the Vikunja instance.
The OIDC provider authenticates the attacker using their compromised or created account.
Vikunja's OIDC callback handler (pkg/modules/auth/openid/openid.go) matches the email address from the OIDC provider to the local user.
The callback handler incorrectly issues a JWT without performing TOTP verification, bypassing the second factor.
The attacker uses the received JWT to authenticate to the Vikunja API and gains full access to the user's account.

Impact

Successful exploitation allows an attacker to bypass TOTP two-factor authentication and gain unauthorized access to Vikunja accounts. This can lead to data breaches, modification of tasks and projects, and potential further compromise of the Vikunja instance. Any user who has enrolled TOTP on their local account can have that protection completely bypassed if their email address is also present in the OIDC provider. This undermines the security of TOTP enrollment.

Recommendation

Apply the recommended fix by adding a TOTP check in the OIDC callback before issuing the JWT, as described in the advisory.
Disable the EmailFallback option in the Vikunja OIDC configuration until the patch is applied.
Monitor Vikunja logs for unusual OIDC login activity, specifically successful OIDC logins for users who also have local accounts with TOTP enabled.
Deploy the Sigma rule Detect Vikunja Successful OIDC Login Bypassing TOTP to identify successful logins that bypass TOTP.
Deploy the Sigma rule Detect Vikunja OIDC Callback Request to identify potential OIDC login attempts.

Vikunja Link Share Hash Disclosure Leads to Privilege Escalation

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

Vikunja, a self-hosted to-do list application, suffers from a privilege escalation vulnerability due to improper access control in its link sharing feature. The LinkSharing.ReadAll() method allows authenticated users to list all link shares for a project, including their secret hashes. This bypasses the intended LinkSharing.CanRead() check, enabling an attacker with a read-only link share to retrieve hashes for write or admin link shares on the same project. By authenticating with these leaked hashes, an attacker can escalate to full administrative privileges. The vulnerability affects versions of Vikunja prior to 2.2.2. This issue is significant because it allows unauthenticated or low-privileged users to gain complete control over a Vikunja project without requiring valid credentials.

Attack Chain

Attacker obtains a read-only link share URL for a Vikunja project.
Attacker authenticates to the Vikunja API using the read-only link share hash via a POST request to /api/v1/shares/READ_ONLY_HASH/auth, receiving a JWT.
Attacker uses the read-only JWT to make a GET request to /api/v1/projects/PROJECT_ID/shares, listing all link shares associated with the project, including their hashes. This bypasses the intended CanRead() permission check.
The ReadAll() method returns the Hash field, which is used for authentication, for all link shares, including admin shares.
Attacker extracts the hash of an admin-level link share from the API response.
Attacker authenticates to the Vikunja API using the leaked admin link share hash via a POST request to /api/v1/shares/ADMIN_HASH/auth, receiving a new JWT with administrative privileges.
Attacker uses the admin JWT to perform administrative actions such as deleting the project via a DELETE request to /api/v1/projects/PROJECT_ID.
The attacker successfully escalates privileges and gains full control over the Vikunja project, causing disruption or data loss.

Impact

This vulnerability allows an attacker with minimal access (a read-only link share) to gain full administrative control over a Vikunja project. This can lead to data breaches, unauthorized modifications, or complete deletion of project data. The vulnerability poses a high risk, especially for projects that utilize a tiered sharing approach, where read-only shares are publicly available while admin shares are intended for internal use. Successful exploitation grants the attacker the ability to perform any action within the affected project, leading to significant disruption and potential data loss.

Recommendation

Apply the patch or upgrade to Vikunja version 2.2.2 or later to address CVE-2026-33680.
Implement the authorization check in LinkSharing.ReadAll() as described in the advisory to prevent unauthorized access to link share hashes.
Deploy the Sigma rule Vikunja_LinkShare_ReadAll_Hash_Disclosure to detect attempts to list all link shares without proper authorization using the vulnerable ReadAllWeb handler.
Monitor web server logs for unusual API calls to /api/v1/projects/*/shares (where * is the project ID) that may indicate exploitation attempts, and investigate any anomalous activity.