| Package | Affected versions | Patched versions |
|---|---|---|
| symfony/ux-autocomplete | ≥ 2.2.0, < 2.36.0≥ 3.0.0, < 3.1.0 | 2.36.03.1.0 |
| ux | = 3.0.0≥ 2.2.0, < 2.36.0 | 2.36.0 |
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.
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).
Symfony would like to thank Alex Ashkov for reporting the issue and Hugo Alliaume for providing the fix.
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site free