Listen to this Post
The vulnerability exists in `Symfony\UX\Autocomplete\Doctrine\EntitySearchUtil::addSearchClause()` within the Symfony UX Autocomplete component. This method constructs a SQL `LIKE` expression used by the autocomplete endpoint by wrapping the client-supplied search query with `%…%` wildcards. However, it fails to escape the SQL `LIKE` wildcard characters — namely `%` (matches any sequence of characters), `_` (matches any single character), and `\` (the default escape character).
Because the user input is passed as a bound parameter rather than interpolated directly into the SQL string, this is not a SQL injection vulnerability in the traditional sense. Nevertheless, an attacker can send a query containing `%` to match every row in the underlying database table, or use `_` to perform single-character wildcard matching. This transforms the autocomplete endpoint into a broad data matcher.
Compounding the issue, `searchable_fields` defaults to every property of the entity being searched, and the autocomplete endpoint is public by default — `BaseEntityAutocompleteType` ships with security => false. As a result, an unauthenticated attacker can abuse the endpoint as a blind boolean oracle to probe every column of the entity, including sensitive columns that were never intended to be exposed to the frontend.
The fix, implemented in versions 2.36.0 and 3.1.0, escapes the \, %, and `_` characters using `addcslashes()` and appends an explicit `ESCAPE ‘\’` clause to the generated `LIKE` expression, ensuring these characters are matched literally rather than interpreted as wildcards. The exact-match `words_query IN()` branch remains unchanged. The patch was backported to the 2.x branch and forward-ported to 3.x. Pascal Cescon is credited with reporting the issue and providing the fix.
DailyCVE Form:
Platform: Symfony UX Autocomplete
Version: 2.2.0–2.35.0, 3.0.0
Vulnerability: Unescaped LIKE wildcards
Severity: Medium (CVSS 5.0)
date: 2026-05-29
Prediction: Already patched (2.36.0/3.1.0)
What Undercode Say:
Analytics:
- Affected Package: `symfony/ux-autocomplete`
– Total Downloads: ~5.7 million - Dependent Packages: 7
- Dependent Repositories: 37
- Attack Vector: Network
- Privileges Required: None
- User Interaction: None
Bash commands to check and update:
Check current version composer show symfony/ux-autocomplete Update to patched version (2.36.0 or 3.1.0+) composer require symfony/ux-autocomplete:^2.36.0 or for 3.x composer require symfony/ux-autocomplete:^3.1.0 Verify the update composer show symfony/ux-autocomplete
Exploit:
An attacker can send a search query containing `%` to the autocomplete endpoint to retrieve all records:
GET /autocomplete?query=% HTTP/1.1 Host: target.com
To perform blind boolean oracle attacks, the attacker can use `_` to test character positions:
GET /autocomplete?query=a_ HTTP/1.1 Matches "ab", "ac", etc. GET /autocomplete?query=a% HTTP/1.1 Matches anything starting with "a"
Because the endpoint is public and searches all entity properties, sensitive columns (e.g., email, password hash, internal flags) can be enumerated.
Protection:
- Upgrade immediately to `symfony/ux-autocomplete` version 2.36.0 or 3.1.0 or higher.
- If upgrading is not possible, restrict access to the autocomplete endpoint by configuring security in
config/packages/security.yaml:security: access_control:</li> </ol> - { path: ^/autocomplete, roles: ROLE_USER }3. Explicitly define `searchable_fields` in your form type to limit which entity properties are searchable:
public function configureOptions(OptionsResolver $resolver): void { $resolver->setDefaults([ 'searchable_fields' => ['name', 'description'], // limit to safe fields ]); }4. Set `security` to `true` or a valid role in
BaseEntityAutocompleteType:BaseEntityAutocompleteType::class => [ 'security' => 'ROLE_USER', ]
Impact:
- Confidentiality: High — unauthenticated attackers can enumerate all entity data, including sensitive columns.
- Integrity: None — the vulnerability does not allow data modification.
- Availability: None — no denial-of-service impact.
- Attack Complexity: Low — no special conditions required.
- Privileges Required: None — the endpoint is public by default.
- User Interaction: None — the attack can be fully automated.
The primary risk is information exposure — an attacker can turn a seemingly innocuous autocomplete feature into a full database extraction tool, potentially leaking user records, internal identifiers, and other sensitive data that was never meant to be exposed via the public API.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by ThousandsSources:
Reported By: github.com
Extra Source Hub:
Undercode🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow DailyCVE & Stay Tuned:
