CVE-2026-33678 Overview
CVE-2026-33678 is a critical Insecure Direct Object Reference (IDOR) vulnerability in Vikunja, an open-source self-hosted task management platform. Prior to version 2.2.1, the TaskAttachment.ReadOne() function 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 flaw 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. Since attachment IDs are sequential integers, enumeration is trivial.
Critical Impact
Authenticated attackers can download or delete arbitrary attachments across all projects, leading to unauthorized data access and potential data loss system-wide.
Affected Products
- Vikunja versions prior to 2.2.1
- All self-hosted Vikunja deployments running vulnerable versions
Discovery Timeline
- 2026-03-24 - CVE CVE-2026-33678 published to NVD
- 2026-03-25 - Last updated in NVD database
Technical Details for CVE-2026-33678
Vulnerability Analysis
This vulnerability is classified as CWE-639 (Authorization Bypass Through User-Controlled Key), commonly known as an Insecure Direct Object Reference (IDOR). The core issue lies in a mismatch between the authorization check and the data retrieval logic within Vikunja's attachment handling system.
When a user requests an attachment, the application performs two separate operations: first, it validates whether the user has permission to access the task specified in the URL path through the CanRead() function; second, it retrieves the attachment data through ReadOne(). However, these two operations reference different identifiers—CanRead() uses the task ID from the URL, while ReadOne() only uses the attachment ID parameter, completely disregarding the task context.
This architectural flaw creates an authorization bypass where an attacker can specify a task they legitimately have access to in the URL path (passing the CanRead() check), while simultaneously specifying an attachment ID belonging to a completely different task or project (which ReadOne() will happily retrieve).
Root Cause
The root cause stems from inconsistent parameter usage between the authorization and data access layers. The ReadOne() function constructs its database query using only the attachment ID (WHERE id = ?) without including the task ID as an additional constraint. This means any valid attachment ID will be returned regardless of which task was specified in the authorization check. The sequential nature of attachment IDs further exacerbates this issue by making it trivial to enumerate all attachments in the system.
Attack Vector
The attack can be executed over the network by any authenticated user with access to at least one task containing attachments. An attacker would:
- Obtain a valid task ID from a project they have legitimate access to
- Enumerate attachment IDs by incrementing integer values (starting from 1)
- Construct requests using their accessible task ID in the URL path but substituting different attachment IDs
- Successfully download or delete attachments belonging to tasks in other projects they should not have access to
The vulnerability requires low privilege (any authenticated user) and no user interaction, making exploitation straightforward once an attacker has authenticated to the platform.
Detection Methods for CVE-2026-33678
Indicators of Compromise
- Unusual patterns of attachment access requests with sequential or enumerated attachment IDs
- Users accessing attachments from tasks they don't normally interact with
- Sudden increases in attachment download or deletion activity from a single user account
- HTTP request logs showing mismatched task IDs and attachment IDs in API calls
Detection Strategies
- Monitor API endpoints related to attachment operations (/api/v1/tasks/*/attachments/*) for anomalous access patterns
- Implement logging that correlates task IDs in URL paths with the actual task ownership of retrieved attachments
- Set up alerts for users accessing attachments at rates significantly higher than normal usage patterns
- Audit trails should capture both the requested task ID and the actual attachment's parent task for comparison
Monitoring Recommendations
- Enable detailed access logging for all attachment-related API endpoints
- Deploy application-layer monitoring to detect sequential ID enumeration attempts
- Review authentication logs for unusual session activity preceding attachment access spikes
- Implement rate limiting on attachment download endpoints to slow enumeration attacks
How to Mitigate CVE-2026-33678
Immediate Actions Required
- Upgrade Vikunja to version 2.2.1 or later immediately
- Review audit logs for signs of unauthorized attachment access prior to patching
- Consider temporarily disabling attachment functionality if immediate upgrade is not possible
- Reset attachment access permissions and verify data integrity after patching
Patch Information
The vulnerability is resolved in Vikunja version 2.2.1. The fix modifies the ReadOne() function to include the task ID in the database query, ensuring that attachments can only be retrieved when they belong to the task specified in the URL path. This ensures the authorization check and data retrieval operate on the same object context.
For detailed patch information, refer to the GitHub Security Advisory and the Vikunja Release Changelog.
Workarounds
- Restrict network access to Vikunja instances to trusted networks only until patching is complete
- Implement additional authentication controls or access restrictions at the reverse proxy level
- Monitor and alert on attachment-related API calls with enhanced logging
- Consider disabling public or external access to the application temporarily
# Vikunja upgrade example
# Stop the running Vikunja instance
systemctl stop vikunja
# Download and install the patched version (2.2.1 or later)
wget https://dl.vikunja.io/vikunja/2.2.1/vikunja-2.2.1-linux-amd64.zip
unzip vikunja-2.2.1-linux-amd64.zip -d /opt/vikunja
# Restart the service
systemctl start vikunja
# Verify the version
vikunja version
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
