{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/products/vikunja/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Vikunja"],"_cs_severities":["critical"],"_cs_tags":["vikunja","idor","privilege-escalation","data-breach"],"_cs_type":"advisory","_cs_vendors":["Vikunja"],"content_html":"\u003cp\u003eAn 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 \u003ccode\u003eReadAll\u003c/code\u003e 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 \u003ccode\u003eReadOne\u003c/code\u003e/\u003ccode\u003eGetTaskAttachment\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker obtains a URL for a public link share (e.g., via social engineering or accidental exposure).\u003c/li\u003e\n\u003cli\u003eAttacker authenticates to the Vikunja API using the read-only link share hash via \u003ccode\u003ePOST /shares/{hash}/auth\u003c/code\u003e to obtain a JWT.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates all link shares for the project associated with the initial share using \u003ccode\u003eGET /projects/{id}/shares\u003c/code\u003e. The API discloses all share hashes, including those with admin privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates using an admin-level share hash via \u003ccode\u003ePOST /shares/{admin_hash}/auth\u003c/code\u003e to escalate privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies an accessible task ID within the project using \u003ccode\u003eGET /projects/{id}/tasks\u003c/code\u003e. This task is only used to bypass initial checks.\u003c/li\u003e\n\u003cli\u003eThe attacker exploits the attachment IDOR by sending requests like \u003ccode\u003eGET /tasks/{accessible_task}/attachments/{1..N}\u003c/code\u003e 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.\u003c/li\u003e\n\u003cli\u003eThe attacker downloads attachments from any project by iterating through attachment IDs.\u003c/li\u003e\n\u003cli\u003eIf the attacker escalated to an admin share, they can delete attachments from other projects using \u003ccode\u003eDELETE /tasks/{accessible_task}/attachments/{TARGET_ATTACHMENT_ID}\u003c/code\u003e causing data loss.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the recommended fixes as outlined in the advisory (\u003ca href=\"https://github.com/advisories/GHSA-2pv8-4c52-mf8j\"\u003ehttps://github.com/advisories/GHSA-2pv8-4c52-mf8j\u003c/a\u003e). Specifically, ensure that the \u003ccode\u003eHash\u003c/code\u003e field is cleared in \u003ccode\u003eReadAll\u003c/code\u003e responses for link shares.\u003c/li\u003e\n\u003cli\u003eImplement the suggested fix for the attachment IDOR by verifying task ownership in the \u003ccode\u003eReadOne\u003c/code\u003e method within \u003ccode\u003epkg/models/task_attachment.go\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule to detect suspicious attachment downloads across projects based on sequential attachment ID enumeration.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule to detect link share enumeration, as this is the initial step in the attack chain.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for unusual patterns of API requests, particularly to the \u003ccode\u003e/projects/{id}/shares\u003c/code\u003e and \u003ccode\u003e/tasks/{accessible_task}/attachments/{1..N}\u003c/code\u003e endpoints.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-30T12:00:00Z","date_published":"2024-01-30T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-vikunja-idor/","summary":"Chained authorization flaws in Vikunja allow an unauthenticated attacker to download and delete all file attachments across all projects by disclosing share hashes and exploiting cross-project attachment access.","title":"Vikunja Unauthenticated Instance-Wide Data Breach via Link Share and IDOR","url":"https://feed.craftedsignal.io/briefs/2024-01-vikunja-idor/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Vikunja"],"_cs_severities":["high"],"_cs_tags":["vikunja","totp","oidc","bypass","cve-2026-34727"],"_cs_type":"advisory","_cs_vendors":["Vikunja"],"content_html":"\u003cp\u003eVikunja, 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 \u003ccode\u003eEmailFallback\u003c/code\u003e 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 (\u003ccode\u003epkg/modules/auth/openid/openid.go\u003c/code\u003e) issuing a JWT without verifying TOTP status.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies a Vikunja instance with OIDC enabled and \u003ccode\u003eEmailFallback\u003c/code\u003e set to \u003ccode\u003etrue\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a valid local user with TOTP enabled and determines the user's email address.\u003c/li\u003e\n\u003cli\u003eThe attacker creates or compromises an account on the configured OIDC provider that uses the same email address as the target Vikunja user.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates the OIDC login flow to the Vikunja instance.\u003c/li\u003e\n\u003cli\u003eThe OIDC provider authenticates the attacker using their compromised or created account.\u003c/li\u003e\n\u003cli\u003eVikunja's OIDC callback handler (\u003ccode\u003epkg/modules/auth/openid/openid.go\u003c/code\u003e) matches the email address from the OIDC provider to the local user.\u003c/li\u003e\n\u003cli\u003eThe callback handler incorrectly issues a JWT without performing TOTP verification, bypassing the second factor.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the received JWT to authenticate to the Vikunja API and gains full access to the user's account.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the recommended fix by adding a TOTP check in the OIDC callback before issuing the JWT, as described in the advisory.\u003c/li\u003e\n\u003cli\u003eDisable the \u003ccode\u003eEmailFallback\u003c/code\u003e option in the Vikunja OIDC configuration until the patch is applied.\u003c/li\u003e\n\u003cli\u003eMonitor Vikunja logs for unusual OIDC login activity, specifically successful OIDC logins for users who also have local accounts with TOTP enabled.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Vikunja Successful OIDC Login Bypassing TOTP\u003c/code\u003e to identify successful logins that bypass TOTP.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Vikunja OIDC Callback Request\u003c/code\u003e to identify potential OIDC login attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-vikunja-totp-bypass/","summary":"Vikunja version 2.2.2 and earlier has a two-factor authentication bypass vulnerability via the OIDC login path, where TOTP enrollment is ignored when a local user with TOTP enabled is matched via OIDC email fallback, allowing attackers with a matching email address in the OIDC provider to gain access without the second factor.","title":"Vikunja TOTP Two-Factor Authentication Bypass via OIDC Login","url":"https://feed.craftedsignal.io/briefs/2024-01-vikunja-totp-bypass/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Vikunja"],"_cs_severities":["high"],"_cs_tags":["vikunja","privilege-escalation","credential-access"],"_cs_type":"advisory","_cs_vendors":["Vikunja"],"content_html":"\u003cp\u003eVikunja, a self-hosted to-do list application, suffers from a privilege escalation vulnerability due to improper access control in its link sharing feature. The \u003ccode\u003eLinkSharing.ReadAll()\u003c/code\u003e method allows authenticated users to list all link shares for a project, including their secret hashes. This bypasses the intended \u003ccode\u003eLinkSharing.CanRead()\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker obtains a read-only link share URL for a Vikunja project.\u003c/li\u003e\n\u003cli\u003eAttacker authenticates to the Vikunja API using the read-only link share hash via a POST request to \u003ccode\u003e/api/v1/shares/READ_ONLY_HASH/auth\u003c/code\u003e, receiving a JWT.\u003c/li\u003e\n\u003cli\u003eAttacker uses the read-only JWT to make a GET request to \u003ccode\u003e/api/v1/projects/PROJECT_ID/shares\u003c/code\u003e, listing all link shares associated with the project, including their hashes. This bypasses the intended \u003ccode\u003eCanRead()\u003c/code\u003e permission check.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eReadAll()\u003c/code\u003e method returns the \u003ccode\u003eHash\u003c/code\u003e field, which is used for authentication, for all link shares, including admin shares.\u003c/li\u003e\n\u003cli\u003eAttacker extracts the hash of an admin-level link share from the API response.\u003c/li\u003e\n\u003cli\u003eAttacker authenticates to the Vikunja API using the leaked admin link share hash via a POST request to \u003ccode\u003e/api/v1/shares/ADMIN_HASH/auth\u003c/code\u003e, receiving a new JWT with administrative privileges.\u003c/li\u003e\n\u003cli\u003eAttacker uses the admin JWT to perform administrative actions such as deleting the project via a DELETE request to \u003ccode\u003e/api/v1/projects/PROJECT_ID\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker successfully escalates privileges and gains full control over the Vikunja project, causing disruption or data loss.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the patch or upgrade to Vikunja version 2.2.2 or later to address CVE-2026-33680.\u003c/li\u003e\n\u003cli\u003eImplement the authorization check in \u003ccode\u003eLinkSharing.ReadAll()\u003c/code\u003e as described in the advisory to prevent unauthorized access to link share hashes.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eVikunja_LinkShare_ReadAll_Hash_Disclosure\u003c/code\u003e to detect attempts to list all link shares without proper authorization using the vulnerable \u003ccode\u003eReadAllWeb\u003c/code\u003e handler.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for unusual API calls to \u003ccode\u003e/api/v1/projects/*/shares\u003c/code\u003e (where * is the project ID) that may indicate exploitation attempts, and investigate any anomalous activity.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-vikunja-privesc/","summary":"The Vikunja application is vulnerable to privilege escalation, where the LinkSharing.ReadAll() method permits authenticated users to list all link shares, including secret hashes, without proper authorization checks, allowing an attacker with a read-only link share to escalate to full admin access.","title":"Vikunja Link Share Hash Disclosure Leads to Privilege Escalation","url":"https://feed.craftedsignal.io/briefs/2024-01-vikunja-privesc/"}],"language":"en","title":"CraftedSignal Threat Feed - Vikunja","version":"https://jsonfeed.org/version/1.1"}