https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 18:55:40 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-339078 EUVD-2026-339078 https://cve.radiocsirt.org/vuln/euvd-2026-339078 https://cve.radiocsirt.org/vuln/fkie_cve-2026-49216 <p>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 (&lt;div&gt;${item[labelField]}&lt;/div&gt;) 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.</p> <p>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 (&lt;div&gt;${item[labelField]}&lt;/div&gt;) 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.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-49216 https://cve.radiocsirt.org/vuln/ghsa-mwqm-4fw3-cjvr <p><strong>Affected:</strong> Packagist: symfony/ux-autocomplete</p> <p>### Description</p> <p>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 (`&lt;div&gt;${item[labelField]}&lt;/div&gt;`) inside `_createAutocompleteWithRemoteData()`. The value is parsed as HTML rather than text, so any markup contained in the AJAX response is executed by the browser.</p> <p>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.</p> <p>### Resolution</p> <p>The `option` and `item` renderers used in `_createAutocompleteWithRemoteData()` now use TomSelect&#39;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.</p> <p>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).</p> <p>### Credits</p> <p>Symfony would like to thank Alex Ashkov for reporting the issue and Hugo Alliaume for providing the fix.</p> <p><strong>Affected:</strong> Packagist: symfony/ux-autocomplete</p> <p>### Description</p> <p>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 (`&lt;div&gt;${item[labelField]}&lt;/div&gt;`) inside `_createAutocompleteWithRemoteData()`. The value is parsed as HTML rather than text, so any markup contained in the AJAX response is executed by the browser.</p> <p>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.</p> <p>### Resolution</p> <p>The `option` and `item` renderers used in `_createAutocompleteWithRemoteData()` now use TomSelect&#39;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.</p> <p>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).</p> <p>### Credits</p> <p>Symfony would like to thank Alex Ashkov for reporting the issue and Hugo Alliaume for providing the fix.</p> https://cve.radiocsirt.org/vuln/ghsa-mwqm-4fw3-cjvr