CVE-2026-9279: Logseq Shell Command Injection RCE Flaw

CVE-2026-9279 Overview

CVE-2026-9279 affects Logseq, an open-source knowledge management and note-taking application built on Electron. The vulnerability exists in an Inter-Process Communication (IPC) handler that allows the renderer process to execute shell commands. An allowlist restricts which command binaries can run, including git, pandoc, and grep. However, the argument string is concatenated with the command and passed to child_process.spawn with the shell: true option. Shell metacharacters embedded in arguments bypass the allowlist and execute arbitrary commands. Version v0.10.15 is confirmed vulnerable, and the issue has not been addressed by a patch.

Critical Impact
An attacker with JavaScript execution in the renderer, via cross-site scripting (XSS) or a malicious plugin, can achieve arbitrary command execution with the privileges of the Logseq process.

Affected Products

Logseq v0.10.15 (confirmed vulnerable)
Other Logseq versions (status unknown, no patch available)
Logseq desktop application (Electron-based)

Discovery Timeline

2026-06-09 - CVE-2026-9279 published to NVD
2026-06-09 - Last updated in NVD database

Technical Details for CVE-2026-9279

Vulnerability Analysis

The vulnerability is a command injection flaw classified as [CWE-78]: Improper Neutralization of Special Elements used in an OS Command. Logseq's Electron main process exposes an IPC handler intended to run a fixed set of utility binaries on behalf of the renderer. The allowlist enforces only the command name. The arguments accompanying that command receive no sanitization before reaching the shell.

Because child_process.spawn is invoked with shell: true, the full command line passes through /bin/sh or cmd.exe. Metacharacters such as ;, &&, |, and backticks change the meaning of the command line. An attacker who runs JavaScript in the renderer can call the IPC channel with a permitted command name and a weaponized argument string. The shell then executes any payload appended to that string.

Root Cause

The root cause is the combination of two unsafe design choices. The IPC handler trusts argument content after validating only the command binary. Spawning the child process with shell: true removes the argument-array boundary that normally prevents shell interpretation. Together, these allow shell metacharacter injection through a parameter the allowlist never inspects.

Attack Vector

Exploitation requires JavaScript execution inside the Logseq renderer process. Two practical paths exist. A cross-site scripting flaw in rendered Markdown, an embedded iframe, or a third-party block could deliver attacker-controlled JavaScript. Alternatively, a malicious Logseq plugin installed by the user gains the renderer context required to call the IPC handler. Once code runs in the renderer, the attacker invokes the IPC channel with an allowlisted binary such as git and appends shell metacharacters to the argument string. The injected commands execute with the privileges of the Logseq process on the host operating system.

// Example exploitation pattern (described, not executed)
// Renderer-side JavaScript invokes the IPC handler with an
// allowlisted command and an argument containing shell metacharacters.
// command: "git"
// args: "status; <attacker-payload>"
// Result: shell parses the semicolon and executes the payload.

Refer to the CERT Poland advisory for additional technical detail.

Detection Methods for CVE-2026-9279

Indicators of Compromise

Unexpected child processes spawned by the Logseq executable, particularly shell interpreters such as sh, bash, zsh, cmd.exe, or powershell.exe.
Logseq-launched processes invoking network utilities such as curl, wget, or nc, or writing to startup and persistence locations.
Installation of unsigned or unreviewed Logseq plugins immediately before suspicious process activity.

Detection Strategies

Monitor process lineage for Logseq as the parent of shell processes, then inspect the full command line for chained operators such as ;, &&, ||, and backticks.
Alert on allowlisted binaries (git, pandoc, grep) invoked by Logseq with argument strings that contain shell metacharacters or redirection operators.
Correlate Logseq plugin installation events with subsequent outbound network connections or file writes outside the notes directory.

Monitoring Recommendations

Enable command-line auditing on endpoints running Logseq and forward process creation events to a centralized log store for retention and search.
Track outbound network connections originating from the Logseq process and flag destinations not associated with sync or update services.
Review installed Logseq plugins against an internal approved list and alert on additions.

How to Mitigate CVE-2026-9279

Immediate Actions Required

Restrict Logseq usage to trusted Markdown content and disable rendering of untrusted embedded HTML or iframes where possible.
Remove all third-party Logseq plugins that are not strictly required and block installation of new plugins on managed endpoints.
Run Logseq under a standard user account with no administrative privileges to limit the impact of command execution.

Patch Information

No vendor patch is available at the time of publication. The CERT Poland advisory notes that the issue was not addressed by a fix. Monitor the Logseq project for future security releases and apply them when issued.

Workarounds

Avoid opening untrusted Logseq graphs, shared notes, or Markdown files from unknown sources until a patch is released.
Use application allowlisting or endpoint controls to block Logseq from spawning shell interpreters and common living-off-the-land binaries.
Isolate Logseq usage to a dedicated low-privilege account or sandboxed environment that limits filesystem and network reach.

bash

# Example: block shell spawning by Logseq on Linux via AppArmor profile fragment
# Place in a custom profile attached to the Logseq binary.
deny /bin/sh ix,
deny /bin/bash ix,
deny /usr/bin/zsh ix,
deny /usr/bin/curl ix,
deny /usr/bin/wget ix,