EUVD-2026-14921
GHSA-jfmm-mjcp-8wq2
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Lifecycle Timeline
4DescriptionGitHub Advisory
Vikunja is an open-source self-hosted task management platform. Prior to version 2.2.1, TaskAttachment.ReadOne() queries attachments by ID only (WHERE id = ?), ignoring the task ID from the URL path. The permission check in CanRead() validates access to the task specified in the URL, but ReadOne() loads a different attachment that may belong to a task in another project. This allows any authenticated user to download or delete any attachment in the system by providing their own accessible task ID with a target attachment ID. Attachment IDs are sequential integers, making enumeration trivial. Version 2.2.1 patches the issue.
AnalysisAI
Vikunja, an open-source self-hosted task management platform, contains an insecure direct object reference (IDOR) vulnerability that allows any authenticated user to access or delete attachments belonging to other users' tasks. The vulnerability affects all versions prior to 2.2.1, enabling attackers to enumerate and download attachments by combining their own valid task ID with sequential attachment IDs. With a CVSS score of 8.1 (High severity), this represents a significant confidentiality and integrity risk, though no evidence of active exploitation (KEV) or public proof-of-concept has been reported.
Technical ContextAI
The vulnerability affects Vikunja task management platform (CPE: cpe:2.3:a:go-vikunja:vikunja) and stems from CWE-639 (Authorization Bypass Through User-Controlled Key). The root cause lies in the TaskAttachment.ReadOne() function, which queries attachments using only the attachment ID parameter without validating that the attachment belongs to the task specified in the URL path. While the CanRead() permission check validates access to the task in the URL, the subsequent ReadOne() operation retrieves attachments based solely on attachment ID, creating a classic IDOR vulnerability. Because attachment IDs are sequential integers rather than unpredictable tokens, attackers can trivially enumerate all attachments in the system by iterating through ID values.
RemediationAI
Upgrade Vikunja to version 2.2.1 or later immediately, as documented in the official security advisory at https://github.com/go-vikunja/vikunja/security/advisories/GHSA-jfmm-mjcp-8wq2 and release changelog at https://vikunja.io/changelog/vikunja-v2.2.2-was-released. Version 2.2.1 patches the issue by properly validating that attachment IDs belong to the task specified in the URL path before allowing read or delete operations. As a temporary mitigation until patching is possible, consider restricting user registration to trusted users only, implementing enhanced logging to detect suspicious attachment access patterns, and reviewing access logs for sequential attachment ID requests that may indicate exploitation attempts. No effective workaround exists that fully addresses the vulnerability without upgrading.
Same technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: High| Product | Status |
|---|---|
| openSUSE Leap 15.6 | Fixed |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Fixed |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Fixed |
| openSUSE Leap 15.5 | Fixed |
Share
External POC / Exploit Code
Leaving vuln.today