Symfony UX Autocomplete CVE-2026-49211
MEDIUMSeverity by source
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.
Estimated by vuln.today — no official severity rating has been published for this CVE yet.
Lifecycle Timeline
2DescriptionCVE.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. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | The autocomplete endpoint must be reachable over the network, which is true by default because BaseEntityAutocompleteType ships with security => false - no authentication or session is required. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | No CVSS vector was provided; the assessed vector is independently derived. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An unauthenticated attacker sends an HTTP GET to the Symfony autocomplete endpoint (e.g., /autocomplete/product?query=%) and receives every row in the target entity table because the unescaped % wildcard matches all records. By iterating queries such as a_, b_, or ab_ to probe individual character positions, the attacker enumerates sensitive column values through a blind boolean oracle, comparing result counts or returned records to infer data not intended for public exposure. … |
| Remediation | 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. … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
Same weakness CWE-200 – Information Exposure
View allShare
External POC / Exploit Code
Leaving vuln.today