CVE-2025-66400

What it actually does

mdast-util-to-hast versions 13.0.0 through versions before 13.2.1 improperly validate or normalize class names derived from user-supplied Markdown. By using HTML character references in Markdown source, an attacker can cause multiple unprefixed CSS class names to be added to rendered code elements. This does not directly provide code execution or data disclosure, but it can affect rendered page integrity by allowing attacker-controlled Markdown to visually blend with trusted page content, bypass expected styling constraints, or create misleading UI/content presentation.

Why it matters to the business

Applications that render untrusted Markdown may allow users to make malicious or misleading content appear like native site content. This can support phishing, impersonation, social engineering, abuse workflows, or moderation bypasses in documentation portals, forums, knowledge bases, issue trackers, chat systems, CMS platforms, and developer collaboration tools. The risk is moderate because exploitation is remote and low-complexity, but the known impact is limited to content integrity rather than server compromise. EPSS is low and the issue is not listed in CISA KEV, so remediation should be prioritized for internet-facing or user-generated-content rendering paths rather than treated as an emergency unless those paths are business-critical.

How an attack unfolds

An attacker first identifies an application that accepts Markdown from untrusted users and renders it using a vulnerable mdast-util-to-hast dependency. They submit Markdown containing a code block or similar Markdown construct where class names are derived from attacker-controlled text. Instead of using literal spaces or separators that would normally be rejected or handled safely, the attacker encodes separators as character references such as numeric HTML entities. During Markdown-to-HAST transformation, those references are decoded or interpreted in a way that results in multiple unprefixed CSS classes being applied to the rendered element. The attacker then chooses class names already used by the application’s design system so the rendered content visually resembles trusted page elements, notices, buttons, labels, or body text. The final effect is content spoofing or visual deception within the rendered page, which can be used to mislead users into taking actions or trusting attacker-controlled content.

How to fix it

Upgrade mdast-util-to-hast to version 13.2.1 or later. If consuming the upstream Git source, update to a revision containing commit 174795b21f7757fffb54dd8d5fb4012f4751f791 or later. For SUSE Linux Enterprise Live Patching 15 SP4 package kernel-livepatch-SLE15-SP4_Update_6, apply the vendor-fixed package version 5-150400.2.2 where applicable. Rebuild and redeploy applications that bundle JavaScript dependencies so the fixed transitive dependency is actually present in production artifacts. As defense in depth, sanitize rendered HTML, restrict allowed classes on user-generated content, use a strict allowlist for Markdown-rendered element attributes, scope user-generated content under isolated CSS, and avoid allowing attacker-controlled Markdown to inherit privileged application UI classes.

How to confirm the fix worked

Confirm dependency resolution shows mdast-util-to-hast version 13.2.1 or newer in lockfiles and deployed artifacts, not only in package manifests. Use package managers and software composition analysis tooling to inspect direct and transitive dependencies, for example npm ls mdast-util-to-hast, pnpm why mdast-util-to-hast, yarn why mdast-util-to-hast, or equivalent SBOM queries. Render a regression test Markdown payload that previously produced multiple unprefixed classes through character references and verify the output no longer adds attacker-controlled class names. Inspect generated HTML for code elements and confirm class attributes are limited to the expected safe format. For vendor-managed systems, verify installed package versions match or exceed the fixed SUSE package 5-150400.2.2 where that product is in scope.

Typical attack path

1. Find a public or authenticated feature that accepts user-supplied Markdown and displays rendered output to other users.
2. Confirm the application uses mdast-util-to-hast version 13.0.0 or later but earlier than 13.2.1, directly or through a Markdown rendering framework.
3. Craft Markdown containing character references in a location that is transformed into CSS class names for rendered code elements.
4. Use encoded separators to inject multiple unprefixed class names rather than a single safely prefixed language class.
5. Select class names that match the target application’s trusted UI styling, such as classes for normal body text, alerts, badges, buttons, or layout containers.
6. Publish or send the Markdown so victims view rendered attacker-controlled content that appears to be part of the legitimate page.

How to detect it

Look for evidence of suspicious Markdown submissions rather than server compromise, because this issue affects rendered content integrity. Review application logs, content moderation records, database exports of user-generated Markdown, audit trails for edited pages or comments, and web request logs for Markdown payloads containing HTML character references in code fence language/info strings or other fields that become CSS classes. Focus on encoded whitespace or separator-like references such as decimal or hexadecimal spaces and tabs. Inspect rendered HTML snapshots, cached pages, search indexes, and CDN caches for code elements or Markdown-rendered elements with unexpected multiple class names, especially classes matching trusted UI components. If abuse is suspected, identify who submitted or edited the Markdown, who viewed it, whether links or instructions were embedded nearby, and whether the content impersonated official notices, buttons, forms, warnings, or administrative messages. There are no known named threat actors or ransomware campaigns associated with this issue in the supplied intelligence.

• mdast-util-to-hast@13.0.0
• mdast-util-to-hast@13.0.1
• mdast-util-to-hast@13.0.2
• mdast-util-to-hast@13.1.0
• mdast-util-to-hast@13.2.0
• ```.* 
• ```.* 
• ```.* 
• ```.*	
• ```.*	
• ```.*	
• ```.*	
• class="language-.*
• className.*language-.*

What your security team should do

• Inventory applications and services that render user-supplied Markdown, especially public documentation, community, support, ticketing, chat, CMS, and developer portal features.
• Prioritize upgrades for internet-facing or multi-user applications where rendered Markdown is viewed by other users.
• Upgrade mdast-util-to-hast to 13.2.1 or later and rebuild production bundles, containers, and static assets that include the vulnerable dependency.
• Add or strengthen HTML sanitization and CSS class allowlisting for all user-generated Markdown output.
• Search stored Markdown content for suspicious character references in code block info strings or other class-generating Markdown fields.
• Create regression tests to ensure encoded separators cannot create multiple attacker-controlled CSS classes.
• Review UI components whose CSS classes could make user-generated content look like trusted alerts, buttons, administrative messages, or system notices.
• Because the issue is not in CISA KEV and has low EPSS, track remediation through normal patch SLAs unless the affected renderer is exposed to untrusted users at scale.