CVE-2026-82642: readest iframe srcdoc XSS bypass

CISO Take

Readest, an open-source Tauri-based e-book reader, sanitized EPUB chapter HTML with a DOMPurify configuration that only blocked the <script> tag, missing that DOMPurify treats an <iframe>'s srcdoc attribute as an opaque string rather than parsing its contents — so a hidden, zero-size iframe carrying a full HTML document with an embedded script slips through untouched. Because the reader's content iframe runs with sandbox="allow-same-origin allow-scripts", that script executes with the parent's origin and can call parent.parent.__TAURI_INTERNALS__.invoke(...), reaching every Tauri IPC command the app is permitted to use and turning a rendering bug into arbitrary code execution on the user's machine — CVSS 8.8, no privileges required, though it does need a user to open a malicious book file. There is no evidence of active exploitation (not in CISA KEV, no EPSS score published, no public PoC or Nuclei template), so this reads as a disclosed-and-patched sanitizer gap rather than an in-the-wild campaign, but the underlying technique — an iframe srcdoc bypassing a tag-based sanitizer allowlist to reach a native IPC bridge — is generic and worth checking against any other Tauri or Electron app that renders untrusted HTML, EPUB, or Markdown client-side. Upgrade Readest to 0.11.16 or later, which adds 'iframe', 'object', and 'embed' to FORBID_TAGS and 'srcdoc' to FORBID_ATTR; until patched, treat any EPUB from an untrusted source as a potential full-compromise vector.

Sources:NVDGitHub AdvisoryATLAS

What is the risk?

High severity (CVSS 8.8) but currently a low-exploitation-likelihood risk: attack vector is network-deliverable content with low complexity and no privileges required, but it does require user interaction (opening a malicious EPUB file), which caps automatic/drive-by exploitation. No EPSS score, no CISA KEV listing, no public exploit code, and no Nuclei template exist as of this writing, indicating no known active exploitation campaign. The real risk driver is impact, not likelihood: successful exploitation gives an attacker the full set of Tauri IPC commands the app is permitted to call, which in most desktop apps includes filesystem, shell, or network primitives — effectively arbitrary code execution on the host, not just a browser-sandboxed XSS. Organizations distributing or allowing Readest (or any similarly-architected Tauri/Electron app with an under-restricted sanitizer) should treat this as a client-side RCE risk equivalent to a malicious-document vulnerability, not a cosmetic content-injection bug.

How does the attack unfold?

Malicious document delivery

Attacker distributes an EPUB file containing a hidden, zero-size iframe whose srcdoc attribute embeds a full HTML document with a <script> tag, relying on the victim to open the book.

AML.T0011

Sanitizer bypass

DOMPurify only forbids the <script> tag and never inspects the opaque srcdoc string, so the malicious iframe and its embedded script pass sanitization unmodified.

Script execution in shared origin

The content iframe's sandbox="allow-same-origin allow-scripts" setting lets the injected script run with the parent app's origin when the reader renders the chapter.

AML.T0050

IPC bridge abuse and RCE

The script calls parent.parent.__TAURI_INTERNALS__.invoke(...) to reach any permitted Tauri command, escalating from a rendering bug to arbitrary code execution on the host.

Malicious document delivery

Attacker distributes an EPUB file containing a hidden, zero-size iframe whose srcdoc attribute embeds a full HTML document with a <script> tag, relying on the victim to open the book.

AML.T0011

Sanitizer bypass

DOMPurify only forbids the <script> tag and never inspects the opaque srcdoc string, so the malicious iframe and its embedded script pass sanitization unmodified.

Script execution in shared origin

The content iframe's sandbox="allow-same-origin allow-scripts" setting lets the injected script run with the parent app's origin when the reader renders the chapter.

AML.T0050

IPC bridge abuse and RCE

The script calls parent.parent.__TAURI_INTERNALS__.invoke(...) to reach any permitted Tauri command, escalating from a rendering bug to arbitrary code execution on the host.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
readest	—	—	No patch

Do you use readest? You're affected.

How severe is it?

CVSS 3.1

8.8 / 10

EPSS

0.7%

chance of exploitation in 30 days

Higher than 52% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AVNetwork

ACLow

PRNone

UIRequired

SUnchanged

CHigh

IHigh

AHigh

What should I do?

1 step

1) Patch: upgrade Readest to v0.11.16 or later, which adds 'iframe', 'object', and 'embed' to the DOMPurify FORBID_TAGS list and 'srcdoc' to FORBID_ATTR. 2) Audit any other Tauri/Electron app in your environment that renders untrusted HTML (EPUB readers, AI chat UIs, Markdown viewers) for the same gap — verify their sanitizer explicitly forbids iframe/object/embed tags and the srcdoc/src attributes, not just <script>. 3) Defense-in-depth: ensure content-rendering iframes never combine allow-same-origin with allow-scripts unless strictly necessary — this combination is what allowed the payload to reach the parent origin and the Tauri bridge. 4) Detection: for security teams monitoring endpoint telemetry, watch for Tauri/Electron apps spawning unexpected child processes or making unexpected filesystem/network calls shortly after opening a user-supplied document (EPUB, PDF-wrapper, etc.) — a strong indicator of a sanitizer-bypass-to-native-bridge exploit chain. 5) Restrict distribution of untrusted EPUB/document files from unverified sources until patched clients are confirmed deployed fleet-wide.

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableNo

