CVE-2026-49211 — ux-autocomplete
Fix: symfony/ux@725ab3dCVE-2026-49211 is a Information Exposure vulnerability in symfony/ux-autocomplete. A fix is available for symfony/ux-autocomplete — see the affected versions and patch details below.
Symfony UX: Information exposure via unescaped LIKE wildcards in EntitySearchUtil
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-49211.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
symfony/ux-autocomplete🐘symfony/ux-autocompleteReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | symfony/ux-autocomplete | ≥ 2.2.0&&< 2.36.0 | 2.36.0composer require symfony/ux-autocomplete:^2.36.0 |
| 🐘Packagist | symfony/ux-autocomplete | ≥ 3.0.0&&< 3.1.0 | 3.1.0composer require symfony/ux-autocomplete:^3.1.0 |
Affected Products
uxsymfonyDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for symfony/ux-autocomplete, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update symfony/ux-autocomplete to 2.36.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-49211 is resolved across your whole dependency graph.
Workarounds
Until you can upgrade, make sure every query built from user input uses parameterised statements or a prepared-statement API rather than string concatenation, and reduce the database account's privileges so an injected query cannot read or alter data beyond what the feature needs.
Frequently Asked Questions
Is CVE-2026-49211 in your dependencies?
Find it across Packagist, including transitive dependencies.