Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 optionsashtml: true. The AutocompleteChoiceTypeExtension normalizer that previously forced…
Recommended action: Upgrade to 3.1.0 or 2.36.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Symfony\UX\Autocomplete\Doctrine\EntitySearchUtil::addSearchClause() builds the LIKE expression used by the autocomplete endpoint by wrapping the client-supplied query in %...% without escaping the SQL LIKE wildcards (%, , \). The value is passed as a bound parameter, so this is not SQL injection, but a client can send % to match every row or use as a single-character wildcard. Because searchablefields defaults to every property of the entity and the autocomplete endpoint is public by default (BaseEntityAutocompleteType ships with security = false), an unauthenticated user can turn the endpoint into a broad matcher or a blind boolean oracle against every column of the entity, including columns the application never intended to expose. Resolution EntitySearchUtil now escapes \, %, and in the user-supplied query with addcslashes() and appends an explicit ESCAPE '\' clause to the generated LIKE expression, so those characters are matched literally. The exact-match wordsquery…
Recommended action: Upgrade to 3.1.0 or 2.36.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Under certain circumstances, an attacker could successfully submit an entity id for an EntityType that is not part of the valid choices. Affected applications are any that use: A custom querybuilder option to limit the valid results; AND An EntityType with 'autocomplete' = true or a custom AsEntityAutocompleteField. Under this circumstance, if an id is submitted, it is accepted even if the matching record would not be returned by the custom query built with querybuilder. Patches The problem has been fixed in symfony/ux-autocomplete version 2.11.2. Workarounds Upgrade to version 2.11.2 or greater of symfony/ux-autocomplete or perform extra validation after submit to verify the selected option is valid.
Recommended action: Upgrade to 2.11.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.