| Package | Affected versions | Patched versions |
|---|---|---|
| symfony/json-path | ≥ 7.3.0, < 7.4.12≥ 8.0.0, < 8.0.12 | 7.4.128.0.12 |
| symfony/symfony | ≥ 7.3.0, < 7.4.12≥ 8.0.0, < 8.0.12 | 7.4.128.0.12 |
| symfony | ≥ 7.3.0, < 7.4.12≥ 8.0.0, < 8.0.12 | 7.4.128.0.12 |
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.
An application that evaluates an attacker-influenced JSONPath expression containing a match() / search() filter against any non-trivial JSON input.
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 for branch 7.4.
Symfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois for providing the fix.
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site free