dbcve.org
OS Command InjectionWeakness · CWE-78

CVE-2026-9279

HIGH · 8.7 CVSS v4.0 Published 2026-06-09
Mitigation only
No fix yet — a mitigation exists. There is no fixed release. A documented workaround reduces exposure in the meantime.
See remediation →
92/100
Remediation priority · Urgent
No privileges Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
Logseq exposes an IPC handler that allows the renderer process to execute shell commands. While an allowlist restricts the command name (e.g. `git`, `pandoc`, `grep`), the argument string is concatenated with the command and passed to `child_process.spawn` with the `shell: true` option, allowing shell metacharacters in the arguments to bypass the allowlist. An attacker with JavaScript execution in the renderer (e.g. via XSS or a malicious plugin) can execute arbitrary shell commands with the privileges of the Logseq process, leading to remote code execution on the host. While only version v0.10.15 was tested and confirmed as vulnerable, status of other versions is unknown since this issue was not addressed by a patch.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

Logseq exposes an IPC handler that allows the renderer process to invoke allowed commands (git, pandoc, grep) via child_process.spawn with shell: true. Because the argument string is concatenated directly and shell metacharacters are not sanitized, an attacker with JS execution in the renderer can inject arbitrary shell commands to achieve RCE.

MitigationRemove the shell: true option from child_process.spawn calls and implement strict argument validation/sanitization to reject shell metacharacters, or use an array-based spawn API with explicit argument passing.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Local
Complexity
Low
Privileges
None
Authentication
X
User interaction
None
Scope
X

CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N/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

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify if Logseq is installed
    Check for the Logseq executable or application installation. On Windows: look for Logseq.exe in Program Files or AppData. On macOS: check /Applications for Logseq.app. On Linux: check common install paths like /opt or ~/.local/share.
    Affected if Logseq is not installed on the system, then this CVE does not apply.
  2. Determine the installed Logseq version
    Run the Logseq application and check its version. Typically found in Help > About, or check the application metadata file (e.g., package.json in the app resources, or version info in the executable properties). Compare against any known affected version ranges.
    Affected if The installed version falls within an affected range and the vulnerable IPC handler code is present.
  3. Locate the IPC handler code in the installation
    If you have access to the Logseq installation directory, examine the main process JavaScript files for IPC handlers. Look for handlers that use child_process.spawn with shell: true and concatenate arguments directly.
    Affected if The code contains an IPC handler that passes concatenated argument strings to child_process.spawn with shell: true.
  4. Check for the vulnerable allowlist bypass pattern
    Search the application source or decompiled files for patterns like child_process.spawn with shell:true where arguments are concatenated as strings rather than passed as an array.
    Affected if The code shows argument string concatenation with shell: true, which would allow shell metacharacter injection.
  5. Verify if external network access is possible
    Check if the renderer process can communicate with the main process IPC handler. In Logseq, this would typically require the desktop app to be running and the IPC channel to be exposed.
    Affected if The renderer process can send messages to the vulnerable IPC handler, enabling exploitation.

You are affected if Logseq is installed, the installed version contains the vulnerable IPC handler code with shell:true and argument concatenation, and the renderer process can access that handler.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

From vendor data
Mitigation available No clean upgrade yet — mitigate in the meantime
Mitigation

Remove the shell: true option from child_process.spawn calls and implement strict argument validation/sanitization to reject shell metacharacters, or use an array-based spawn API with explicit argument passing.

Have this fixed Scoped from the published advisory
  • Consultation3.0 h
  • Implementation6.0 h
  • Testing3.0 h
  • Review / QA3.0 h
15.0 hours of engineering $2,670
Get help mitigating

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $4,272.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-9279 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-9279 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data