CVE-2026-82642 in Readest
Summary
by MITRE • 08/30/2026
Readest is an open-source e-book reader built on Tauri. In versions prior to 0.11.16, EPUB chapter HTML is sanitized with DOMPurify using a configuration that forbade only the <script> tag (FORBID_TAGS: ['script']) in apps/readest-app/src/services/transformers/sanitizer.ts. DOMPurify does not parse the contents of the srcdoc attribute on <iframe> elements, treating it as an opaque string attribute, so an attacker who can get an <iframe> element to survive sanitization can embed a complete HTML document containing a <script> tag inside srcdoc and have it execute when the browser renders the iframe. The content iframe is configured with sandbox="allow-same-origin allow-scripts", so script executing inside it shares the parent origin and can reach parent.parent.__TAURI_INTERNALS__.invoke(...), giving access to every Tauri IPC command the application is permitted to use, which escalates to arbitrary code execution. The payload can be made invisible (zero-size, transparent iframe) so the reader sees only normal book text. Version 0.11.16 hardened the sanitizer configuration by adding 'iframe', 'object' and 'embed' to FORBID_TAGS and adding 'srcdoc' to FORBID_ATTR.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/30/2026
The vulnerability identified in Readest versions prior to 0.11.16 represents a critical cross-site scripting flaw rooted in the improper sanitization of EPUB chapter HTML content. As an open-source e-book reader built on the Tauri framework, Readest processes user-provided or downloaded book files which may contain maliciously crafted markup. The application utilizes DOMPurify to sanitize this input before rendering it within a browser context. However, the sanitizer configuration was insufficiently restrictive, specifically allowing iframe elements by only forbidding script tags via the FORBID_TAGS setting. This oversight created a significant attack surface where an adversary could inject HTML structures that bypassed initial filtering mechanisms and were subsequently rendered in the user's environment without adequate validation of their internal attributes or nested content.
The technical core of this vulnerability lies in how DOMPurify handles specific HTML5 attributes, particularly srcdoc on iframe elements. When processing markup, DOMPurify treats the contents of the srcdoc attribute as an opaque string rather than parsing it for further malicious payloads. Consequently, if an attacker successfully injects an iframe element that survives sanitization, they can embed a complete secondary HTML document within its srcdoc attribute. This embedded document can contain script tags and other executable code. Because DOMPurify does not recursively sanitize the content of such attributes, these scripts remain intact when the browser renders the iframe. The resulting execution context allows for arbitrary JavaScript injection that is not caught by standard sanitization routines designed to block direct script tag insertion in the main document flow.
The operational impact of this flaw is severe due to the specific security configuration applied to the content iframe within Readest. The iframe was configured with sandbox attributes set to allow-same-origin and allow-scripts. This combination effectively neutralizes many browser-based mitigations against cross-site scripting attacks by granting the embedded script full access to the parent window's origin. Once a malicious script executes inside this iframe, it can interact directly with the parent context through the Window interface. Specifically, the attacker gains the ability to invoke methods on parent.parent._TAURI_INTERNALS_.invoke, which serves as the bridge for inter-process communication in Tauri applications. This access allows the adversary to call any IPC command that the application is permitted to execute, effectively bypassing client-side security controls and escalating from a simple script injection to arbitrary code execution with the privileges of the user running Readest.
To mitigate this vulnerability, users must upgrade immediately to version 0.11.16 or later, where the sanitizer configuration has been hardened. The fix involves expanding the FORBID_TAGS list to explicitly exclude iframe, object, and embed elements, thereby preventing the injection of containers capable of hosting external content or scripts. Additionally, srcdoc was added to the FORBID_ATTR list to ensure that even if other container tags were permitted in future configurations, their ability to execute embedded HTML would be neutralized. From a defensive perspective, this incident highlights the importance of applying strict Content Security Policy headers and ensuring that sandbox attributes do not unnecessarily grant same-origin access unless absolutely required for legitimate functionality. Developers should also consider implementing recursive sanitization strategies or using allowlists rather than blocklists when processing untrusted input to prevent similar bypasses in other contexts.
This vulnerability aligns with CWE-79, which describes Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting. Furthermore, the exploitation technique maps to MITRE ATT&CK techniques related to Client-side Execution and potentially Command and Control if used for remote access. The failure to sanitize nested content within specific attributes like srcdoc is a common pitfall in web application security that underscores the need for rigorous testing of sanitization libraries against complex payload structures. By addressing these gaps, organizations can significantly reduce their risk profile associated with processing untrusted digital documents through browser-based interfaces.