CVE-2026-86016 in VNote
Summary
by MITRE • 10/13/2026
VNote is a note-taking platform. Prior to 4.3.0, VNote uses the assignment `preNode.innerHTML = p_metaData` in src/data/extra/web/js/markdownit.js to insert YAML frontmatter metadata into a pre element before the protectFromXss sanitization path runs. Opening an attacker-supplied Markdown note can therefore execute stored JavaScript in the file:// viewer context. Because QWebEngineSettings::LocalContentCanAccessRemoteUrls enables local content to access remote URLs, the script can read reachable local note files and transmit their contents to a remote server without further interaction after the note is opened. This issue is fixed in version 4.3.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/13/2026
VNote is a popular cross-platform note-taking application that supports Markdown formatting and various extensions for enhanced productivity features. A critical security vulnerability was identified in versions prior to 4.3.0, specifically within the JavaScript handling logic responsible for rendering YAML frontmatter metadata. The core technical flaw stems from an improper sequence of operations during the document processing pipeline. Specifically, the application utilizes a direct innerHTML assignment operation on a pre element using raw user-supplied data derived from Markdown files before any XSS sanitization mechanisms are invoked. This architectural oversight allows maliciously crafted content within YAML frontmatter to bypass intended security controls because the injection occurs at a stage where protective filters have not yet been applied to the specific DOM node being modified.
The operational impact of this vulnerability is severe due to the execution context in which VNote operates. When an attacker supplies a Markdown note containing embedded JavaScript payloads within its metadata section, opening such a file triggers the execution of that script code. Because VNote utilizes Qt WebEngine for rendering content, it inherits specific security settings related to local and remote resource access. The configuration setting QWebEngineSettings::LocalContentCanAccessRemoteUrls is enabled by default in many configurations, which permits scripts running within locally loaded files to make network requests to external servers. Consequently, an attacker can craft a malicious note that, once opened by the victim, executes stored JavaScript capable of reading other local file contents accessible via the file:// protocol and exfiltrating them to a remote command-and-control server without requiring any further interaction from the user after the initial opening of the document.
This vulnerability aligns with CWE-79, which describes Improper Neutralization of Input During Web Page Generation known as Cross-site Scripting (XSS). More specifically, it represents an instance where sanitization is applied too late in the processing chain to be effective against dynamically inserted content. From a threat modeling perspective consistent with MITRE ATT&CK frameworks, this behavior facilitates Initial Access through maliciously crafted files and enables Data Exfiltration over alternative channels such as HTTP or HTTPS traffic initiated by client-side scripts. The ability to read local file contents via JavaScript running in the browser context of an Electron-based application highlights the risks associated with enabling broad filesystem access permissions for web content without strict origin isolation or sandboxing measures that prevent cross-origin data theft from local resources.
To mitigate this vulnerability, users must upgrade VNote to version 4.3.0 or later where the issue has been resolved by correcting the order of operations in the markdown rendering engine and ensuring sanitization precedes DOM manipulation involving user-supplied metadata. For organizations deploying VNote at scale, it is advisable to audit configuration settings related to Qt WebEngine permissions, particularly disabling LocalContentCanAccessRemoteUrls if remote access from local files is not strictly required for legitimate functionality. Additionally, implementing strict Content Security Policy headers within the application's web views can provide an additional layer of defense by restricting script execution sources and preventing unauthorized network requests. Regular security audits of third-party dependencies and input validation routines are essential to prevent similar injection flaws in future updates or related applications relying on embedded web technologies for content rendering.