sanitize-html CVE-2026-113650

Exploitation requires that the application feeds attacker-influenced HTML into sanitize-html 2.18.0 while running the default configuration - specifically with <iframe> NOT in allowedTags and disallowedTagsMode set to 'discard' (both are the library defaults), so most unmodified deployments are exposed. The payload must contain a disallowed <iframe> whose raw-text content nests deeply enough to overflow the Node.js call stack. Limiting factors: there must exist an application path that routes untrusted HTML to sanitizeHtml (e.g. a public comment/form or an editor input); deployments that explicitly allow iframes or set disallowedTagsMode to a non-'discard' mode avoid the recursive path; and impact is confined to availability (a failed request or stack-overflow error), with no data exposure. Per CVSS PR:N the flaw is reachable without authentication, though in ApostropheCMS the HTML-submission surface may in practice sit behind editor permissions depending on where sanitize-html is invoked.

This is a genuine but moderate-severity denial-of-service issue, not a critical priority. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L, base 5.3) correctly signals a remotely reachable, low-complexity, unauthenticated flaw whose only impact is low availability - there is no confidentiality or integrity exposure (C:N/I:N). The root cause (CWE-674 uncontrolled recursion in sanitize-html 2.18.0: a disallowed <iframe> under the default disallowedTagsMode 'discard' re-sanitizes its raw-text content via an unbounded recursive sanitizeHtml call) can exhaust the Node.js call stack. No EPSS score, CISA KEV entry, or public POC was provided in the intelligence set, so there is no public exploit identified at time of analysis and no evidence of active exploitation. NOTE A CONFLICT: the input tag 'Information Disclosure' contradicts the CVSS vector, which shows zero confidentiality/integrity impact and only availability impact - the CWE-674 mechanism is a resource-exhaustion DoS, so the tag appears mislabeled and should not drive triage. Overall this warrants routine patching (trivial exploit, wide library footprint) rather than emergency response, because worst-case impact is a crashed request or process, not data loss.

An attacker submits crafted HTML - for example through a comment, form field, or rich-text input that an application passes to sanitize-html with its default options - in which a disallowed <iframe> contains deeply nested raw-text content. Because the sanitizer recursively re-sanitizes that content without any depth bound, the Node.js call stack is exhausted, throwing a stack-overflow error that fails the request or can disrupt the service. No public exploit code was provided, but the trigger is simple to construct once the mechanism is known.