Logseq EUVD-2026-35438

Exploitation requires the victim to install and activate a malicious Logseq plugin - this is the mandatory prerequisite and the primary limiting factor. The CVSS AV:L (local) and UI:A (active user interaction) confirm that remote unauthenticated exploitation is not possible; the attacker's code must reach the victim through the plugin distribution channel and the user must voluntarily install it. The vulnerability further requires that the injected event handler attribute be triggered by user interaction with the affected host DOM element (e.g., mouse movement, click). The disabled Content Security Policy in the host context is a necessary enabling condition: if a CSP were present and restricting inline scripts, the injected handlers would be blocked by the browser even if attribute injection succeeded. Users who run Logseq with no plugins installed, or exclusively with plugins from audited trusted sources, are not at practical risk. The vulnerability does not expose a network-accessible attack surface and cannot be triggered by a remote third party without first achieving plugin code execution on the victim's Logseq instance.

The CVSS 4.0 score of 4.6 appropriately reflects a constrained attack surface. The vector AV:L (local) and UI:A (active user interaction) together mean exploitation is not opportunistic - the victim must deliberately install and activate a malicious plugin, which is a meaningful barrier. PR:N indicates no special system privileges are needed by the attacker to author a plugin. The confidentiality and integrity impacts are rated Low (VC:L/VI:L) against the vulnerable system with no impact on subsequent systems, which may understate risk if Logseq's filesystem API grants broad local file read/write access in practice; this should be verified against Logseq's plugin API surface documentation. No EPSS score was provided in the source data, making probabilistic exploitation likelihood assessment impossible. This CVE is not in the CISA KEV catalog, and no public exploit or POC has been identified at time of analysis. In practical terms, this is a real but targeted risk: users who install untrusted third-party Logseq plugins are the at-risk population, while users running no plugins or only curated plugins face negligible exposure. The lack of a CSP is a defense-in-depth failure worth remediating independently of the specific plugin injection vector.

An attacker publishes a malicious Logseq plugin to the plugin marketplace or distributes it via a community forum; when the victim installs and enables the plugin, it injects a JavaScript event handler attribute (e.g., onmouseover) into the plugin's container element in the host DOM. Because Logseq's host context has no Content Security Policy, the event handler fires as privileged Electron renderer JavaScript the next time the user's cursor passes over the element, granting the attacker's code access to Logseq's filesystem APIs for reading local notes and potentially writing arbitrary files. No public exploit code has been identified at time of analysis, so this scenario is based on the described vulnerability mechanism rather than a confirmed working exploit.