Description
Symfony\Component\HtmlSanitizer\TextSanitizer\UrlSanitizer::parse() (used by UrlSanitizer::sanitize() and therefore by every HtmlSanitizer config that allows links or media) accepts URLs that contain Unicode explicit-direction BiDi formatting characters: U+202A–U+202E (LRE / RLE / PDF / LRO / RLO) and U+2066–U+2069 (LRI / RLI / FSI / PDI). These characters are passed through unchanged into the href / src attributes produced by HtmlSanitizer. When the resulting HTML is rendered in a browser, the override characters reverse or alter the visual ordering of the URL text, so the displayed link can differ arbitrarily from the actual destination: a classic visual-spoofing / phishing primitive against viewers of sanitized content.
Resolution
UrlSanitizer::parse() now rejects URLs containing the explicit-direction BiDi formatting code points (U+202A–U+202E, U+2066–U+2069) before invoking the underlying URL parser. As an unrelated companion fix in the same patch, spaces inside path/query/fragment are now percent-encoded rather than rejected outright, while spaces in the scheme/authority remain rejected by the post-encoding whitespace check.
The patch for this issue is available here for branch 5.4.
Credits
Symfony would like to thank Himanshu Anand for reporting the issue and Nicolas Grekas for providing the fix.
Description
Symfony\Component\HtmlSanitizer\Visitor\AttributeSanitizer\UrlAttributeSanitizer::getSupportedAttributes() enumerates the attribute names whose values are scrubbed through UrlSanitizer::sanitize() (scheme and host allow-lists, javascript: rejection, BiDi check, etc.). The list is ['src', 'href', 'lowsrc', 'background', 'ping', 'action', 'formaction', 'poster', 'cite']. Other URL-bearing attributes are absent: <object data=…>, <applet codebase=…>, <applet archive=…> and <object archive=…>, <iframe longdesc=…> and <img longdesc=…>. When an integrator opts these elements/attributes in via allowElement('object', ['data']), allowElement('applet', ['codebase']), etc., or via allowAttribute(), no URL sanitization runs: data="javascript:alert(1)" and similar payloads ship through unchanged into the output, enabling stored XSS.
<meta http-equiv="refresh" content="0; url=…"> is the same class of bug routed differently: the URL is embedded inside a multi-field content attribute that the per-attribute sanitizer cannot detect from the attribute name alone. Integrators who enable <meta> with the content attribute (e.g. via allowStaticElements()) see content="0; url=javascript:alert(1)" pass through, producing a refresh-driven navigation to a javascript: URL.
Default configurations are not affected: <object>, <applet> and <iframe> are not in W3CReference::BODYELEMENTS and <meta> requires an explicit opt-in to <head> context. The vulnerability surface is integrators who explicitly allow any of those elements together with the listed URL-bearing attributes.
Resolution
UrlAttributeSanitizer now also routes data, codebase, archive and longdesc through UrlSanitizer::sanitize(). A new MetaRefreshAttributeSanitizer registered as a default attribute sanitizer detects the <delay>; url=<url> syntax inside <meta content>, sanitizes the embedded URL, and drops the attribute if the URL is rejected; non-refresh meta content values are passed through unchanged.
The patches for this issue are available here for branch 6.4 (and forward-ported to 7.4, 8.0 and 8.1).
Credits
Symfony would like to thank Scott Arciszewski (Trail of Bits) for reporting the issue and Nicolas Grekas for providing the fix.
Description
symfony/html-sanitizer lets applications sanitise untrusted HTML. The configuration methods allowLinkHosts([...]) and allowLinkSchemes([...]) are intended to restrict <a href> targets to an allowlist of hosts/schemes; allowMediaHosts() / allowMediaSchemes() do the same for <img src> etc.
Three distinct bypasses allow a content author to smuggle off-allowlist URLs past these checks. First, UrlSanitizer::parse() parses the input following RFC-3986, while browsers follow the WHATWG URL Standard which normalises \ to / before parsing the authority of "special" schemes; so an input like https://evil\@trusted.com/ parses with host trusted.com server-side but navigates to https://evil/ in the browser. Second, WHATWG collapses any run of / after the scheme into //, while RFC-3986 does not; so https:/evil.com/ and https:///evil.com/ parse as host-less (skipping the host allowlist) but resolve to evil.com in the browser. Third, UrlAttributeSanitizer checks 'a' === $element to route to the link policy and falls through to the media policy otherwise, but <area> is a navigable hyperlink equivalent to <a>; so <area href> was sanitised against the media policy (which typically allows data: and may have no host allowlist), bypassing allowLinkHosts() / allowLinkSchemes() entirely.
Resolution
UrlSanitizer::sanitize() now rejects URLs that contain a backslash or that use a special scheme (http, https, ftp, ws, wss) followed by a single slash or three slashes before parsing, eliminating the parser-differential bypasses. UrlAttributeSanitizer now applies the link policy to both <a> and <area> elements.
The patch for this issue is available here for branch 5.4.
Credits
Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.
Description
Symfony\Component\HtmlSanitizer\TextSanitizer\UrlSanitizer::parse() rejects URLs containing raw Unicode explicit-direction BiDi formatting characters (U+202A–U+202E, U+2066–U+2069) as a defense against visual-spoofing of the rendered href. The check covers only the raw UTF-8 forms of those code points: the percent-encoded forms (%E2%80%AE for U+202E, %E2%81%A6 for U+2066, etc.) are not matched by the deny regex, survive league/uri's parse/build cycle, and are re-emitted unchanged in the sanitized URL. Any downstream consumer that decodes the link before display — phishing-detection filters that compare urldecode($href) against a domain allow-list, audit-log dashboards that show a decoded form for readability, hover-tooltip previews, federated/syndicated content where the decoder lives on the consuming side — restores the BiDi character and the visual spoof that the original defense was filed to prevent.
The same UrlSanitizer::parse() carries an ASCII-only /\s/ whitespace check (no /u modifier) intended as a backstop against malformed URLs. Without the /u modifier, PCRE's \s matches only ASCII whitespace, so Unicode whitespace characters — NBSP (U+00A0), the zero-width no-break space / BOM (U+FEFF), line/paragraph separators (U+2028, U+2029), ogham space (U+1680), the U+2000–U+200A en/em quad family, narrow / medium / ideographic spaces (U+202F, U+205F, U+3000) and NEL (U+0085) — pass through unchanged in both raw and percent-encoded forms. In hostname positions they enable lookalike spoofs (example<NBSP>.com); in path/query/fragment they enable allow-list drift when a downstream consumer strips whitespace before comparison.
Resolution
UrlSanitizer::parse() now denies BiDi formatting marks together with Unicode whitespace and the zero-width no-break space, in both the raw input and the percent-decoded form of each parsed URL component (user, pass, host, path, query, fragment). ASCII space remains tolerated in path/query/fragment via the existing percent-encoding step.
The patches for this issue are available here for branch 6.4 (and forward-ported to 7.4, 8.0 and 8.1).
Credits
Symfony would like to thank Scott Arciszewski (Trail of Bits) for reporting the issue and Nicolas Grekas for providing the fix.
Description
symfony/html-sanitizer lets applications sanitise untrusted HTML. UrlAttributeSanitizer is the visitor responsible for validating URL-valued attributes and stripping dangerous schemes from them; it runs on every element regardless of configuration. Whether an attribute is kept is decided by the element/attribute allow-list; validating the scheme of a URL attribute is solely UrlAttributeSanitizer's responsibility.
UrlAttributeSanitizer::getSupportedAttributes() returned only ['src', 'href', 'lowsrc', 'background', 'ping']. The HTML URL-valued attributes action (<form>), formaction (<button>, <input type=image>), poster (<video>) and cite (<blockquote>, <q>, <del>, <ins>) were missing from that list, so DomVisitor never invoked scheme validation for them. As a result, when a configuration admits one of those attributes, a javascript: URI in it survived sanitisation.
Conditions for exploitation
allowSafeElements() is not affected: <form> and the formaction attribute are both flagged unsafe in W3CReference, and allowElement('form') resets the element's attribute list. Reaching the vulnerable attributes requires a deliberately permissive configuration, for example:
<form> + action: allowElement('form', ''), allowElement('form', ['action', …]), allowElement('form')->allowAttribute('action', 'form'), or the allowStaticElements() preset (whose docblock already warns the output "may still contain other dangerous behaviors"); <button> / <input type=image> + formaction: allowElement(…, ''), allowAttribute('formaction', …), or allowStaticElements(); <blockquote> / <q> / <del> / <ins> + cite, or <video> + poster: similarly via '', allowAttribute(), or allowStaticElements().
For the action / formaction cases the victim must additionally submit the form or click the button.
Resolution
UrlAttributeSanitizer now also handles action, formaction, cite and poster. action / formaction / cite are validated against the link schemes (like <a href>, so javascript: is rejected and data: is dropped too); poster is validated against the media schemes (so data: images keep working). The behaviour of <a href> and <img src> is unchanged.
One behaviour change to be aware of: a relative action="/submit" on an allowed <form> is now dropped by default (the same as <a href> / <img src> today); ->allowRelativeLinks() re-enables it.
The patch for this issue is available here for branch 6.4.
Credits
Symfony would like to thank Himanshu Anand and Rémi Pelloux for reporting the issue and Nicolas Grekas for providing the fix.