Skip to content

Vikunja: Scoped API tokens with projects.background permission can delete project backgrounds

Moderate severity GitHub Reviewed Published Apr 9, 2026 in go-vikunja/vikunja • Updated Apr 10, 2026

Package

gomod code.vikunja.io/api (Go)

Affected versions

< 2.3.0

Patched versions

2.3.0

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.

References

@kolaente kolaente published to go-vikunja/vikunja Apr 9, 2026
Published to the GitHub Advisory Database Apr 10, 2026
Reviewed Apr 10, 2026
Published by the National Vulnerability Database Apr 10, 2026
Last updated Apr 10, 2026

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
Low
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N

EPSS score

Weaknesses

Use of Password Hash Instead of Password for Authentication

The product records password hashes in a data store, receives a hash of a password from a client, and compares the supplied hash to the hash obtained from the data store. Learn more on MITRE.

Incorrect Authorization

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. Learn more on MITRE.

CVE ID

CVE-2026-40103

GHSA ID

GHSA-v479-vf79-mg83

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.