5.4

CVSS Score

3.1

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

CVE-2026-40103

CVE-2026-40103: Vikunja: Scoped API tokens with projects.background permission can delete project backgrounds

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

Log in as a user who can update a project that already has a background.
Create an API token with only: {"projects":["background"]}
Send: DELETE /api/v1/projects/<project_id>/background Authorization: Bearer <token>
Observe that the request succeeds and the project background is removed.

For comparison:

Create an API token with only: {"projects":["background_delete"]}
Repeat the same DELETE request.
Observe that the request is rejected with 401 Unauthorized.

I confirmed this locally with three validations:

/api/v1/routes advertises both background and background_delete.
The matcher unit test proves CanDoAPIRoute() accepts DELETE for background.
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.

(GitHub Advisory)

Miggo Vulnerability Database

→

CVE-2026-40103

CVE-2026-40103:

5.4

CVSS Score

3.1

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
code.vikunja.io/api	go	< 2.3.0	2.3.0

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability is an authorization bypass in Vikunja's API token handling. The core of the issue lies in the models.CanDoAPIRoute function, which was responsible for checking if an API token had the necessary permissions to access a given API route.

The original implementation of CanDoAPIRoute incorrectly determined permissions. It would parse the request URL to guess the required permission scope, but it failed to consider the HTTP method (e.g., GET, POST, DELETE). This created a "method confusion" vulnerability.

For the specific case of project backgrounds, two routes were defined for the same URL path but with different HTTP methods and permissions:

GET /api/v1/projects/:project/background required projects.background permission.
DELETE /api/v1/projects/:project/background required projects.background_delete permission.

Because of the flaw in CanDoAPIRoute, when a DELETE request was made, the function only checked for a permission matching the path, which it derived as background. A token holding the projects.background permission would therefore be granted access, allowing it to call the handler.RemoveProjectBackground function and delete the project background, even though it lacked the explicit projects.background_delete permission.

The fix in commit 6a0f39b252a81fa4b19dc56dc889183acc9225ae completely rewrites models.CanDoAPIRoute. The new logic iterates through the permissions granted to the token and strictly checks both the HTTP method and the URL path against the details registered for each permission, eliminating the method confusion and ensuring that API tokens can only access the exact routes they are authorized for.

Therefore, the key vulnerable function is models.CanDoAPIRoute, and handler.RemoveProjectBackground is the function that would be observed in a runtime profile during the exploitation of this vulnerability, as it's the endpoint that performs the unauthorized destructive action.

Vulnerable functions

models.CanDoAPIRoute

pkg/models/api_routes.go

This function contained a flawed authorization logic that did not properly check the HTTP method for API token permissions. It derived the required permission from the URL path, allowing a token with a GET permission (`projects.background`) to perform a DELETE operation on the same endpoint, bypassing the intended security control.

handler.RemoveProjectBackground

pkg/modules/background/handler/background.go

This function is the handler that performs the destructive action of deleting a project's background. Due to the authorization bypass in `models.CanDoAPIRoute`, an attacker with a token only granted `projects.background` permission (for viewing) can successfully call this function and delete the background, which should require the `projects.background_delete` permission.

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

Generate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance

Get WAF rules

WAF Protection Rules

WAF Rule

W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.

Reasoning

*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.