CVE-2026-55877: Symfony UX Icon XSS Vulnerability – Patch & Mitigation Guide
Symfony UX, a popular JavaScript framework for the Symfony PHP framework, contains a cross-site scripting (XSS) vulnerability in how it renders SVG icons. The ux_icon() Twig function treats icon content as safe HTML without sanitizing it first. This means if an SVG file or icon data from the Iconify service contains malicious code—such as embedded script tags or event handlers—that code will execute in a user's browser. An attacker could exploit this by serving a malicious SVG or by compromising icon sources to run unauthorized JavaScript in the context of the affected application.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 6.1 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
- Weaknesses (CWE)
- CWE-79
- Affected products
- 0 configuration(s)
- Published / Modified
- 2026-07-08 / 2026-07-10
NVD description (verbatim)
Symfony UX is a JavaScript ecosystem for Symfony. From 2.17.0 before 2.36.1 and from 3.0.0 before 3.2.0, the ux_icon() Twig function is marked is_safe=['html'] and Icon::toHtml() inlines SVG source verbatim, allowing unsanitized local SVG files or Iconify on-demand JSON body responses containing nested script elements, on* event handlers, or dangerous URL schemes to execute cross-site scripting. This issue is fixed in versions 2.36.1 and 3.2.0.
4 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
The vulnerability stems from the Icon::toHtml() method in Symfony UX inlining SVG content verbatim while the ux_icon() Twig function is marked with is_safe=['html']. This combination means the rendered output bypasses Twig's automatic escaping. Unsanitized SVG sources—whether local files or responses from Iconify's on-demand JSON API—can contain XSS payloads including nested <script> elements, on* event handlers (onclick, onload, etc.), or dangerous URL schemes (javascript:, data:). The vulnerability affects versions 2.17.0 through 2.36.0 and 3.0.0 through 3.1.x. Remediation requires proper HTML sanitization before rendering or careful validation of all icon sources.
Business impact
This vulnerability allows attackers to execute arbitrary JavaScript within the security context of web applications using affected Symfony UX versions. Successful exploitation could lead to session hijacking, credential theft, malware distribution, defacement, or unauthorized actions performed on behalf of legitimate users. The attack requires user interaction (clicking a page with a malicious icon), but the network-accessible nature of icon sources—especially third-party services like Iconify—expands the attack surface. For organizations relying on dynamic icon loading from external sources, the risk is particularly acute.
Affected systems
Symfony UX versions 2.17.0 through 2.36.0 and 3.0.0 through 3.1.x are vulnerable. Any Symfony application using the ux_icon() Twig function to render icons is at risk, particularly those that load icons from untrusted or dynamic sources such as user-uploaded files, external icon libraries (like Iconify), or configurable URLs. Applications that load icons exclusively from trusted, statically defined local files have reduced but not eliminated risk if those files could be modified.
Exploitability
Exploitation requires crafting or compromising an SVG source containing XSS payload. For local files, an attacker would need write access or the ability to influence which SVG file is loaded. For Iconify integration, an attacker could attempt to compromise the service, perform a man-in-the-middle attack on the connection, or trick the application into requesting a malicious icon via URL manipulation. Once a malicious SVG is loaded, the XSS executes automatically without additional user action beyond visiting the affected page. The CVSS score of 6.1 (MEDIUM) reflects network accessibility and low attack complexity, mitigated by the requirement for user interaction and limited impact scope.
Remediation
Upgrade to Symfony UX version 2.36.1 or 3.2.0 or later, which includes proper HTML sanitization in the Icon rendering pipeline. Prior to patching, implement additional mitigations: validate all SVG sources against a strict whitelist, sanitize SVG content using a library like DOMPurify or similar HTML sanitization tools before passing to ux_icon(), disable dynamic icon loading from untrusted sources, and use Content Security Policy (CSP) headers to restrict inline script execution. If using Iconify, ensure the connection is HTTPS and monitor for unexpected icon changes.
Patch guidance
Apply Symfony UX updates immediately: upgrade to version 2.36.1 if running 2.x, or version 3.2.0 if running 3.x. Verify the patch via your Composer dependencies and test icon rendering in your application before deploying to production. Check Symfony's official security advisory for any additional migration notes or behavioral changes in the patched versions.
Detection guidance
Search application logs and network traffic for requests to ux_icon() or icon rendering endpoints with suspicious SVG payloads containing <script>, event handler attributes (on*=), or javascript: schemes. Monitor for unusual icon source modifications or unexpected Iconify API requests. Code review: audit all ux_icon() calls to identify which icons are user-controlled or sourced from external APIs. Runtime detection via WAF rules can flag SVG responses containing script tags or event handlers intended for icon rendering endpoints.
Why prioritize this
Although classified as MEDIUM severity, this vulnerability should be prioritized for patching because it affects a widely-used Symfony component and can lead to account compromise or data theft. Organizations using Symfony UX for icons—especially those with dynamic or third-party icon sources—face immediate XSS risk. The fix is straightforward (version upgrade), and the attack surface is broad in modern web applications where icons are ubiquitous. Early patching reduces the window for opportunistic exploitation.
Risk score, explained
The CVSS 3.1 score of 6.1 reflects: network-accessible attack vector (AV:N), low attack complexity (AC:L), no privilege requirement (PR:N), and required user interaction (UI:R). Impact is limited to confidentiality and integrity (C:L/I:L) with no availability impact (A:N), and scope changes (S:C) because the XSS occurs in the user's browser context. The MEDIUM rating appropriately captures a real but mitigated threat; remediation is straightforward, but the functional nature of icon rendering means many applications are affected.
Frequently asked questions
Does this affect applications that only use built-in Symfony icons?
Risk is lower for applications using only statically defined, built-in icons from trusted sources. However, if the icon path can be influenced by user input or configuration, the vulnerability remains exploitable. Review how icon sources are determined in your application.
Is there a workaround if we cannot patch immediately?
Yes. Sanitize SVG content before passing to ux_icon() using a library like DOMPurify, validate icon sources against a strict whitelist, disable dynamic icon loading, and implement restrictive Content Security Policy headers to mitigate inline script execution. These are defensive measures, not replacements for patching.
Does the Iconify service itself require compromise for exploitation?
Not necessarily. An attacker can exploit this vulnerability via man-in-the-middle attacks on unencrypted connections, DNS hijacking, or by manipulating the icon URL that the application requests (if user-controlled). Ensure your application uses HTTPS for all icon requests and does not allow user-controlled icon URLs.
How does this differ from a typical XSS vulnerability?
This is a stored or server-side rendering XSS rather than reflected XSS. The malicious SVG can be persistent (stored file) or dynamic (API response), and the rendering happens server-side by Symfony before being sent to the client, meaning client-side protections offer limited defense. This makes it more predictable to exploit and harder to defend against without server-side fixes.
This analysis is based on the CVE description and CVSS vector provided as of the publication date. Vendor details, patch timelines, and affected product versions should be verified against official Symfony security advisories and your specific deployments. This explainer does not constitute security advice for your specific environment; assess risk based on your actual icon sources, user exposure, and Symfony UX usage patterns. No exploit code or weaponized proof-of-concept is provided. Always test patches in non-production environments before deployment. Source: NVD (public-domain), retrieved 2026-08-17. Analysis generated by SEC.co (claude-haiku-4-5).
Weaknesses (CWE)
Related vulnerabilities
- CVE-2016-20070MEDIUMPrivilege Escalation & Stored XSS in WordPress Booking Calendar Contact Form 1.0.23
- CVE-2018-25384MEDIUMStored XSS in Wikidforum 2.20 Allows Authenticated Attackers to Inject Malicious Scripts
- CVE-2019-25731MEDIUMStored XSS in Zuz Music 2.1 Contact Form
- CVE-2019-25737MEDIUMStored XSS in Live Chat Unlimited 2.8.3 – Admin Session Compromise
- CVE-2019-25739MEDIUMGigToDo 1.3 Stored XSS Vulnerability in Proposal Descriptions
- CVE-2019-25742MEDIUMStored XSS in Zoner Real Estate WordPress Theme 4.1.1 – Admin Account Compromise Risk
- CVE-2019-25743MEDIUMWordPress Soliloquy Lite 2.5.6 Stored XSS Vulnerability
- CVE-2019-25744MEDIUMWordPress Popup Builder 3.49 Stored XSS Vulnerability – Exploit Prevention & Patch Guide