CVE-2024-21535

What it actually does

markdown-to-jsx versions before 7.4.0 improperly sanitize the src property when converting Markdown to JSX/HTML, allowing attacker-controlled Markdown to produce a malicious iframe element. If rendered in a victim’s browser, the injected content can execute script in the context of the vulnerable application, enabling session theft, credential phishing, unauthorized actions as the victim, or manipulation of page content. The issue is a client-side cross-site scripting flaw and generally requires an application to accept, store, preview, or render untrusted Markdown using the affected library.

Why it matters to the business

Applications that render user-supplied Markdown may expose users to account takeover, data disclosure, fraudulent actions, and reputational damage if malicious content is viewed. The risk is highest for collaboration platforms, documentation portals, ticketing systems, comments, knowledge bases, CMS features, and any workflow where Markdown from one user is displayed to another. This vulnerability is not currently in CISA KEV, has low EPSS, and has no reported public exploit maturity in the provided data, but it has been public for a long time and should be remediated as part of normal dependency hygiene, especially in internet-facing or multi-user products.

How an attack unfolds

An attacker first identifies an application feature that accepts Markdown and renders it through a vulnerable version of markdown-to-jsx. The attacker submits Markdown that results in an iframe element with a crafted src value that bypasses the library’s sanitization. When another user views the rendered content, the browser loads or executes attacker-controlled content in a way that can run JavaScript or present deceptive UI. The attacker can then steal tokens or session-related data accessible to script, capture credentials through phishing overlays, or perform actions using the victim’s authenticated browser session. If the vulnerable Markdown is stored, the attack can persist and affect every user who views the malicious content until the content is removed or sanitized.

How to fix it

Upgrade markdown-to-jsx to version 7.4.0 or later. For source builds from quantizor/markdown-to-jsx, ensure the code includes fixed commit 8eb74da825c0d8d2e9508d73c672bcae36ba555a or a later trusted commit. Rebuild and redeploy all applications and front-end bundles that include the vulnerable dependency, including transitive dependency instances. If immediate upgrade is not possible, disable raw HTML rendering in Markdown where feasible, block iframe rendering from untrusted Markdown, enforce allowlist-based URL sanitization for iframe src values, and apply a restrictive Content Security Policy that prevents javascript: URLs, untrusted frame sources, inline script execution, and unauthorized network exfiltration. Review and clean existing user-generated Markdown content for malicious iframe payloads after patching.

How to confirm the fix worked

Confirm dependency inventory shows markdown-to-jsx version 7.4.0 or later, or that the deployed source includes commit 8eb74da825c0d8d2e9508d73c672bcae36ba555a or later. Check package-lock.json, yarn.lock, pnpm-lock.yaml, SBOMs, bundled artifacts, and container images for older versions. Run software composition analysis against all applications that render Markdown. Perform a safe security regression test by submitting benign Markdown containing iframe-like constructs and verifying that unsafe iframe src values are removed, encoded, blocked, or rendered inert. Validate that deployed Content Security Policy blocks untrusted frame sources and script execution paths. Confirm any previously stored malicious Markdown has been removed or neutralized.

Typical attack path

1. Find an application feature that accepts Markdown input, such as comments, posts, documentation, issue descriptions, profile text, or message previews.
2. Confirm the application renders Markdown with markdown-to-jsx before version 7.4.0 or a vulnerable pre-fix commit.
3. Craft Markdown or embedded HTML that produces an iframe element with a malicious src property.
4. Submit or store the malicious Markdown in a location likely to be viewed by privileged or targeted users.
5. Wait for a victim to open the affected page or preview.
6. Execute JavaScript or attacker-controlled iframe content in the victim’s browser context.
7. Steal sensitive browser-accessible data, phish credentials, or perform authenticated actions as the victim.
8. Optionally maintain persistence by leaving the malicious Markdown in stored content or re-submitting it after removal.

How to detect it

To determine whether this was already exploited, review all places where user-supplied Markdown is stored, submitted, previewed, or rendered. Search application databases, content exports, object storage, audit logs, web access logs, WAF logs, and API request logs for iframe tags with suspicious src values, especially javascript:, data:text/html, blob:, encoded characters, or references to unfamiliar external domains. Correlate suspicious Markdown submissions with subsequent page views by other users and then review authentication logs, session events, password changes, MFA changes, API token creation, profile changes, admin actions, and anomalous requests from the affected users shortly after exposure. Browser-side evidence may be limited unless CSP reports, frontend error telemetry, or RUM logs are collected; if available, look for CSP violations involving frame-src, child-src, script-src, or blocked javascript/data URL execution. Also inspect CDN and proxy logs for unexpected outbound requests initiated from pages that render Markdown content. Because XSS payloads are frequently obfuscated, include URL-decoded, HTML-decoded, mixed-case, and Unicode-normalized searches.

• <iframe
• </iframe>
• iframe src=
• iframe%20src
• %3Ciframe
• &lt;iframe
• src="javascript:
• src='javascript:
• src=javascript:
• javascript:alert
• javascript:fetch
• javascript:eval
• javascript:document.cookie
• data:text/html
• src="data:text/html
• src='data:text/html
• srcdoc=
• onload=
• onerror=
• document.cookie
• localStorage
• sessionStorage
• postMessage(
• fetch(
• XMLHttpRequest
• navigator.sendBeacon
• <iframe src="javascript:
• <iframe src='javascript:
• <iframe src="data:text/html
• <iframe src='data:text/html
• markdown-to-jsx@7.3
• markdown-to-jsx@7.2
• markdown-to-jsx@7.1
• markdown-to-jsx@7.0
• "markdown-to-jsx": "7.3
• "markdown-to-jsx": "7.2
• "markdown-to-jsx": "7.1
• "markdown-to-jsx": "7.0
• "markdown-to-jsx": "^7.3
• "markdown-to-jsx": "^7.2
• "markdown-to-jsx": "^7.1
• "markdown-to-jsx": "^7.0

What your security team should do

• Inventory applications that accept and render user-supplied Markdown, prioritizing internet-facing, multi-tenant, collaboration, support, documentation, CMS, and admin-facing workflows.
• Upgrade markdown-to-jsx to 7.4.0 or later, or to a build containing commit 8eb74da825c0d8d2e9508d73c672bcae36ba555a or later.
• Search source repositories, lockfiles, SBOMs, containers, and deployed bundles for vulnerable markdown-to-jsx versions before 7.4.0.
• Add server-side or rendering-layer sanitization that allowlists safe HTML tags, attributes, and URL schemes; do not rely solely on client-side controls.
• Disable or strictly restrict iframe support in untrusted Markdown unless there is a documented business requirement.
• Deploy or tighten Content Security Policy, especially frame-src, child-src, script-src, object-src, base-uri, and form-action directives.
• Search stored Markdown content and application logs for suspicious iframe payloads, javascript: URLs, data: HTML payloads, and encoded variants.
• Add regression tests for Markdown XSS payloads to prevent reintroduction during dependency upgrades or renderer changes.
• Monitor authentication, session, and user-action logs for unusual activity following views of pages containing suspicious Markdown.