GHSA-8wvg-r2j4-3737 GO-2026-6723
Vikunja: Assignee email addresses disclosed to read-only project members via the task assignees endpoint
- Severity
- 0.0 / 10
- Medium · CVSS 4.0
- Exploit chance (EPSS)
- —
- No score published
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
- Fix
2.6.0- Upgrade code.vikunja.io/api to this version or later
Description
Summary
TaskAssginee.ReadAll returns assignee user objects without blanking the Email field, disclosing assignee email addresses to any read-only project member. Every sibling path that returns user objects obfuscates the email; this one does not.
Details
pkg/models/task_assignees.go (~lines 306-344) does Select("users.*") and returns the result directly. User.Email is json:"email,omitempty", so a non-empty value always serializes. The endpoint gates on task.CanRead, so a read-only member passes. Sibling paths blank the field: pkg/models/tasks.go:530, pkg/models/project_users.go:216, pkg/models/teams.go:177, pkg/models/label_task.go:312, pkg/models/task_attachment.go:511. The omission here reads as an oversight, not a decision.
The same file's getRawTaskAssigneesForTasks (~line 56) also selects users.* but is safe because its only caller (addAssigneesToTasks) blanks the email afterwards.
PoC (verified at runtime against v2.5.0, v1 and v2)
GET /api/v1/tasks/{id}/assignees (reader with permission:0)
-> [{"id":37,"username":"...","email":"assignee+SECRET@example.test", ...}]
Same leak on GET /api/v2/tasks/{id}/assignees (routes through the identical model method). Contrast: GET /api/v1/projects/{id}/projectusers and the project task-embed both return the same users with no email.
Impact
Disclosure of assignees' email addresses to users who should only see usernames. Read-only.
Fix
Blank Email on each returned user in TaskAssginee.ReadAll before returning, matching the sibling paths. Covers v1 and v2 at once.
Affected versions
Go
| Package | Vulnerable | Fixed in |
|---|---|---|
| code.vikunja.io/api | < 2.6.0 |
2.6.0 |
| code.vikunja.io/api | all versions |
No fix yet |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
code.vikunja.io/api Go → 2.6.0
- go
go get code.vikunja.io/api@v2.6.0 && go mod tidy
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- None
- Privileges required
- Low
- User interaction
- None
- Confidentiality (vulnerable system)
- Low
- Integrity (vulnerable system)
- None
- Availability (vulnerable system)
- None
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
Weakness
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
How to prevent it
- Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
References
Packages
Other links
Timeline
- Published
- Last updated by the source
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-m687-p538-r5hp Vikunja: Permissive Cross-domain Security Policy trusts every localhost origin which should not be trusted | Medium | Also affects code.vikunja.io/api |
| GHSA-fmmf-xq98-g327 Vikunja: Write-level project members can delete admin-tier link shares through an unloaded permission check | Medium | Also affects code.vikunja.io/api |
| GHSA-pjr3-86v4-5p7w Vikunja: Explicit lower-permission share on a sub-project is silently overridden by an inherited parent permission (broken access control / privilege-management regression in v2.6.0) | Medium | Also affects code.vikunja.io/api |
| GHSA-hjx8-qv73-f7cm Vikunja: Webhooks and link shares survive every revocation path, so a removed collaborator keeps a live feed | High | Also affects code.vikunja.io/api |
| GHSA-fprf-r6rv-xg99 Vikunja: Saved filter creation with an empty filter string recalculates task positions across all tenants | Medium | Also affects code.vikunja.io/api |
| GHSA-4hv6-xc92-j86g Vikunja: WebSocket authentication ignores server-side session state, so revoked sessions keep receiving live pushes | High | Also affects code.vikunja.io/api |
| GHSA-w2ch-4xgr-22ww Vikunja: Task relation deletion does not check read access to the other task, allowing cross-project relation removal | Low | Also affects code.vikunja.io/api |
| GHSA-3hc7-r24j-rpwc Vikunja: Cross-project task disclosure through subtask expansion | Medium | Also affects code.vikunja.io/api |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor