### Description `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 `searchable_fields` 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 `words_query` `IN()` branch is unchanged. The patch for this issue is available [here](https://github.com/symfony/ux/commit/725ab3d40689c91ff19ad2d01940a30007769214) for branch 2.x (and forward-ported to 3.x). ### Credits Symfony would like to thank Pascal Cescon for reporting the issue and providing the fix.
### Description `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 `searchable_fields` 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 `words_query` `IN()` branch is unchanged. The patch for this issue is available [here](https://github.com/symfony/ux/commit/725ab3d40689c91ff19ad2d01940a30007769214) for branch 2.x (and forward-ported to 3.x). ### Credits Symfony would like to thank Pascal Cescon for reporting the issue and 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: Information exposure via unescaped LIKE wildcards in EntitySearchUtil affects symfony/ux-autocomplete (composer), symfony/ux-autocomplete (composer). Severity is medium. ### Description `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 `searchable_fields` 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 `words_query` `IN()` branch is unchanged. The patch for this issue is available [here](https://github.com/symfony/ux/commit/725ab3d40689c91ff19ad2d01940a30007769214) for branch 2.x (and forward-ported to 3.x). ### Credits Symfony would like to thank Pascal Cescon for reporting the issue and 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: Information exposure via unescaped LIKE wildcards in EntitySearchUtil affects symfony/ux-autocomplete (composer), symfony/ux-autocomplete (composer). Severity is medium. ### Description `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 `searchable_fields` 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 `words_query` `IN()` branch is unchanged. The patch for this issue is available [here](https://github.com/symfony/ux/commit/725ab3d40689c91ff19ad2d01940a30007769214) for branch 2.x (and forward-ported to 3.x). ### Credits Symfony would like to thank Pascal Cescon for reporting the issue and 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