symfony/ux · Security
symfony/ux-autocomplete: Information exposure via unescaped LIKE wildcards in EntitySearchUtil
- GHSA ID
- GHSA-946h-jp5c-8fvh
- CVE ID
- CVE-2026-49211
- Severity
- medium
- Published
- Updated
- CVSS v4
- 6.3 · CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Description
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 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.
CWEs
- CWE-200 · Exposure of Sensitive Information to an Unauthorized Actor
References
- https://github.com/symfony/ux/security/advisories/GHSA-946h-jp5c-8fvh ↗
- https://github.com/symfony/ux/commit/725ab3d40689c91ff19ad2d01940a30007769214 ↗
- https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/ux-autocomplete/CVE-2026-49211.yaml ↗
- https://github.com/advisories/GHSA-946h-jp5c-8fvh ↗