PyPI · mistune
Mistune renderers/html.safe_url: HARMFUL_PROTOCOLS list misses legacy and chained schemes that historically chain to `javascript:` execution
Type: URL-scheme allowlist gap. The safe_url filter only blocks the four schemes javascript:, vbscript:, file:, data:. Several other schemes are accepted into rendered <a href="..."> and <img src="..."> tags despite being known XSS vectors in legacy or chain-handling browsers. The same gap applies to direct links, reference links, and autolinks.
File: src/mistune/renderers/html.py, line 11-23 (HARMFUL_PROTOCOLS list).
Root cause: the HARMFUL_PROTOCOLS tuple is a hardcoded, opt-out denylist of four entries. Browsers historically supported (and some still partially support) several other schemes that either execute JavaScript directly (livescript:, mocha:) or wrap a javascript: payload (feed:javascript:, view-source:javascript:, jar:javascript:, ms-its:javascript:, mk:@MSITStore:javascript:). On user-agents that still recognise these schemes (older Firefox builds for feed:/jar:, all Internet Explorer / Edge Legacy for ms-its:/mk:/res:, niche chrome-style browsers, browser extensions that register custom protocol handlers), clicking a link rendered by mistune executes attacker-controlled JavaScript in the page's origin.
File: src/mistune/renderers/html.py, lines 10-62.
class HTMLRenderer(BaseRenderer):
HARMFUL_PROTOCOLS: ClassVar[Tuple[str, ...]] = (
"javascript:",
"vbscript:",
"file:",
"data:",
) # <-- BUG: incomplete denylist
GOOD_DATA_PROTOCOLS: ClassVar[Tuple[str, ...]] = (
"data:image/gif;",
"data:image/png;",
"data:image/jpeg;",
"data:image/webp;",
)
def safe_url(self, url: str) -> str:
if self._allow_harmful_protocols is True:
return escape_text(url)
_url = url.lower()
if self._allow_harmful_protocols and _url.startswith(tuple(self._allow_harmful_protocols)):
return escape_text(url)
if _url.startswith(self.HARMFUL_PROTOCOLS) and not _url.startswith(self.GOOD_DATA_PROTOCOLS):
return "#harmful-link"
return escape_text(url) # <-- BUG: any scheme not in HARMFUL_PROTOCOLS passes through
Why it's wrong: an opt-out denylist for URL schemes is the wrong shape. The set of schemes a user-agent might honour is unbounded (registered handlers, browser extensions, OS-level protocol registrations, custom intent handlers on Android, etc.), but the set of schemes a markdown renderer needs to allow is small (http://, https://, mailto:, optionally tel:, ftp:, fragment-only #anchor, and a few image-only data: types). Switching to an opt-in allowlist with a safe_extra_protocols knob for callers who need others would close every variant of this bug class permanently. The current code accepts every chained-scheme XSS vector for as long as the project remembers to keep the denylist current.
escape=True prevents raw HTML, but link href/image src filtering is the only XSS defense for [click](...) and  syntax.[click here](feed:javascript:alert(document.cookie)). mistune's safe_url checks feed:javascript:alert(document.cookie) against HARMFUL_PROTOCOLS = ('javascript:', 'vbscript:', 'file:', 'data:') — none match. The href is escape_text'd (HTML-entity escape) and emitted as <a href="feed:javascript:alert(document.cookie)">click here</a>.javascript:alert(...). JS executes in the page's origin. Victim's session cookie is exfiltrated.livescript:alert(1) (Netscape Communicator era, still recognised by some niche browsers / browser-emulator tools), view-source:javascript:alert(1) (Firefox, see CVE-2009-1938), jar:javascript:alert(1) (older Firefox), ms-its:javascript: (IE/Edge Legacy), res:javascript: (IE), mk:@MSITStore:javascript: (IE CHM viewer). Each user-agent that recognises one of these is exploitable; the user-agent population that recognises at least one is not negligible (corporate environments still running Edge Legacy compatibility mode, locked-down kiosk browsers, Android WebView in apps that register custom intent handlers, Linux distros with old Firefox ESR plus the feed: extension, etc.).The same primitive applies to image src ( rendered as <img src="feed:...">) — though most browsers don't fetch javascript: from img src, the same chained handler quirk applies on a few user-agents — and to reference links and autolinks (verified in the PoC below; the rendered HTML is identical regardless of which markdown link syntax is used).
Severity: sec-moderate. Conditional XSS depending on user-agent. Modern Chrome / Edge Chromium / Safari ignore most of these schemes, but Firefox forks, Edge Legacy, in-app WebViews, browser extensions registering custom handlers, and corporate browser deployments are exposed. Defence-in-depth is the framing: a markdown renderer should not need to track which browsers still honour which legacy chained-scheme. Attacker capability: plant a link in any place the application renders user-supplied markdown. When clicked by a user-agent that honours the legacy scheme, the attacker's JavaScript runs in the page's origin (steal cookies, perform actions as the victim, etc.). Preconditions: application uses mistune to render attacker-influenced markdown. Default config. Victim user-agent is one of the affected populations. No specific mistune option is required. Differential: PoC-verified against mistune@3.2.1, default config. The following inputs all PASS the filter and reach the rendered HTML unchanged:
import mistune
md = mistune.create_markdown()
for url in [
'feed:javascript:alert(1)', # Firefox feed handler chain
'livescript:alert(1)', # Netscape, niche browsers
'mocha:alert(1)', # Netscape, niche browsers
'view-source:javascript:alert(1)', # Firefox view-source chain (CVE-2009-1938 class)
'jar:javascript:alert(1)', # Firefox jar: handler chain
'ms-its:javascript:alert(1)', # IE/Edge Legacy InfoTech Storage handler
'mk:@MSITStore:javascript:alert(1)', # IE CHM viewer chain
'res:javascript:', # IE resource: handler
]:
print(md(f'[click]({url})').strip())
# Output (each one passes the filter):
# <p><a href="feed:javascript:alert(1)">click</a></p>
# <p><a href="livescript:alert(1)">click</a></p>
# <p><a href="mocha:alert(1)">click</a></p>
# <p><a href="view-source:javascript:alert(1)">click</a></p>
# <p><a href="jar:javascript:alert(1)">click</a></p>
# <p><a href="ms-its:javascript:alert(1)">click</a></p>
# <p><a href="mk:@MSITStore:javascript:">click</a></p>
# <p><a href="res:javascript:">click</a></p>
For comparison, the four schemes already in the denylist are correctly blocked: javascript:, vbscript:, file:, data:text/html all return <a href="#harmful-link">.
The same gap applies to reference links ([click][ref]\n\n[ref]: feed:javascript:alert(1) → <a href="feed:javascript:alert(1)">) and to autolinks (<feed:javascript:alert(1)> → <a href="feed:javascript:alert(1)">).
Switch from denylist to allowlist. The set of schemes a markdown renderer needs to allow is small and well-known; the set of schemes that might trigger handler chains is unbounded.
--- a/src/mistune/renderers/html.py
+++ b/src/mistu
Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.