CVE-2026-33312
Improper Permission Check in Vikunja Allows Background Deletion
Publication date: 2026-03-20
Last updated on: 2026-03-24
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| vikunja | vikunja | From 0.20.2 (inc) to 2.2.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-863 | The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': "CVE-2026-33312 is a broken object-level authorization vulnerability in the Vikunja task management software. It occurs in the DELETE /api/v1/projects/:project/background endpoint, where the system incorrectly checks if a user has read permission (CanRead) instead of update permission (CanUpdate) before allowing deletion of a project's background image."}, {'type': 'paragraph', 'content': "Because of this mistake, any user with read-only access to a project—whether through direct sharing, team membership, link share tokens with read permission, or read-scoped API tokens—can permanently delete the project's background image, even though they should not have permission to do so."}, {'type': 'paragraph', 'content': 'The deletion removes the background file from storage and clears related project fields, causing irreversible data loss. This issue affects versions from 0.20.2 up to but not including 2.2.0, where it has been fixed.'}] [1]
How can this vulnerability impact me? :
This vulnerability allows unauthorized users with only read access to permanently delete background images of projects. This results in unauthorized data destruction and loss of project customization or branding.
If you rely on Vikunja for project management and share projects with read-only users, those users could exploit this flaw to remove background images without permission, potentially disrupting workflows or causing confusion.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability can be detected by monitoring for unauthorized DELETE requests to the endpoint /api/v1/projects/:project/background from users who only have read-only access to the project.'}, {'type': 'paragraph', 'content': 'You can use network traffic inspection tools or API gateway logs to identify such requests.'}, {'type': 'list_item', 'content': 'Use curl or similar tools to test if a read-only user can delete a project background image by sending a DELETE request to /api/v1/projects/{project_id}/background with their authentication token.'}, {'type': 'list_item', 'content': 'Example command to test with curl (replace {project_id} and {token} accordingly):'}, {'type': 'list_item', 'content': 'curl -X DELETE -H "Authorization: Bearer {token}" https://your-vikunja-instance/api/v1/projects/{project_id}/background'}, {'type': 'paragraph', 'content': 'If the request succeeds for a user with only read permissions, the vulnerability is present.'}] [1]
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade Vikunja to version 2.2.0 or later, where this authorization issue has been fixed.
Until the upgrade can be performed, restrict or monitor access to the DELETE /api/v1/projects/:project/background endpoint, ensuring only users with update permissions can invoke it.
Additionally, review project sharing permissions to limit read-only access where possible and audit API tokens and link share tokens to prevent unauthorized deletions.