Technical Impacttotal

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Code ExecutionData LeakageFrameworkAML.T0011- User Execution AML.T0050- Command and Scripting Interpreter

Which compliance frameworks are affected?

This CVE is relevant to:

NIST AI RMF

GOVERN-6.1-Third-party AI system component risk

Frequently Asked Questions

What is CVE-2026-82642?

Readest, an open-source Tauri-based e-book reader, sanitized EPUB chapter HTML with a DOMPurify configuration that only blocked the <script> tag, missing that DOMPurify treats an <iframe>'s srcdoc attribute as an opaque string rather than parsing its contents — so a hidden, zero-size iframe carrying a full HTML document with an embedded script slips through untouched. Because the reader's content iframe runs with sandbox="allow-same-origin allow-scripts", that script executes with the parent's origin and can call parent.parent.__TAURI_INTERNALS__.invoke(...), reaching every Tauri IPC command the app is permitted to use and turning a rendering bug into arbitrary code execution on the user's machine — CVSS 8.8, no privileges required, though it does need a user to open a malicious book file. There is no evidence of active exploitation (not in CISA KEV, no EPSS score published, no public PoC or Nuclei template), so this reads as a disclosed-and-patched sanitizer gap rather than an in-the-wild campaign, but the underlying technique — an iframe srcdoc bypassing a tag-based sanitizer allowlist to reach a native IPC bridge — is generic and worth checking against any other Tauri or Electron app that renders untrusted HTML, EPUB, or Markdown client-side. Upgrade Readest to 0.11.16 or later, which adds 'iframe', 'object', and 'embed' to FORBID_TAGS and 'srcdoc' to FORBID_ATTR; until patched, treat any EPUB from an untrusted source as a potential full-compromise vector.

Is CVE-2026-82642 actively exploited?

No confirmed active exploitation of CVE-2026-82642 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-82642?

1) Patch: upgrade Readest to v0.11.16 or later, which adds 'iframe', 'object', and 'embed' to the DOMPurify FORBID_TAGS list and 'srcdoc' to FORBID_ATTR. 2) Audit any other Tauri/Electron app in your environment that renders untrusted HTML (EPUB readers, AI chat UIs, Markdown viewers) for the same gap — verify their sanitizer explicitly forbids iframe/object/embed tags and the srcdoc/src attributes, not just <script>. 3) Defense-in-depth: ensure content-rendering iframes never combine allow-same-origin with allow-scripts unless strictly necessary — this combination is what allowed the payload to reach the parent origin and the Tauri bridge. 4) Detection: for security teams monitoring endpoint telemetry, watch for Tauri/Electron apps spawning unexpected child processes or making unexpected filesystem/network calls shortly after opening a user-supplied document (EPUB, PDF-wrapper, etc.) — a strong indicator of a sanitizer-bypass-to-native-bridge exploit chain. 5) Restrict distribution of untrusted EPUB/document files from unverified sources until patched clients are confirmed deployed fleet-wide.

What systems are affected by CVE-2026-82642?

This vulnerability affects the following AI/ML architecture patterns: Tauri-based desktop applications, agent frameworks with native IPC bridges, local AI/document-rendering tools with embedded HTML sanitization.

What is the CVSS score for CVE-2026-82642?

CVE-2026-82642 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.66%.

What is the AI security impact?

Affected AI Architectures

Tauri-based desktop applicationsagent frameworks with native IPC bridgeslocal AI/document-rendering tools with embedded HTML sanitization

MITRE ATLAS Techniques

AML.T0011User Execution

AML.T0050Command and Scripting Interpreter

Compliance Controls Affected

NIST AI RMF: GOVERN-6.1

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An attacker crafts a malicious EPUB file containing a chapter with a zero-size, visually transparent <iframe> whose srcdoc attribute holds a complete HTML document with an embedded <script> tag. They distribute the file via a book-sharing site, torrent, email attachment, or supply-chain-adjacent channel (e.g., a compromised 'free books' repository) and rely on the victim opening it in Readest, satisfying the required user interaction. Because DOMPurify's FORBID_TAGS list only blocks <script> and never inspects the opaque srcdoc string, the iframe and its embedded script survive sanitization intact; when Readest renders the chapter, the browser parses the srcdoc content as a full document and executes the script inside the sandboxed-but-same-origin iframe. From there, the script calls parent.parent.__TAURI_INTERNALS__.invoke(...) to invoke any Tauri command the app's permission manifest allows — potentially reading/writing files, exfiltrating data, or launching processes — all while the victim sees nothing but normal book text, since the malicious iframe is invisible.

Weaknesses (CWE)

CWE-79Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

CWE-79 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'): The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.

[Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
[Implementation, Architecture and Design] Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies. For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters. Parts of the same output document may require different encodings, which will vary depending on whether the output is in the: etc. Note that HTML Entity Encoding is only appropriate for the HTML body. Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed. HTML body Element attributes (such as src="XYZ") URIs JavaScript sections Casca

Source: MITRE CWE corpus.