CVE-2026-40103: Authorization Bypass via Method Confusion in Vikunja API

CVE-2026-40103 is a medium-severity authorization bypass vulnerability affecting the open-source task management platform Vikunja. The issue stems from improper implementation of authorization enforcement for scoped API tokens. The application maps API operations to specific token permissions known as scopes.

The core failure involves method confusion in the route authorization logic. Vikunja utilizes a unified URL path for multiple operations, relying on the HTTP method to differentiate the requested action. For example, a single endpoint path manages both reading and deleting a project's background resource.

The vulnerable authorization implementation extracts the URL path and verifies if the token possesses a matching scope string. It critically omits validation of the HTTP method specified in the incoming request. This omission permits an attacker possessing a low-privileged read token to execute high-privileged operations, such as deleting files or altering database records.

The vulnerability is localized within the CanDoAPIRoute() function located in pkg/models/api_routes.go. This function is responsible for determining if a given API token possesses the necessary scopes to access a specific route. The function relies on heuristic parsing to resolve the required permissions.

During execution, the function parses the request URI path into "Group" and "Route" segments. If this parsing yields a non-empty route string, such as background from the /api/v1/projects/:project/background endpoint, the logic verifies only if the token's configured permissions array contains that specific string.

Crucially, this evaluation branch bypasses HTTP method verification entirely. The application design dictates that a GET request requires the projects.background scope, while a DELETE request requires the projects.background_delete scope. Because the parser successfully matches the generic background string derived from the URI path, it halts further evaluation and approves the request.

As a result, any token provisioned with the base projects.background scope is universally authorized for all HTTP methods targeting that specific URI path. The application's intention to enforce granular, method-specific access controls is completely subverted by the parser's short-circuit logic.

The flawed logic in CanDoAPIRoute() relies on string manipulation to infer required permissions rather than querying a definitive routing registry. The exact mechanism relies on splitting the incoming path and confirming the presence of the resulting token within the user's scope array.

The fix introduced in commit 6a0f39b252a81fa4b19dc56dc889183acc9225ae overhauls this component. The patched implementation abandons the heuristic string parsing approach entirely. It replaces the logic with an explicit lookup against the apiTokenRoutes registry, which serves as the authoritative source for endpoint definitions.

In the patched version, the authorization handler iterates through the actual permissions assigned to the API token. For each permission, it queries the routing registry and enforces a strict, two-factor match. The incoming request must precisely align with both the expected path template and the required HTTP method.

The developers also implemented a new unit test, TestAPITokenMethodMatching, to prevent future regressions of this method confusion class. This test explicitly verifies that tokens scoped for one HTTP method are correctly rejected when attempting to utilize a disparate method on the same path.

Exploiting this vulnerability requires specific prerequisites. An attacker must possess an authenticated account with update rights on a target project. This access is necessary to provision the scoped API token required for the attack sequence.

The attacker initiates the exploit by creating an API token configured exclusively with the {"projects":["background"]} scope. This scope is explicitly designed to grant read-only access to project background resources via HTTP GET requests. No write or delete permissions are assigned to this token.

The attacker then constructs an HTTP DELETE request targeting the /api/v1/projects/<project_id>/background endpoint. The attacker authenticates the request by supplying the provisioned token via the Authorization: Bearer <token> HTTP header. The vulnerable application processes the request, matches the background path string, and ignores the DELETE method.

The application returns an HTTP 200 or 204 success status code upon execution. The backend logic deletes the background file from the storage medium and nullifies the corresponding BackgroundFileID field within the database. The attacker successfully executes an unauthorized destructive action using a read-only token.

The exploitation of CVE-2026-40103 results in a direct loss of application integrity. An attacker successfully circumvents granular access controls to alter or destroy specific application resources. The impact is limited to the subset of objects that the provisioned API token can reach based on its path scope.

The vulnerability does not compromise data confidentiality or system availability. The method confusion flaw cannot be leveraged to read arbitrary files, extract unrelated user credentials, or cause a denial of service condition. The scope of impact is isolated to unauthorized state changes on accessible endpoints.

The vulnerability carries a CVSS base score of 4.3, reflecting a Medium severity rating. This score accounts for the low privileges required and the necessity of prior authentication and token provisioning capabilities. The attack vector is strictly network-based and requires no user interaction.

Currently, there is no evidence of active exploitation in the wild. The vulnerability is not cataloged in the CISA Known Exploited Vulnerabilities (KEV) database. A functional proof-of-concept is documented in the official GitHub Security Advisory.

The definitive remediation for CVE-2026-40103 is upgrading Vikunja to version 2.3.0 or later. This release contains the comprehensively refactored CanDoAPIRoute() function that securely enforces HTTP method validation during scoped API token authorization.

Organizations incapable of immediately applying the patch must implement operational workarounds. Administrators must audit existing scoped API tokens and restrict the issuance of new tokens to highly trusted users. Security awareness training should highlight that API token scopes in vulnerable versions encompass broader permissions than explicitly stated.

Defensive monitoring provides a supplementary mitigation layer. Security teams should instrument application logging to identify anomalous HTTP DELETE, PUT, or POST requests originating from scoped service tokens. Network-level defenses, such as Web Application Firewalls (WAFs), are largely ineffective due to their inability to inspect and parse JWT token claims effectively without terminating TLS and possessing the signing keys.