GHSA-7jp5-298q-jg98
HIGHVikunja: Stored XSS via Unsanitized SVG Attachment Upload Leads to Token Exposure
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
code.vikunja.io/apiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Details The application allows users to upload SVG files as task attachments. SVG is an XML-based format that supports JavaScript execution through elements such as <script> tags or event handlers like onload.
The application does not sanitize SVG content before storing it. When the uploaded SVG file is accessed via its direct URL, it is rendered inline in the browser under the application's origin. As a result, embedded JavaScript executes in the context of the authenticated user.
Because the authentication token is stored in localStorage, it is accessible via JavaScript and can be retrieved by a malicious payload.
Key security issues identified:
No server-side sanitization of SVG content. SVG attachments are rendered inline instead of being forced as a download. Embedded JavaScript within SVG files is allowed to execute. Authentication tokens stored in localStorage are accessible to client-side scripts.
PoC
Tested Environment
[ ] Application version: 1.1.0 [ ] Deployment type: Self-hosted
Steps to Reproduce
- Log in to an account.
- Go to Projects and Create a new task or open an existing task.
- Upload the following SVG file as an attachment:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<svg
onload="alert(localStorage.getItem('token'))"
xmlns="http://www.w3.org/2000/svg">
</svg>
- After uploading ,save the Task and open the project , copy the direct URL of the attachment.
- Open the attachment URL in a new browser tab.
- The embedded JavaScript executes immediately and displays the authentication token stored in
localStorage.
This confirms that arbitrary JavaScript embedded in an uploaded SVG file executes within the application's context.
Impact
This vulnerability is classified as Stored Cross-Site Scripting (XSS).
Potential impact includes:
Execution of arbitrary JavaScript in a victim’s browser. Exposure of authentication tokens. Potential account takeover. Ability to perform authenticated actions on behalf of the victim. Possible privilege escalation if higher-privileged users open the malicious attachment. Any authenticated user who accesses a malicious SVG attachment may be affected.
Recommendations
This vulnerability can be mitigated by implementing proper server-side sanitization of SVG uploads and preventing inline execution of uploaded files.
Specifically:
- Sanitize all uploaded SVG files to remove <script> elements, event handlers (e.g., onload), and other executable content.
- Serve attachments with Content-Disposition: attachment to prevent inline rendering.
- Implement a strict Content Security Policy (CSP) to block script execution within uploaded files.
- Store authentication tokens in HttpOnly, Secure cookies instead of localStorage to prevent JavaScript access.
- Applying these controls will prevent stored XSS via SVG uploads and significantly reduce the risk of token exposure and account takeover.
Attachment Stored XSS Proof of concept.pdf
A fix is available at https://github.com/go-vikunja/vikunja/releases/tag/v2.0.0.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | code.vikunja.io/api | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for code.vikunja.io/api. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Remediation status
No patched version of code.vikunja.io/api has shipped for GHSA-7jp5-298q-jg98 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-7jp5-298q-jg98 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-7jp5-298q-jg98. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-7jp5-298q-jg98 in your dependencies?
O3 detects GHSA-7jp5-298q-jg98 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.