GHSA-9RG3-V78M-26Q8
Vulnerability from github – Published: 2026-10-09 20:51 – Updated: 2026-10-09 20:51Summary
API token permission checks only match the HTTP method and route path. The expand query parameter on task read endpoints embeds data from other permission groups (task comments, reactions, time entry counts) without checking whether the token holds those scopes. A token scoped only to tasks read permissions can therefore read task comments and reactions it was explicitly not granted.
Details
models.CanDoAPIRoute (pkg/models/api_routes.go, ~line 440) authorises API tokens purely by comparing method and c.Path() against the routes stored for each granted permission group. The query string is never consulted.
The task read endpoints accept expand:
GET /api/v1/tasks/:task,GET /api/v1/tasks(pkg/models/tasks.goReadOne/ReadAll,pkg/models/task_collection.go)GET /api/v2/tasks/:id,GET /api/v2/tasks,GET /api/v2/projects/:project/tasks(pkg/routes/api/v2/tasks.go,task_collection.go)
Accepted values include comments, comment_count, reactions, time_entries_count. addMoreInfoToTasks (pkg/models/tasks.go, ~line 683) loads and embeds that data. At that layer only a web.Auth (the plain owner user, resolved by auth.GetAuthFromClaims) is available, so the token's scopes cannot be enforced there either.
Result: the tasks_comments, reactions, and time_entries permission groups are advisory for any data reachable through a task expansion.
Impact
A holder of an API token scoped to tasks: [read_one] or tasks: [read_all] (or projects_views_tasks: [read_all]) can read the full bodies of task comments, all reactions, and time entry counts on every task the token owner can access, despite GET /api/v1|v2/tasks/:task/comments and the reactions endpoints correctly returning 401 for the same token.
The leak is limited to data the token owner can already see, and is read-only. The realistic victim is a user who grants a narrowly scoped token to a third-party integration expecting comments to stay private.
Proof of Concept
Against the test fixtures (pkg/db/fixtures/api_tokens.yml, token 1 has {"tasks":["read_all","update"]}, plaintext tk_2eef46f40ebab3304919ab2e7e39993f75f29d2e):
GET /api/v2/tasks/1/comments
Authorization: Bearer tk_2eef46f40ebab3304919ab2e7e39993f75f29d2e
-> 401 {"code":11,"message":"missing, malformed, expired or otherwise invalid token provided"}
GET /api/v2/tasks?expand=comments&filter=id%3D1
Authorization: Bearer tk_2eef46f40ebab3304919ab2e7e39993f75f29d2e
-> 200, response items[0].comments contains the full comment objects
Same behaviour with expand=reactions, and on the v1 endpoints GET /api/v1/tasks?expand=comments / GET /api/v1/tasks/1?expand=comments. Any user-created token with only tasks read permissions reproduces this.
Recommended Fix
Enforce expansions in the single existing choke point, models.CanDoAPIRoute: after the method/path match succeeds, read c.QueryParams()["expand"] and require the token to hold the owning group's read permission for each value, e.g.
comments,comment_count->tasks_comments.read_allreactions->reactions.read_alltime_entries_count->time_entries.read_all
(subtasks, buckets, is_unread are task-level data and need nothing extra.) Doing this in the middleware covers both v1 and v2 without handler or model changes. Add a table-driven test alongside pkg/webtests/api_token_method_matching_test.go asserting a tasks-only token gets 401 with expand=comments and 200 once tasks_comments.read_all is added.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.5.0"
},
"package": {
"ecosystem": "Go",
"name": "code.vikunja.io/api"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "2.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-91983"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-09T20:51:52Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nAPI token permission checks only match the HTTP method and route path. The `expand` query parameter on task read endpoints embeds data from other permission groups (task comments, reactions, time entry counts) without checking whether the token holds those scopes. A token scoped only to `tasks` read permissions can therefore read task comments and reactions it was explicitly not granted.\n\n## Details\n\n`models.CanDoAPIRoute` (`pkg/models/api_routes.go`, ~line 440) authorises API tokens purely by comparing `method` and `c.Path()` against the routes stored for each granted permission group. The query string is never consulted.\n\nThe task read endpoints accept `expand`:\n\n- `GET /api/v1/tasks/:task`, `GET /api/v1/tasks` (`pkg/models/tasks.go` ReadOne/ReadAll, `pkg/models/task_collection.go`)\n- `GET /api/v2/tasks/:id`, `GET /api/v2/tasks`, `GET /api/v2/projects/:project/tasks` (`pkg/routes/api/v2/tasks.go`, `task_collection.go`)\n\nAccepted values include `comments`, `comment_count`, `reactions`, `time_entries_count`. `addMoreInfoToTasks` (`pkg/models/tasks.go`, ~line 683) loads and embeds that data. At that layer only a `web.Auth` (the plain owner user, resolved by `auth.GetAuthFromClaims`) is available, so the token\u0027s scopes cannot be enforced there either.\n\nResult: the `tasks_comments`, `reactions`, and `time_entries` permission groups are advisory for any data reachable through a task expansion.\n\n## Impact\n\nA holder of an API token scoped to `tasks: [read_one]` or `tasks: [read_all]` (or `projects_views_tasks: [read_all]`) can read the full bodies of task comments, all reactions, and time entry counts on every task the token owner can access, despite `GET /api/v1|v2/tasks/:task/comments` and the reactions endpoints correctly returning 401 for the same token.\n\nThe leak is limited to data the token owner can already see, and is read-only. The realistic victim is a user who grants a narrowly scoped token to a third-party integration expecting comments to stay private.\n\n## Proof of Concept\n\nAgainst the test fixtures (`pkg/db/fixtures/api_tokens.yml`, token 1 has `{\"tasks\":[\"read_all\",\"update\"]}`, plaintext `tk_2eef46f40ebab3304919ab2e7e39993f75f29d2e`):\n\n```\nGET /api/v2/tasks/1/comments\nAuthorization: Bearer tk_2eef46f40ebab3304919ab2e7e39993f75f29d2e\n-\u003e 401 {\"code\":11,\"message\":\"missing, malformed, expired or otherwise invalid token provided\"}\n\nGET /api/v2/tasks?expand=comments\u0026filter=id%3D1\nAuthorization: Bearer tk_2eef46f40ebab3304919ab2e7e39993f75f29d2e\n-\u003e 200, response items[0].comments contains the full comment objects\n```\n\nSame behaviour with `expand=reactions`, and on the v1 endpoints `GET /api/v1/tasks?expand=comments` / `GET /api/v1/tasks/1?expand=comments`. Any user-created token with only `tasks` read permissions reproduces this.\n\n## Recommended Fix\n\nEnforce expansions in the single existing choke point, `models.CanDoAPIRoute`: after the method/path match succeeds, read `c.QueryParams()[\"expand\"]` and require the token to hold the owning group\u0027s read permission for each value, e.g.\n\n- `comments`, `comment_count` -\u003e `tasks_comments.read_all`\n- `reactions` -\u003e `reactions.read_all`\n- `time_entries_count` -\u003e `time_entries.read_all`\n\n(`subtasks`, `buckets`, `is_unread` are task-level data and need nothing extra.) Doing this in the middleware covers both v1 and v2 without handler or model changes. Add a table-driven test alongside `pkg/webtests/api_token_method_matching_test.go` asserting a `tasks`-only token gets 401 with `expand=comments` and 200 once `tasks_comments.read_all` is added.",
"id": "GHSA-9rg3-v78m-26q8",
"modified": "2026-10-09T20:51:52Z",
"published": "2026-10-09T20:51:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-9rg3-v78m-26q8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-91983"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/pull/3688"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/commit/077dc4de79ce6f1ab59215a2c7bf9b30423685f2"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-vikunja/vikunja"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/releases/tag/v2.6.0"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/vikunja-before-2.6.0-api-token-scope-bypass-via-expand-parameter"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "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",
"type": "CVSS_V4"
}
],
"summary": "Vikunja: API token scopes bypassed via task expand parameter (comments, reactions, time entry counts)"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.