Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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…
Recommended action: Upgrade to 8.0.13, 7.4.13 or 6.4.41 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 8.0.13, 7.4.13 or 6.4.41 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 8.0.12, 7.4.12 or 6.4.40 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 8.0.12, 7.4.12 or 6.4.40 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 8.0.12, 7.4.12 or 6.4.40 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.