CVE-2026-111922 in Vikunja
Summary
by MITRE • 10/17/2026
Vikunja from 2.2.0 before 2.7.0 contains a permissive CORS configuration that trusts every localhost and 127.0.0.1 port with credentials, even when service.publicurl is set. Attackers controlling a page on any localhost port can send a credentialed request to the token refresh endpoint and read the returned bearer JWT to take over the logged-in user's account.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/17/2026
The vulnerability in Vikunja versions prior to 2.7.0 stems from an overly permissive Cross-Origin Resource Sharing configuration that fails to properly restrict access based on the configured public URL setting. Specifically, the application trusts requests originating from any localhost address and any port associated with 127.0.0.1 while allowing credentials such as cookies or authorization headers to be included in these cross-origin requests. This misconfiguration effectively bypasses standard browser security mechanisms designed to prevent unauthorized data access between different origins, creating a significant attack surface for local network-based exploits.
From a technical perspective, the flaw allows an attacker who controls a web page hosted on any port of localhost to send credentialed HTTP requests directly to Vikunja's token refresh endpoint. Because the server accepts these credentials from such broad sources, it processes the request and returns sensitive authentication data, specifically the bearer JSON Web Token used for session management. This behavior violates the principle of least privilege by exposing critical security tokens to any local origin rather than restricting them to trusted domains defined in the service configuration. The attacker can then intercept this returned token through JavaScript running on their controlled page due to the browser's same-origin policy being circumvented by the permissive CORS headers.
The operational impact of this vulnerability is severe, as it enables a complete account takeover scenario without requiring user interaction beyond visiting a malicious local webpage or having an existing session active in the victim's browser. By capturing the bearer JWT obtained from the token refresh endpoint, an attacker can authenticate to the Vikunja application as the compromised user. This grants full access to all data associated with that account, including task lists, project details, and any other information stored within the platform. The attack is particularly dangerous because it leverages local execution capabilities, which are often easier for attackers to achieve through phishing or malicious extensions compared to remote exploitation techniques.
This vulnerability aligns with CWE-942, which describes Permissive Cross-Origin Resource Sharing, as well as CWE-359 regarding Exposure of Private Informational Through Web Server Headers when sensitive tokens are exposed via misconfigured responses. In terms of the MITRE ATT&CK framework, this exploit maps to T1078 Valid Accounts and specifically leverages browser-based techniques similar to those found in Local Network Service Scanning or potentially Client-side Scripting if used in conjunction with other vectors for initial access. The core tactic involves stealing valid authentication credentials through a web application vulnerability that undermines the intended isolation between different origins.
To mitigate this risk, organizations running Vikunja versions from 2.2.0 up to but not including 2.7.0 should immediately upgrade to version 2.7.0 or later where these CORS restrictions have been corrected. Until an update is applied, administrators can manually configure the application to restrict allowed origins strictly to their intended public URL rather than accepting wildcards for localhost addresses. It is also advisable to review server configurations to ensure that credentials are not sent with cross-origin requests unless absolutely necessary and properly validated against a whitelist of trusted domains. Regular security audits should include verification of CORS policies to prevent similar misconfigurations in other web applications hosted on the same infrastructure.