EUVD-2026-45214
GHSA-946h-jp5c-8fvh
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-accessible by default with no authentication (PR:N, AV:N); impact is partial confidentiality disclosure only (C:L), with no integrity or availability consequence.
Primary rating from Vendor (https://github.com/symfony/ux).
CVSS VectorVendor: https://github.com/symfony/ux
Lifecycle Timeline
3DescriptionCVE.org
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.
AnalysisAI
Unescaped SQL LIKE wildcards in symfony/ux-autocomplete allow unauthenticated network attackers to turn the autocomplete endpoint into a broad data matcher or blind boolean oracle against all entity columns. Because BaseEntityAutocompleteType defaults to security => false and searchable_fields defaults to all entity properties, versions >= 2.2.0 < 2.36.0 and >= 3.0.0 < 3.1.0 expose potentially sensitive entity data to any caller who sends % or _ as the query parameter. No public exploit has been identified at time of analysis, but the attack requires only standard HTTP tooling; patches are available in 2.36.0 and 3.1.0.
Technical ContextAI
The vulnerability resides in Symfony\UX\Autocomplete\Doctrine\EntitySearchUtil::addSearchClause(), which constructs Doctrine ORM QueryBuilder LIKE expressions for the HTTP autocomplete search endpoint (pkg:composer/symfony/ux-autocomplete). User-supplied query strings are wrapped in %...% to produce substring matches but were not sanitized for SQL LIKE metacharacters (%, _, \). Although the value is passed as a bound PDO parameter - preventing SQL injection (CWE-89) - the LIKE pattern semantics remain fully active within the parameterized context, causing CWE-200 information exposure through improper output neutralization inside the query expression. The compound risk comes from two defaults: searchable_fields covering every entity property, and the endpoint shipping with security => false, making it publicly accessible without configuration changes.
RemediationAI
Upgrade symfony/ux-autocomplete to 2.36.0 (for 2.x deployments) or 3.1.0 (for 3.x deployments); the patch at https://github.com/symfony/ux/commit/725ab3d40689c91ff19ad2d01940a30007769214 escapes \, %, and _ in user input via addcslashes() and appends an explicit ESCAPE '\' clause to all generated LIKE expressions. If immediate upgrade is not possible, the highest-impact workaround is to explicitly set security to a Symfony voter or role (e.g., ROLE_USER) on every BaseEntityAutocompleteType subclass, which restricts the endpoint to authenticated users and eliminates the unauthenticated exposure - note this changes application UX for public-facing autocomplete fields. A secondary workaround is to explicitly define searchable_fields to include only non-sensitive columns, reducing the oracle surface even if the endpoint remains public; this does not fix the wildcard behavior but limits what data can be inferred.
Same weakness CWE-200 – Information Exposure
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today