Vikunja CVE-2026-111922

Requires that cors.enable remains true (the default) and that cors.origins retains its default localhost/127.0.0.1 port wildcards - per the advisory these are APPENDED to, not replaced by, the mandatory service.publicurl, so even a fully configured production deployment keeps trusting them and there is no supported configuration that drops them. The victim must be authenticated to Vikunja (holding a valid vikunja_refresh_token cookie) and must load attacker-controlled content served from some port on their own localhost or 127.0.0.1. Limiting factors that reduce real-world risk: the attacker must be able to serve a page on the victim's local machine (a local foothold, rogue/compromised local app, or malicious local dev server), the victim must have a live session, and the attack depends on the browser honoring the credentialed cross-origin response - it is not exploitable directly from an arbitrary external internet origin.

This is a genuine but conditional account-takeover flaw, not a mass-exploitable internet-facing RCE. The input provides a CVSS 4.0 vector (AV:L/AC:L/AT:P/PR:N/UI:P, VC:H/VI:H) scoring 7.2 (HIGH), and CWE-942 (permissive cross-domain policy) matches the described CORS misconfiguration precisely. Key risk-moderating signals: AV:L and AT:P indicate the attack is NOT straightforward remote exploitation - the malicious origin must itself be a localhost/127.0.0.1 port on the victim's own machine, and UI:P requires the logged-in victim to load that attacker-controlled page. No EPSS score was provided, and there is no CISA KEV listing and no public exploit code referenced, so exploitation status is: no public exploit identified at time of analysis. The flaw was reported by VulnCheck (a credible vulnerability-intelligence source) and is documented in a detailed vendor GHSA advisory with source-code line references, so the technical mechanism is well-corroborated even though real-world exploitation is unproven. Net: credible, well-documented, and high-impact if triggered (full JWT/account takeover), but the localhost-origin prerequisite makes it targeted rather than wormable - prioritize patching for multi-user/shared or hostile-local-process environments over treating it as an emergency internet-exposure bug.

A user is logged into their self-hosted Vikunja instance (holding a valid vikunja_refresh_token cookie) and is lured to, or already runs, a malicious page served from any port on their own localhost/127.0.0.1 - for example a rogue local dev server or a compromised local application. That page issues a single credentialed fetch() to Vikunja's token refresh endpoint; because the default CORS policy trusts every localhost origin with Access-Control-Allow-Credentials: true, the browser returns the fresh bearer JWT in the response body, which the attacker's script reads and uses to take over the account. No public proof-of-concept was referenced in the provided data, but the vendor advisory describes the full working chain.