CVE-2019-25225

What it actually does

The flaw is a cross-site scripting weakness in sanitize-html before 2.0.0-beta where the sanitizeHtml() function can fail to neutralize attacker-controlled content when the custom transformTags option is used. transformTags is intended to rewrite tags or attributes, including converting attribute values into text, but vulnerable versions can allow transformed input to become executable browser code. If an application accepts untrusted HTML or rich text and renders the sanitized output to other users, an attacker can inject JavaScript that executes in the victim’s browser under the vulnerable application’s origin.

Why it matters to the business

Successful exploitation can allow attackers to hijack user sessions, perform actions as legitimate users, alter page content, steal data visible in the browser, or deliver phishing prompts inside a trusted application. The direct severity is moderate because exploitation generally requires a victim to view attacker-supplied content, but impact increases significantly for administrative consoles, content-management workflows, collaboration tools, dashboards, or embedded Kibana-based interfaces where privileged users may render user-controlled content. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS, so broad active exploitation is not currently indicated; however, affected dependency use in downstream packages means exposure may exist indirectly through bundled software.

How an attack unfolds

An attacker first identifies an application path where users can submit HTML, markdown converted to HTML, comments, profile fields, dashboards, descriptions, templates, or other rich text that is sanitized using a vulnerable sanitize-html version. The attacker then crafts input that interacts with the application’s transformTags configuration so that dangerous content survives the transformation process or is converted into executable markup. When the application stores or reflects the sanitized result and a victim later views it, the browser executes the injected script in the context of the trusted site. From there, the attacker may read page data, capture anti-CSRF tokens or session-adjacent secrets accessible to JavaScript, make same-origin requests as the victim, change displayed content, or redirect the victim to attacker-controlled infrastructure. Exploitation maturity is currently reported as none, so defenders should focus on dependency remediation, targeted exposure review, and retrospective searches for suspicious script-bearing user content rather than assuming widespread weaponization.

How to fix it

Upgrade sanitize-html to version 2.0.0-beta or later, or to a current stable release, wherever it is used directly or transitively. For the listed source package, the issue is fixed by apostrophecms/sanitize-html commit 712cb6895825c8bb6ede71a16b42bade42abcaf3. For MinimOS downstream packages, upgrade kibana-8, kibana-8-config, and kibana-8-oci-entrypoint to 8.18.3-r0 or later. After upgrading, rebuild and redeploy applications or containers so the fixed dependency is actually present at runtime. As defense in depth, review transformTags usage, avoid returning raw attacker-controlled values from transformation callbacks, encode text output explicitly, restrict allowed tags and attributes to the minimum required, disallow javascript: and data: URLs unless strictly necessary, and deploy a restrictive Content Security Policy that blocks inline scripts where possible.

How to confirm the fix worked

Confirm dependency versions using package lockfiles, software composition analysis, npm/yarn/pnpm dependency trees, container SBOMs, and runtime image scans. For direct Node.js use, verify sanitize-html resolves to 2.0.0-beta or later, preferably a current stable version, and that no nested dependency still resolves to a vulnerable copy. For MinimOS images or packages, verify kibana-8, kibana-8-config, and kibana-8-oci-entrypoint are 8.18.3-r0 or later. Review code for sanitizeHtml() calls that use transformTags and test representative malicious payloads in a non-production environment to ensure they are rendered inert as text rather than executable markup. Validate that rebuilt artifacts no longer contain the vulnerable source code path and that browser testing shows injected event handlers, script tags, and javascript: URLs do not execute.

Typical attack path

1. Find an application feature that accepts and later renders user-controlled HTML or rich text.
2. Confirm the application or bundled component uses sanitize-html before 2.0.0-beta with a custom transformTags configuration.
3. Submit crafted markup or attributes designed to survive sanitization after tag transformation.
4. Wait for another user, preferably a privileged user, to view the affected content.
5. Execute JavaScript in the victim’s browser under the vulnerable application’s origin.
6. Use the victim’s browser context to steal visible data, perform unauthorized actions, modify content, or stage further phishing.

How to detect it

To determine whether exploitation already occurred, examine places where user-supplied HTML or rich text is submitted, stored, transformed, and rendered. Relevant sources include web application access logs, API gateway logs, WAF logs, application logs for content creation or update actions, audit logs for administrative content changes, stored comments or documents, CMS revision history, dashboard or visualization descriptions, and database-backed content repositories. Search for payloads containing script tags, HTML event handlers, javascript: URLs, SVG-based script execution, encoded angle brackets, data:text/html payloads, suspicious iframe/object/embed tags, and unusual post-exploitation browser activity such as unexpected same-origin administrative actions immediately after viewing user content. Also review code and build logs for sanitizeHtml() usage with transformTags to identify exploitable locations. If suspicious payloads are found, correlate submission time, rendering/view events, affected users, authentication events, session changes, privilege-sensitive actions, and outbound requests to unfamiliar domains. Because XSS payloads are often encoded or fragmented, include URL-decoded, HTML-decoded, Unicode-normalized, and case-insensitive searches.

• <script
• </script>
• onerror=
• onload=
• onclick=
• onmouseover=
• onfocus=
• onanimationstart=
• javascript:
• data:text/html
• <svg
• <iframe
• <object
• <embed
• srcdoc=
• eval(
• document.cookie
• localStorage
• sessionStorage
• fetch(
• XMLHttpRequest
• String.fromCharCode
• atob(
• &#x3c;script
• %3Cscript
• sanitizeHtml(
• transformTags

What your security team should do

• Inventory all applications, containers, and build artifacts that include sanitize-html directly or through downstream packages such as Kibana-based bundles.
• Prioritize remediation for internet-facing applications and internal administrative interfaces that render user-supplied rich text to authenticated or privileged users.
• Upgrade sanitize-html to 2.0.0-beta or later, preferably the latest stable release, and upgrade MinimOS kibana-8, kibana-8-config, and kibana-8-oci-entrypoint to 8.18.3-r0 or later where applicable.
• Search source code for sanitizeHtml() calls using transformTags and perform secure code review of callback logic that copies attribute values or user input into returned tag text, attributes, or markup.
• Add regression tests with XSS payloads that verify transformed content remains non-executable after sanitization.
• Deploy or tighten Content Security Policy controls to reduce the impact of any missed client-side injection path.
• Perform retrospective log and content-store searches for suspicious submitted HTML containing script tags, event-handler attributes, javascript: URLs, data: HTML payloads, or encoded equivalents.
• If suspicious content is found, identify users who viewed it, review session activity following the view, and invalidate affected sessions if account misuse is suspected.