Threats affecting pkg:npm/sanitize-html

ApostropheCMS versions prior to 4.33.0 are affected by a cross-site scripting (XSS) vulnerability due to unsafe handling of meta refresh elements in the sanitize-html library before version 2.18.0. This flaw allows unsafe script or redirect destinations to be retained in the refresh content value under a non-default configuration. The issue is fixed in sanitize-html 2.18.0 and ApostropheCMS 4.33.0.

ApostropheCMS versions prior to 4.33.0 and sanitize-html versions from 2.17.7 up to but not including 2.18.0 contain a cross-site scripting (XSS) vulnerability. This occurs due to a bypass in the SMIL URL protection when namespace-prefixed SVG animation elements and certain URL-targeting attributes are allowed, enabling unsafe URI rewriting and script execution upon user interaction. The default sanitizer configuration is not universally affected. The issue is fixed in sanitize-html 2.18.0 and ApostropheCMS 4.33.0.

ApostropheCMS versions prior to 4.33.0 are affected by a cross-site scripting (XSS) vulnerability due to improper sanitization of noscript tag content in the sanitize-html library before version 2.18.0. This flaw allows content intended to be inert to survive sanitization and render in scripting-enabled browsers, potentially enabling XSS attacks. The issue is fixed in sanitize-html 2.18.0 and ApostropheCMS 4.33.0.

ApostropheCMS versions prior to 4.34.0 and sanitize-html versions 2.18.0 before 2.18.1 contain an uncontrolled recursion vulnerability. This occurs when an <iframe> tag is disallowed and disallowedTagsMode is set to 'discard', causing recursive calls to sanitizeHtml without a termination condition. The flaw leads to a denial of service by exhausting resources. The issue is fixed in versions 4.34.0 of ApostropheCMS and 2.18.1 of sanitize-html.

