CVE-2026-40103

| EUVD-2026-21494 MEDIUM
2026-04-10 https://github.com/go-vikunja/vikunja GHSA-v479-vf79-mg83
4.3
CVSS 3.1
Share

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
Low
Availability
None

Lifecycle Timeline

4
EUVD ID Assigned
Apr 10, 2026 - 16:00 euvd
EUVD-2026-21494
Analysis Generated
Apr 10, 2026 - 16:00 vuln.today
Patch Released
Apr 10, 2026 - 16:00 nvd
Patch available
CVE Published
Apr 10, 2026 - 15:36 nvd
MEDIUM 4.3

Description

### Summary Vikunja's scoped API token enforcement for custom project background routes is method-confused. A token with only `projects.background` can successfully delete a project background, while a token with only `projects.background_delete` is rejected. This is a scoped-token authorization bypass. ### Details I verified this locally on commit `c5450fb55f5192508638cbb3a6956438452a712e`. Relevant code paths: * `pkg/models/api_routes.go` * `pkg/routes/routes.go` * `pkg/modules/background/handler/background.go` Route registration exposes separate permissions for the same path: * `GET /api/v1/projects/:project/background` -> `projects.background` * `DELETE /api/v1/projects/:project/background` -> `projects.background_delete` At enforcement time, `CanDoAPIRoute()` falls back to the parent group and reconstructs the child permission from the path segments only. For the DELETE request, that becomes `background`, so the matcher accepts any token containing `projects.background` without re-checking the HTTP method or matching the stored route detail. This matters because `RemoveProjectBackground()` is a real destructive operation: * It checks project update rights. * It deletes the background file if present. * It clears the project's `BackgroundFileID`. ### PoC 1. Log in as a user who can update a project that already has a background. 2. Create an API token with only: `{"projects":["background"]}` 3. Send: `DELETE /api/v1/projects/<project_id>/background` `Authorization: Bearer <token>` 4. Observe that the request succeeds and the project background is removed. **For comparison:** 1. Create an API token with only: `{"projects":["background_delete"]}` 2. Repeat the same DELETE request. 3. Observe that the request is rejected with `401 Unauthorized`. I confirmed this locally with three validations: 1. `/api/v1/routes` advertises both `background` and `background_delete`. 2. The matcher unit test proves `CanDoAPIRoute()` accepts DELETE for `background`. 3. The webtest proves a real API token with only `background` successfully deletes the background. ### Impact Scoped API tokens can exceed their intended capability. A token intended for project background access can delete project backgrounds, which weakens the trust model for automation and third-party integrations that rely on narrowly scoped tokens. The attacker needs a valid API token created by a user who has update rights on the target project, but the token itself only needs the weaker `projects.background` permission.

Analysis

Vikunja's scoped API token enforcement for project background routes contains a method-confusion authorization bypass allowing tokens with only `projects.background` permission to delete project backgrounds despite lacking the `projects.background_delete` permission. This enables authenticated attackers to perform unintended destructive operations on projects they have update access to, weakening the permission model for narrowly scoped API tokens used in automation and third-party integrations. …

Sign in for full analysis, threat intelligence, and remediation guidance.

Priority Score

22
Low Medium High Critical
KEV: 0
EPSS: +0.0
CVSS: +22
POC: 0

Share

CVE-2026-40103 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy