https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 16:50:43 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-338524 EUVD-2026-338524 https://cve.radiocsirt.org/vuln/euvd-2026-338524 https://cve.radiocsirt.org/vuln/fkie_cve-2026-49211 <p>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.</p> <p>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.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-49211 https://cve.radiocsirt.org/vuln/ghsa-946h-jp5c-8fvh <p><strong>Affected:</strong> Packagist: symfony/ux-autocomplete</p> <p>### Description</p> <p>`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.</p> <p>Because `searchable_fields` defaults to every property of the entity and the autocomplete endpoint is public by default (`BaseEntityAutocompleteType` ships with `security =&gt; 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.</p> <p>### Resolution</p> <p>`EntitySearchUtil` now escapes `\`, `%`, and `_` in the user-supplied query with `addcslashes()` and appends an explicit `ESCAPE &#39;\&#39;` clause to the generated `LIKE` expression, so those characters are matched literally. The exact-match `words_query` `IN()` branch is unchanged.</p> <p>The patch for this issue is available [here](https://github.com/symfony/ux/commit/725ab3d40689c91ff19ad2d01940a30007769214) for branch 2.x (and forward-ported to 3.x).</p> <p>### Credits</p> <p>Symfony would like to thank Pascal Cescon for reporting the issue and providing the fix.</p> <p><strong>Affected:</strong> Packagist: symfony/ux-autocomplete</p> <p>### Description</p> <p>`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.</p> <p>Because `searchable_fields` defaults to every property of the entity and the autocomplete endpoint is public by default (`BaseEntityAutocompleteType` ships with `security =&gt; 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.</p> <p>### Resolution</p> <p>`EntitySearchUtil` now escapes `\`, `%`, and `_` in the user-supplied query with `addcslashes()` and appends an explicit `ESCAPE &#39;\&#39;` clause to the generated `LIKE` expression, so those characters are matched literally. The exact-match `words_query` `IN()` branch is unchanged.</p> <p>The patch for this issue is available [here](https://github.com/symfony/ux/commit/725ab3d40689c91ff19ad2d01940a30007769214) for branch 2.x (and forward-ported to 3.x).</p> <p>### Credits</p> <p>Symfony would like to thank Pascal Cescon for reporting the issue and providing the fix.</p> https://cve.radiocsirt.org/vuln/ghsa-946h-jp5c-8fvh