Description
The uxicon() Twig function is marked issafe=['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.
Description
The Stimulus controller shipped with symfony/ux-autocomplete renders AJAX response items into the dropdown by interpolating the text field directly into HTML template literals (<div>${item[labelField]}</div>) inside createAutocompleteWithRemoteData(). The value is parsed as HTML rather than text, so any markup contained in the AJAX response is executed by the browser.
When the dropdown values are derived from user-supplied content, an attacker can craft a string that triggers stored XSS in the browser of any other user who later opens a page containing an autocomplete widget backed by the same data.
Resolution
The option and item renderers used in createAutocompleteWithRemoteData() now use TomSelect's escape helper to HTML-escape the value by default. Endpoints that legitimately return HTML (for example, to highlight the search term) can opt back in to the previous behavior by setting optionsashtml: true. The AutocompleteChoiceTypeExtension normalizer that previously forced optionsashtml=false when autocompleteurl was set has been dropped so the opt-in is reachable from the form layer.
The patch for this issue is available here for branch 2.x (and forward-ported to 3.x).
Credits
Symfony would like to thank Alex Ashkov for reporting the issue and Hugo Alliaume for providing the fix.
Description
When using symfony/ux-live-component, methods annotated with #[LiveAction] are invokable from the browser and mutate server-side state via AJAX. Symfony\UX\LiveComponent\EventListener\LiveComponentSubscriber::isLiveComponentRequest() gated these invocations on the presence of Accept: application/vnd.live-component+html, with a code comment stating that this acted as a CSRF protection.
The Accept header is a CORS-safelisted request header, so a cross-origin fetch() can set it without triggering a preflight. The header therefore provided no CSRF protection. Any #[LiveAction] could be forged cross-origin against a victim's session.
In practice the attack is mitigated by SameSite=Lax session cookies (Symfony's default), but applications using SameSite=None, credentials: 'include' with a permissive cookie policy, or that have been pivoted from another same-origin vector remained exposed.
Resolution
isLiveComponentRequest() now additionally requires the request header X-Requested-With: XMLHttpRequest. This header is not CORS-safelisted, so the browser issues a preflight OPTIONS request for any cross-origin attempt; Symfony does not advertise CORS for LiveComponent endpoints, the preflight fails, and the real request is blocked before it reaches the application. The bundled Stimulus client already sends X-Requested-With on every LiveComponent request (RequestBuilder.ts), so standard usage is unaffected. Cross-origin callers must add X-Requested-With to their CORS Access-Control-Allow-Headers allow-list.
The patch for this issue is available here for branch 2.x (and forward-ported to 3.x).
Credits
Symfony would like to thank Anthropic (via Project Glasswing) for reporting the issue and Hugo Alliaume for providing the fix.
Description
In symfony/ux-live-component, a component's server-side state is exposed to the browser as a set of props (#[LiveProp]-annotated properties). Props marked writable: true can be freely changed by the client. Read-only props are round-tripped to the browser and back, and their integrity is protected by an HMAC so the client cannot tamper with them. Child components additionally receive a propsFromParent blob, also HMAC-signed.
The HMAC computed by Symfony\UX\LiveComponent\LiveComponentHydrator covered only the sorted prop key/value pairs. It didn't include the component name, the slot identifier (props vs propsFromParent), or any request context, and a single application-wide secret is used for every component. A signed blob the server minted for component A is therefore a valid signature for component B if the key names happen to match, and a props blob can be replayed in the propsFromParent slot (or the reverse). An attacker can use this to set a read-only prop on a target component to a value they were only ever allowed to choose as a writable prop on another component.
Resolution
The HMAC is now bound to its context: the component name and a slot identifier are included in the pre-image before hashing. Two constants (CHECKSUMSLOTPROPS and CHECKSUMSLOTPROPSFROMPARENT) name the two slots, and calculateChecksum(), verifyChecksum(), addChecksumToData(), and ChildComponentPartialRenderer thread these values through. Cross-component and cross-slot replays no longer verify.
The patch for this issue is available here for branch 2.x (and forward-ported to 3.x).
Credits
Symfony would like to thank Anthropic (via Project Glasswing) for reporting the issue and Hugo Alliaume for providing the fix.
Description
Symfony\UX\Autocomplete\Doctrine\EntitySearchUtil::addSearchClause() builds the LIKE expression used by the autocomplete endpoint by wrapping the client-supplied query in %...% without escaping the SQL LIKE wildcards (%, , \). The value is passed as a bound parameter, so this is not SQL injection, but a client can send % to match every row or use as a single-character wildcard.
Because searchablefields defaults to every property of the entity and the autocomplete endpoint is public by default (BaseEntityAutocompleteType ships with security => false), an unauthenticated user can turn the endpoint into a broad matcher or a blind boolean oracle against every column of the entity, including columns the application never intended to expose.
Resolution
EntitySearchUtil now escapes \, %, and in the user-supplied query with addcslashes() and appends an explicit ESCAPE '\' clause to the generated LIKE expression, so those characters are matched literally. The exact-match wordsquery IN() branch is unchanged.
The patch for this issue is available here for branch 2.x (and forward-ported to 3.x).
Credits
Symfony would like to thank Pascal Cescon for reporting the issue and providing the fix.
Description
Symfony\UX\LiveComponent\Util\ChildComponentPartialRenderer::createHtml() interpolates the $childTag argument directly into the HTML output as a tag name, without escaping or validation. The value originates from client-controlled JSON (children[id].tag) parsed by LiveComponentSubscriber and propagated through InterceptChildComponentRenderSubscriber, so an attacker who can reach the Live Component endpoint can inject arbitrary HTML, including <script> tags, on any re-render of a Live Component that contains at least one child component.
In the default configuration, the Live Component endpoint is gated by an Accept: application/vnd.live-component+html request-header check that cannot be set cross-origin without a CORS preflight, so the issue is primarily a defense-in-depth gap. It becomes directly exploitable on applications that have relaxed CORS to allow this header from untrusted origins, or that have been pivoted from another same-origin XSS.
Resolution
ChildComponentPartialRenderer now validates $childTag against a strict HTML tag-name regex before interpolating it, and rejects any value that doesn't match. Anything that wouldn't be a valid HTML tag is dropped before reaching the response.
The patch for this issue is available here for branch 2.x (and forward-ported to 3.x).
Credits
Symfony would like to thank Pascal Cescon for reporting the issue and Hugo Alliaume for providing the fix.
Description
Symfony\UX\LiveComponent\Controller\BatchActionController::invoke() iterates over the client-supplied actions array and issues a full HttpKernel sub-request for each entry (event subscribers, validators, Doctrine, rendering). The array size is never bounded, so an authenticated client can submit a single batch request containing thousands of actions and exhaust CPU, memory, and database connections on the application server.
Resolution
BatchActionController now enforces an upper bound of 50 actions per batch request (MAXACTIONSPERBATCH) and rejects larger payloads up front with a BadRequestHttpException. The matching JavaScript backend was also updated to split larger client-side batches into multiple requests so legitimate usage isn't affected.
The patch for this issue is available here for branch 2.x (and forward-ported to 3.x).
Credits
Symfony would like to thank Pascal Cescon for reporting the issue and Hugo Alliaume for providing the fix.
Description
When a #[LiveProp] is typed as a DateTimeInterface and no explicit format is configured, Symfony\UX\LiveComponent\LiveComponentHydrator::hydrateObjectValue() falls back to new $className($value). The DateTime / DateTimeImmutable constructors accept relative strings such as "now", "tomorrow", or "+10 years", so a writable, format-less date prop can be pushed to an arbitrary point in time by the client. Components that rely on a date prop to gate time-based business logic can be moved past those checks by a frontend payload that no maintainer would consider a valid date.
Resolution
hydrateObjectValue() now parses format-less date props strictly with createFromFormat(DateTimeInterface::RFC3339, ...), matching the format already emitted by dehydrateObjectValue(). Normal round-trips are unaffected; only inputs that aren't valid RFC 3339 are now rejected, which is consistent with how a format-configured prop already behaved.
The patch for this issue is available here for branch 2.x (and forward-ported to 3.x).
Credits
Symfony would like to thank Pascal Cescon for reporting the issue and Hugo Alliaume for providing the fix.