Description The "JsonPath" component's "match()" and "search()" filter functions compile a caller-supplied pattern straight into "preg_match()": 'match' => @preg_match(\sprintf('/^%s$/u', $this->transformJsonPathRegex($argList[1])), $value), 'search' => @preg_match("/{$this->transformJsonPathRegex($argList[1])}/u", $value), "transformJsonPathRegex()" only performs cosmetic escaping: there is no length cap, no restriction to the RFC 9485 i-regexp subset, and no bound on backtracking. An application that evaluates an attacker-influenced JSONPath expression server-side (e.g. one taken from a query parameter or API field and passed to "JsonCrawler") can therefore be made to run a catastrophic-backtracking pattern such as "$[?search(@, "(a+)+$")]". Evaluated against a moderately sized document, this pins a CPU core for seconds per request, so a handful of concurrent requests exhausts the worker pool: a denial of service. Because the "preg_match()" calls are prefixed with "@", the PCRE backtrack-limit errors that would otherwise surface are suppressed, leaving no log trace. Conditions for exploitation An application that evaluates an attacker-influenced JSONPath expression containing a "match()" / "search()" filter against any non-trivial JSON input. Resolution "JsonCrawler" runs the "preg_match()" calls through a helper that lowers "pcre.backtrack_limit" to 10000 for the duration of the call (restoring the previous value afterwards), so a pathological pattern fails fast instead of stalling the worker. The patch for this issue is available "here" (https://github.com/symfony/symfony/commit/1ac2d47418ec23066112db1e6ca35be6fe123d14) for branch 7.4. Credits Symfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois for providing the fix.