CVE-2026-49211

Symfony UX is a JavaScript ecosystem for Symfony. From 2.2.0 until 2.36.0 and 3.1.0, Symfony\UX\Autocomplete\Doctrine\EntitySearchUtil::addSearchClause() builds the LIKE expression used by the autocomplete endpoint by wrapping the client-supplied query in %...% without escaping SQL LIKE wildcards (%, _, ), allowing unauthenticated users to turn the public BaseEntityAutocompleteType endpoint into a broad matcher or blind boolean oracle against every column in default searchable_fields. This issue is fixed in versions 2.36.0 and 3.1.0.

Symfony UX is a JavaScript ecosystem for Symfony. From 2.2.0 until 2.36.0 and 3.1.0, Symfony\UX\Autocomplete\Doctrine\EntitySearchUtil::addSearchClause() builds the LIKE expression used by the autocomplete endpoint by wrapping the client-supplied query in %...% without escaping SQL LIKE wildcards (%, _, ), allowing unauthenticated users to turn the public BaseEntityAutocompleteType endpoint into a broad matcher or blind boolean oracle against every column in default searchable_fields. This issue is fixed in versions 2.36.0 and 3.1.0.

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.

Symfony UX is a JavaScript ecosystem for Symfony. From 2.2.0 until 2.36.0 and 3.1.0, Symfony\UX\Autocomplete\Doctrine\EntitySearchUtil::addSearchClause() builds the LIKE expression used by the autocomplete endpoint by wrapping the client-supplied query in %...% without escaping SQL LIKE wildcards (%, _, ), allowing unauthenticated users to turn the public BaseEntityAutocompleteType endpoint into a broad matcher or blind boolean oracle against every column in default searchable_fields. This issue is fixed in versions 2.36.0 and 3.1.0.

Symfony UX is a JavaScript ecosystem for Symfony. From 2.2.0 until 2.36.0 and 3.1.0, Symfony\UX\Autocomplete\Doctrine\EntitySearchUtil::addSearchClause() builds the LIKE expression used by the autocomplete endpoint by wrapping the client-supplied query in %...% without escaping SQL LIKE wildcards (%, _, ), allowing unauthenticated users to turn the public BaseEntityAutocompleteType endpoint into a broad matcher or blind boolean oracle against every column in default searchable_fields. This issue is fixed in versions 2.36.0 and 3.1.0.

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.