Logseq CVE-2026-47900

Exploitation requires the target user to actively install a malicious Logseq plugin - this is the primary limiting factor captured by the CVSS UI:A (active user interaction required) and AV:L (local) scores. The malicious plugin must contain a crafted 'name' field in its package.json manifest. No authentication to a remote system is involved; the attack is entirely local and plugin-driven. Exploitation is further constrained to environments where Logseq's plugin feature is enabled and accessible (which is the default configuration). The privileged host context escalation is contingent on Logseq's Electron renderer retaining Node.js API access - if Logseq were to enforce strict contextIsolation and sandbox settings, the impact would be limited to renderer-scoped XSS. Exploitation is NOT possible without user action to install the plugin; drive-by or network-only attack paths are not applicable under the current CVSS vector.

The CVSS 4.0 base score of 4.6 with vector AV:L/AC:L/AT:N/PR:N/UI:A reflects a local attack requiring active user interaction (plugin installation), which correctly limits opportunistic mass exploitation. However, the assigned score likely underweights the effective impact: the description explicitly states execution occurs in the 'privileged host context', and the CVE tags include 'RCE' alongside 'XSS' - signals that align with the well-documented Electron XSS-to-RCE escalation pattern where Node.js access is available in the renderer. The low CVSS impact sub-scores (VC:L, VI:L) appear inconsistent with host-level code execution capability; this discrepancy should be verified against the CERT-PL advisory. No EPSS score was provided, KEV status is negative, and no public exploit code has been identified, so widespread automated exploitation is not a current concern. The realistic threat model is a targeted or supply-chain attack: a threat actor publishes a malicious Logseq plugin to a plugin marketplace or distributes it directly, then waits for users to install it. The absence of a patch (confirmed by the reporter) is the most pressing risk signal.

An attacker publishes a Logseq plugin to a public plugin marketplace or shares it via community channels (e.g., a forum post or GitHub repository), embedding a JavaScript payload such as a Node.js child_process.exec call within the plugin's package.json 'name' field. A Logseq user discovers and installs the plugin; when Logseq renders the plugin's metadata via innerHTML in its privileged Electron renderer, the payload executes with host-level privileges, enabling actions such as reading local files, establishing persistence, or spawning a reverse shell. No public proof-of-concept exploit code has been identified at time of analysis, but the technique is well-understood in the Electron security community.