<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:webfeeds="http://webfeeds.org/rss/1.0"><channel><title>Vikunja (&lt;= 2.3.0) - CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/products/vikunja--2.3.0/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Fri, 09 Oct 2026 21:23:47 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/products/vikunja--2.3.0/feed.xml" rel="self" type="application/rss+xml"/><image><url>https://feed.craftedsignal.io/favicon-32x32.png</url><title>CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/</link><width>32</width><height>32</height></image><webfeeds:icon>https://feed.craftedsignal.io/favicon.svg</webfeeds:icon><item><title>Vikunja Permissive CORS Policy Leading to Account Compromise</title><link>https://feed.craftedsignal.io/briefs/2026-10-vikunja-cors-misconfiguration/</link><pubDate>Fri, 09 Oct 2026 21:23:47 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-10-vikunja-cors-misconfiguration/</guid><description>Vikunja versions 2.2.0 through 2.6.0 contain a CORS misconfiguration that implicitly trusts all localhost ports, allowing local attackers to retrieve valid bearer tokens via credentialed cross-origin requests.</description><content:encoded><![CDATA[<p>Vikunja versions 2.2.0 through 2.6.0 are affected by a permissive Cross-Origin Resource Sharing (CORS) policy vulnerability. The application defaults to allowing <code>http://127.0.0.1:*</code> and <code>http://localhost:*</code> as trusted origins. Crucially, when an administrator configures the required <code>service.publicurl</code> for production, this value is appended to - rather than replacing - the existing localhost defaults. Because the application enables <code>Access-Control-Allow-Credentials: true</code> and marks refresh cookies as <code>SameSite=None</code>, any web page running on the victim's local machine (on any port) can send a credentialed request to the Vikunja API. An attacker can exploit this by forcing a victim's browser to perform a cross-origin <code>POST</code> request to the <code>/api/v1/user/token/refresh</code> endpoint, which returns a valid bearer JWT in the response body. The resulting token grants the attacker full administrative or user authority over the victim's account.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>The victim logs into their production Vikunja instance, resulting in a persistent <code>vikunja_refresh_token</code> cookie being set with <code>SameSite=None</code> and <code>Secure</code> attributes.</li>
<li>The victim visits a malicious or compromised website running on any local port (e.g., <code>http://localhost:31337</code>).</li>
<li>The malicious site initiates a <code>fetch()</code> request to the victim's authenticated Vikunja instance, specifically targeting <code>POST /api/v1/user/token/refresh</code>.</li>
<li>The victim's browser, observing the <code>Access-Control-Allow-Credentials: true</code> header returned by the Vikunja server, attaches the <code>vikunja_refresh_token</code> cookie to the cross-origin request.</li>
<li>The Vikunja server validates the cookie, processes the request as a legitimate refresh attempt, and returns a JSON response containing a new valid bearer JWT.</li>
<li>The malicious site receives the response, including the bearer token, due to the permissive <code>Access-Control-Allow-Origin</code> header matching the localhost origin.</li>
<li>The attacker uses the intercepted bearer token to authenticate against the Vikunja API as the victim, achieving full account takeover.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation results in total account compromise, granting an attacker full access to the victim's data, tasks, and administrative functions within the Vikunja instance. The impact is significant for organizations relying on Vikunja for sensitive task management, particularly where administrative or privileged user accounts are targeted via local browser-based vectors.</p>
<h2 id="recommendation">Recommendation</h2>
<p>Detection and mitigation should focus on identifying unauthorized access patterns and hardening the CORS configuration.</p>
<ul>
<li>Upgrade Vikunja to a version where <code>service.publicurl</code> correctly overrides default localhost origins.</li>
<li>Audit web server logs for requests to <code>/api/v1/user/token/refresh</code> originating from unexpected <code>Origin</code> headers, specifically those targeting loopback IP addresses or local ports.</li>
<li>Implement strict CORS policies on the reverse proxy or web server layer in front of Vikunja to explicitly whitelist only authorized production domains and strip unauthorized localhost origins from the <code>Access-Control-Allow-Origin</code> header.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>web-application</category><category>cors</category><category>privilege-escalation</category><category>account-takeover</category><category>denial-of-service</category><category>memory-exhaustion</category><category>vikunja</category><category>migration</category><category>resource-exhaustion</category><category>api</category><category>dos</category><category>web-vulnerability</category><category>credential-access</category><category>vulnerability</category></item></channel></rss>