symfony/ux · Security

symfony/ux-autocomplete: XSS via unescaped AJAX response data

GHSA ID
GHSA-mwqm-4fw3-cjvr
CVE ID
CVE-2026-49216
Severity
medium
Published
Updated
CVSS v4
5.1 · CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N

Description

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 options_as_html: true. The AutocompleteChoiceTypeExtension normalizer that previously forced options_as_html=false when autocomplete_url 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.

CWEs

References