Markdown HTML Injection

How Markdown HTML injection works

Markdown html injection happens when a renderer allows raw HTML to pass through Markdown content without adequate sanitisation. The risk is not the Markdown syntax itself, but the trust placed in user-supplied text that the parser turns into active page markup.

In practice, the attack surface is broad because Markdown is often used in comment systems, wiki pages, issue trackers, documentation portals and chat tools. If the renderer preserves HTML tags, an attacker can reshape the document in ways that go far beyond ordinary formatting.

Why it is dangerous

The core danger is that content which appears to be plain text can become executable or deceptive page structure. That can include script execution, hidden or misleading links, form fields, iframe content, or layout manipulation that makes malicious content look trusted.

Even when scripts are blocked, injected HTML can still create phishing-style effects inside an otherwise legitimate application. Readers may click links, submit credentials, or follow instructions that were never intended by the content owner.

Where the exposure comes from

Exposure usually starts with user-generated Markdown that is rendered inside a browser or rich client. The issue becomes material when the application supports raw HTML, partially sanitises input, or applies sanitisation inconsistently across preview, saved content and rendered output.

Documentation systems, knowledge bases and collaboration tools are especially sensitive because content is repeatedly edited, quoted and embedded. A single unsafe renderer can turn a low-trust text field into a cross-user injection path that affects many readers.

Control and remediation focus

Defence depends on treating Markdown as untrusted input and enforcing a safe rendering policy. Where raw HTML is unnecessary, the strongest option is to disable it entirely; where it must be supported, sanitise allowed tags and attributes with a strict allowlist and keep the policy identical across all render paths.

It also helps to pair sanitisation with output encoding, CSP hardening and review of template behaviour, because unsafe composition often appears at the boundary between the Markdown engine and the surrounding page. For baseline application security guidance, OWASP Top 10 is a useful companion reference for understanding injection-style failures and their broader web application impact.

Risk and Threat Considerations

Markdown HTML injection can become a stored attack path when malicious markup is persisted and later rendered for many users. The same weakness can also support credential theft, interface spoofing, session abuse or defacement if the injected HTML changes page behaviour or misleads the reader.

Failure mechanism: The renderer trusts raw HTML embedded in Markdown or sanitises it incompletely, so attacker-controlled markup survives into the browser context.

Impact: The attacker can alter content, plant deceptive links or forms, and in some implementations trigger script execution or other browser-side abuse.

Related resources from NHI Mgmt Group

• Why does Angular template injection create XSS risk even when input is HTML-encoded?
• Why does markdown-based prompt injection create command execution risk in AI development environments?
• How should security teams prevent HTML injection when generating transactional emails from web applications?
• Why does HTML injection in an email create phishing risk from a legitimate domain?