## Summary sanitize-html uses `allowedSchemesAppliedToAttributes` (default: `['href', 'src', 'cite']`) to gate the `naughtyHref()` function that blocks dangerous URI schemes like `javascript:` and `vbscript:`. The HTML specification defines 10+ attributes that accept URIs (`action`, `formaction`, `data`, `poster`, `background`, `ping`, `xlink:href`, `dynsrc`, `lowsrc`), but none of these are included in the default gate list. When a developer allows any of these attributes in their configuration, `javascript:` URIs pass through completely unmodified, enabling XSS. The library has zero awareness of these URI-bearing attributes — none appear anywhere in the 854-line source file (verified by grep). No warning mechanism exists, and the README provides no security guidance about expanding `allowedSchemesAppliedToAttributes` when allowing form or media attributes. ## Severity Exploitation requires non-default configuration: the developer must explicitly allow a non-default tag (e.g., `form`) AND a non-default attribute (e.g., `action`). Default configuration is NOT vulnerable. However, this is a common configuration pattern for CMS platforms, form builders, and rich content editors. ## Affected Versions All versions of sanitize-html from v1.18.0 (which introduced `allowedSchemesAppliedToAttributes`) through at least v2.17.2. The default list has been `['href', 'src', 'cite']` since introduction and has never been expanded. ## Root Cause **File**: `index.js:329` (sanitize-html 2.10.0, confirmed same in 2.17.x) ```javascript // Line 329 — The gate that controls scheme validation if (options.allowedSchemesAppliedToAttributes.indexOf(a) >= 0) { if (naughtyHref(name, value)) { delete frame.attribs[a]; return; } } ``` **Default list at line 829**: ```javascript allowedSchemesAppliedToAttributes: ['href', 'src', 'cite'], ``` The `naughtyHref()` function (lines 627-667) correctly blocks `javascript:`, `vbscript:`, and other dangerous schemes. However, it has exactly 2 call sites in the entire codebase (lines 330 and 395), both inside the `indexOf` gate. There is no ungated path. When attribute name is `action`, `formaction`, `data`, `poster`, `background`, etc.: - `indexOf('action')` returns `-1` - The `if` block is skipped entirely - `naughtyHref()` is never called - `javascript:alert(1)` passes through unmodified The `escapeHtml()` function at line 464 provides no defense — it only encodes `& < > "` characters, which are not present in `javascript:alert(1)`. **Data Flow**: ``` Attacker input: <form action="javascript:alert(document.cookie)"> 1. htmlparser2 parses → tag='form', attribs={action:'javascript:alert(document.cookie)'} 2. index.js:298 → allowedAttributes check: 'action' in developer config → PASS 3. index.js:329 → ['href','src','cite'].indexOf('action') → -1 → SKIP naughtyHref() 4. index.js:464 → escapeHtml('javascript:alert(document.cookie)') → unchanged 5. OUTPUT: <form action="javascript:alert(document.cookie)"> ``` ## Steps to Reproduce ```javascript const sanitize = require('sanitize-html'); // ===== VECTOR 1: form action (100% reliable, all modern browsers) ===== const v1 = sanitize( '<form action="javascript:alert(document.cookie)"><button>Submit</button></form>', { allowedTags: ['form', 'button'], allowedAttributes: { form: ['action'] } } ); console.log('V1 (action):', v1); // OUTPUT: <form action="javascript:alert(document.cookie)"><button>Submit</button></form> // XSS triggers when user submits the form // ===== VECTOR 2: button formaction (100% reliable) ===== const v2 = sanitize( '<button formaction="javascript:alert(1)">Click</button>', { allowedTags: ['button'], allowedAttributes: { button: ['formaction'] } } ); console.log('V2 (formaction):', v2); // OUTPUT: <button formaction="javascript:alert(1)">Click</button> // ===== VECTOR 3: object data ===== const v3 = sanitize( '<object data="javascript:alert(1)"></object>', { allowedTags: ['object'], allowedAttributes: { object: ['data'] } } ); console.log('V3 (data):', v3); // OUTPUT: <object data="javascript:alert(1)"></object> // ===== CONTROL: href IS scheme-checked (expected behavior) ===== const ctrl = sanitize( '<a href="javascript:alert(1)">click</a>', { allowedTags: ['a'], allowedAttributes: { a: ['href'] } } ); console.log('Control (href):', ctrl); // OUTPUT: <a>click</a> ← href correctly stripped by naughtyHref() ``` **Observed behavior**: `javascript:` preserved on `action`/`formaction`/`data` but correctly stripped on `href`. **Expected behavior**: `javascript:` should be stripped on ALL URI-bearing attributes, or at minimum, the library should warn developers when they allow URI-bearing attributes not covered by scheme validation. ## Impact An attacker can achieve XSS in applications that use sanitize-html with non-default configurations allowing URI-bearing attributes: - `<for

ApostropheCMS is an open-source Node.js content management system, and sanitize-html provides a simple HTML sanitizer with a clear API. Under the default configuration, versions of `sanitize-html` prior to 2.17.4 can turn attacker-controlled content inside a disallowed `xmp` element into live HTML or JavaScript. This is a sanitizer bypass in the default `disallowedTagsMode: 'discard'` path and can lead to stored XSS in applications that render sanitized output back to users. Version 2.17.4 patches the issue.

ApostropheCMS is an open-source Node.js content management system. A regression introduced in commit 49d0bb7, included in versions 2.17.1 of the ApostropheCMS-maintained sanitize-html package bypasses allowedTags enforcement for text inside nonTextTagsArray elements (textarea and option). ApostropheCMS version 4.28.0 is affected through its dependency on the vulnerable sanitize-html version. The code at packages/sanitize-html/index.js:569-573 incorrectly assumes that htmlparser2 does not decode entities inside these elements and skips escaping, but htmlparser2 10.x does decode entities before passing text to the ontext callback. As a result, entity-encoded HTML is decoded by the parser and then written directly to the output as literal HTML characters, completely bypassing the allowedTags filter. An attacker can inject arbitrary tags including XSS payloads through any allowed option or textarea element using entity encoding. This affects non-default configurations where option or textarea are included in allowedTags, which is common in form builders and CMS platforms. This issue has been fixed in version 2.17.2 of sanitize-html and 4.29.0 of ApostropheCMS.