symfony/ux-icons: XSS via unsanitized SVG content in local files and Iconify on-demand responses

Description

### Description The `ux_icon()` Twig function is marked `is_safe=['html']`, so Twig never escapes its output. `Icon::toHtml()` inlines the SVG source verbatim into the page. Browsers execute `<script>` elements and `on*` event-handler attributes found inside inline SVG, making any unsanitized icon a vector for cross-site scripting. Two code paths were affected. In the local file path, `Icon::fromFile()` only stripped `<script>` elements that were direct children of `<svg>`, leaving nested scripts and all `on*` attributes untouched despite a code comment claiming broader protection. In the Iconify on-demand path (enabled by default), the remote JSON `body` field was wrapped into an `Icon` object with no sanitization at all. Concrete attack vectors include a malicious SVG icon pack from a third-party theme or downloaded icon set, or a controlled Iconify endpoint configured via `iconify.endpoint` (including a poisoned cache). ### Resolution Introducing an `IconFactory` that centralizes sanitization across every icon source before an `Icon` object is created. The sanitizer removes script-capable elements (`script`, `foreignObject`, `iframe`, `object`, `embed`), SMIL animations targeting `on*`, `href`, or `xlink:href` attributes, CDATA sections, processing instructions, all `on*` attributes, and `javascript:`, `vbscript:`, and `data:text/html` URL schemes. `<style>` elements are kept for theming but have any handlers stripped. Icons that contain none of these constructs are byte-for-byte identical after sanitization. ### Credits Symfony would like to thank Pascal Cescon for reporting the issue and Hugo Alliaume for providing the fix.

Affected Packages (1)