### 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.
### 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.
Update symfony/ux-autocomplete to 2.36.0; symfony/ux-autocomplete to 3.1.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scansymfony/ux-autocomplete: XSS via unescaped AJAX response data affects symfony/ux-autocomplete (composer), symfony/ux-autocomplete (composer). Severity is medium. ### 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.
AI coding agents often install or upgrade packages automatically in composer. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| symfony/ux-autocompletecomposer | >=2.2.0,<2.36.0 | 2.36.0 |
| symfony/ux-autocompletecomposer | >=3.0.0,<3.1.0 | 3.1.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate symfony/ux-autocomplete to 2.36.0; symfony/ux-autocomplete to 3.1.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scansymfony/ux-autocomplete: XSS via unescaped AJAX response data affects symfony/ux-autocomplete (composer), symfony/ux-autocomplete (composer). Severity is medium. ### 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.
AI coding agents often install or upgrade packages automatically in composer. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| symfony/ux-autocompletecomposer | >=2.2.0,<2.36.0 | 2.36.0 |
| symfony/ux-autocompletecomposer | >=3.0.0,<3.1.0 | 3.1.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard