Symfony UX is a JavaScript ecosystem for Symfony. From 2.2.0 until 2.36.0 and 3.1.0, the Stimulus controller in symfony/ux-autocomplete renders AJAX response items in _createAutocompleteWithRemoteData() by interpolating the text field into HTML template literals (<div>${item[labelField]}</div>) rather than text, allowing attacker-controlled markup from user-supplied dropdown values to execute in the browser of any user who opens an autocomplete widget backed by the same data. This issue is fixed in versions 2.36.0 and 3.1.0.

Affected: Packagist: symfony/ux-autocomplete

### 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](https://github.com/symfony/ux/commit/842ae54bc74de389299f975f01aafae272cb0019) 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.