symfony/json-path

Version	Released
`v8.1.2` patch	Jul 29, 2026
`v8.0.15` patch	Jul 29, 2026
`v7.4.15` patch	Jul 29, 2026
`v8.1.0` minor	May 29, 2026
`v8.1.0-BETA3` pre	May 20, 2026
`v8.0.12` patch	May 20, 2026
`v7.4.12` patch	May 13, 2026
`v8.1.0-BETA1` pre	Apr 18, 2026
`v8.0.8` patch 1 CVE	Mar 30, 2026
`v7.4.8` patch 1 CVE	Mar 24, 2026
`v8.0.4` patch 1 CVE	Jan 05, 2026
`v7.4.4` patch 1 CVE	Jan 05, 2026
`v7.3.10` patch 1 CVE	Jan 05, 2026
`v8.0.3` patch 1 CVE	Dec 19, 2025
`v7.4.3` patch 1 CVE	Dec 19, 2025
`v7.3.9` patch 1 CVE	Dec 19, 2025
`v8.0.1` patch 1 CVE	Dec 01, 2025
`v7.4.1` patch 1 CVE	Nov 29, 2025
`v7.3.8` patch 1 CVE	Nov 24, 2025
`v8.0.0` major 1 CVE	Nov 05, 2025
`v7.4.0` minor 1 CVE	Nov 03, 2025
`v8.0.0-BETA1` pre	Oct 01, 2025
`v7.4.0-BETA1` pre 1 CVE	Sep 30, 2025
`v7.3.5` patch 1 CVE	Sep 27, 2025
`v7.3.4` patch 1 CVE	Sep 15, 2025
`v7.3.2` patch 1 CVE	Jul 29, 2025
`v7.3.1` patch 1 CVE	Jun 16, 2025
`v7.3.0` initial 1 CVE	May 24, 2025
`v7.3.0-BETA2` pre	Apr 27, 2025

v8.1.2 patch

Jul 29, 2026

v8.0.15 patch

Jul 29, 2026

v7.4.15 patch

Jul 29, 2026

v8.1.0 minor

May 29, 2026

v8.1.0-BETA3 pre

May 20, 2026

v8.0.12 patch

May 20, 2026

v7.4.12 patch

May 13, 2026

v8.1.0-BETA1 pre

Apr 18, 2026

v8.0.8 patch

1 CVE

CVE-2026-45756 GHSA-8v8v-g73j-492j May 28, 2026

Symfony's JsonPath Evaluates Attacker-Controlled Regular Expressions in match()/search() Without Limits — ReDoS

Low

Network Low None None

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 for branch 7.4.

Credits

Symfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois for providing the fix.

Affected versions


          v7.3.0


          v7.3.1


          v7.3.10


          v7.3.2


          v7.3.4


          v7.3.5


          v7.3.8


          v7.3.9


          v7.4.0


          v7.4.0-BETA1


          v7.4.0-RC1


          v7.4.1

+ 8 more


            v7.4.3


            v7.4.4


            v7.4.8


            v8.0.0


            v8.0.1


            v8.0.3


            v8.0.4


            v8.0.8

Fixed in


          7.4.12


          8.0.12

References

Updated Sep 10, 2026 · Source: OSV.dev

Mar 30, 2026

v7.4.8 patch

1 CVE

CVE-2026-45756 GHSA-8v8v-g73j-492j May 28, 2026

Symfony's JsonPath Evaluates Attacker-Controlled Regular Expressions in match()/search() Without Limits — ReDoS

Low

Network Low None None

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 for branch 7.4.

Credits

Symfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois for providing the fix.

Affected versions


          v7.3.0


          v7.3.1


          v7.3.10


          v7.3.2


          v7.3.4


          v7.3.5


          v7.3.8


          v7.3.9


          v7.4.0


          v7.4.0-BETA1


          v7.4.0-RC1


          v7.4.1

+ 8 more


            v7.4.3


            v7.4.4


            v7.4.8


            v8.0.0


            v8.0.1


            v8.0.3


            v8.0.4


            v8.0.8

Fixed in


          7.4.12


          8.0.12

References

Updated Sep 10, 2026 · Source: OSV.dev

Mar 24, 2026

v8.0.4 patch

1 CVE

CVE-2026-45756 GHSA-8v8v-g73j-492j May 28, 2026

Symfony's JsonPath Evaluates Attacker-Controlled Regular Expressions in match()/search() Without Limits — ReDoS

Low

Network Low None None

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 for branch 7.4.

Credits

Symfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois for providing the fix.

Affected versions


          v7.3.0


          v7.3.1


          v7.3.10


          v7.3.2


          v7.3.4


          v7.3.5


          v7.3.8


          v7.3.9


          v7.4.0


          v7.4.0-BETA1


          v7.4.0-RC1


          v7.4.1

+ 8 more


            v7.4.3


            v7.4.4


            v7.4.8


            v8.0.0


            v8.0.1


            v8.0.3


            v8.0.4


            v8.0.8

Fixed in


          7.4.12


          8.0.12

References

Updated Sep 10, 2026 · Source: OSV.dev

Jan 05, 2026

v7.4.4 patch

1 CVE

CVE-2026-45756 GHSA-8v8v-g73j-492j May 28, 2026

Symfony's JsonPath Evaluates Attacker-Controlled Regular Expressions in match()/search() Without Limits — ReDoS

Low

Network Low None None

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 for branch 7.4.

Credits

Symfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois for providing the fix.

Affected versions


          v7.3.0


          v7.3.1


          v7.3.10


          v7.3.2


          v7.3.4


          v7.3.5


          v7.3.8


          v7.3.9


          v7.4.0


          v7.4.0-BETA1


          v7.4.0-RC1


          v7.4.1

+ 8 more


            v7.4.3


            v7.4.4


            v7.4.8


            v8.0.0


            v8.0.1


            v8.0.3


            v8.0.4


            v8.0.8

Fixed in


          7.4.12


          8.0.12

References

Updated Sep 10, 2026 · Source: OSV.dev

Jan 05, 2026

v7.3.10 patch

1 CVE

CVE-2026-45756 GHSA-8v8v-g73j-492j May 28, 2026

Symfony's JsonPath Evaluates Attacker-Controlled Regular Expressions in match()/search() Without Limits — ReDoS

Low

Network Low None None

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 for branch 7.4.

Credits

Symfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois for providing the fix.

Affected versions


          v7.3.0


          v7.3.1


          v7.3.10


          v7.3.2


          v7.3.4


          v7.3.5


          v7.3.8


          v7.3.9


          v7.4.0


          v7.4.0-BETA1


          v7.4.0-RC1


          v7.4.1

+ 8 more


            v7.4.3


            v7.4.4


            v7.4.8


            v8.0.0


            v8.0.1


            v8.0.3


            v8.0.4


            v8.0.8

Fixed in


          7.4.12


          8.0.12

References

Updated Sep 10, 2026 · Source: OSV.dev

Jan 05, 2026

v8.0.3 patch

1 CVE

CVE-2026-45756 GHSA-8v8v-g73j-492j May 28, 2026

Symfony's JsonPath Evaluates Attacker-Controlled Regular Expressions in match()/search() Without Limits — ReDoS

Low

Network Low None None

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 for branch 7.4.

Credits

Symfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois for providing the fix.

Affected versions


          v7.3.0


          v7.3.1


          v7.3.10


          v7.3.2


          v7.3.4


          v7.3.5


          v7.3.8


          v7.3.9


          v7.4.0


          v7.4.0-BETA1


          v7.4.0-RC1


          v7.4.1

+ 8 more


            v7.4.3


            v7.4.4


            v7.4.8


            v8.0.0


            v8.0.1


            v8.0.3


            v8.0.4


            v8.0.8

Fixed in


          7.4.12


          8.0.12

References

Updated Sep 10, 2026 · Source: OSV.dev

Dec 19, 2025

v7.4.3 patch

1 CVE

CVE-2026-45756 GHSA-8v8v-g73j-492j May 28, 2026

Symfony's JsonPath Evaluates Attacker-Controlled Regular Expressions in match()/search() Without Limits — ReDoS

Low

Network Low None None

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 for branch 7.4.

Credits

Symfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois for providing the fix.

Affected versions


          v7.3.0


          v7.3.1


          v7.3.10


          v7.3.2


          v7.3.4


          v7.3.5


          v7.3.8


          v7.3.9


          v7.4.0


          v7.4.0-BETA1


          v7.4.0-RC1


          v7.4.1

+ 8 more


            v7.4.3


            v7.4.4


            v7.4.8


            v8.0.0


            v8.0.1


            v8.0.3


            v8.0.4


            v8.0.8

Fixed in


          7.4.12


          8.0.12

References

Updated Sep 10, 2026 · Source: OSV.dev

Dec 19, 2025

v7.3.9 patch

1 CVE

CVE-2026-45756 GHSA-8v8v-g73j-492j May 28, 2026

Symfony's JsonPath Evaluates Attacker-Controlled Regular Expressions in match()/search() Without Limits — ReDoS

Low

Network Low None None

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 for branch 7.4.

Credits

Symfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois for providing the fix.

Affected versions


          v7.3.0


          v7.3.1


          v7.3.10


          v7.3.2


          v7.3.4


          v7.3.5


          v7.3.8


          v7.3.9


          v7.4.0


          v7.4.0-BETA1


          v7.4.0-RC1


          v7.4.1

+ 8 more


            v7.4.3


            v7.4.4


            v7.4.8


            v8.0.0


            v8.0.1


            v8.0.3


            v8.0.4


            v8.0.8

Fixed in


          7.4.12


          8.0.12

References

Updated Sep 10, 2026 · Source: OSV.dev

Dec 19, 2025

v8.0.1 patch

1 CVE

CVE-2026-45756 GHSA-8v8v-g73j-492j May 28, 2026

Symfony's JsonPath Evaluates Attacker-Controlled Regular Expressions in match()/search() Without Limits — ReDoS

Low

Network Low None None

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 for branch 7.4.

Credits

Symfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois for providing the fix.

Affected versions


          v7.3.0


          v7.3.1


          v7.3.10


          v7.3.2


          v7.3.4


          v7.3.5


          v7.3.8


          v7.3.9


          v7.4.0


          v7.4.0-BETA1


          v7.4.0-RC1


          v7.4.1

+ 8 more


            v7.4.3


            v7.4.4


            v7.4.8


            v8.0.0


            v8.0.1


            v8.0.3


            v8.0.4


            v8.0.8

Fixed in


          7.4.12


          8.0.12

References

Updated Sep 10, 2026 · Source: OSV.dev

Dec 01, 2025

v7.4.1 patch

1 CVE

CVE-2026-45756 GHSA-8v8v-g73j-492j May 28, 2026

Symfony's JsonPath Evaluates Attacker-Controlled Regular Expressions in match()/search() Without Limits — ReDoS

Low

Network Low None None

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 for branch 7.4.

Credits

Symfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois for providing the fix.

Affected versions


          v7.3.0


          v7.3.1


          v7.3.10


          v7.3.2


          v7.3.4


          v7.3.5


          v7.3.8


          v7.3.9


          v7.4.0


          v7.4.0-BETA1


          v7.4.0-RC1


          v7.4.1

+ 8 more


            v7.4.3


            v7.4.4


            v7.4.8


            v8.0.0


            v8.0.1


            v8.0.3


            v8.0.4


            v8.0.8

Fixed in


          7.4.12


          8.0.12

References

Updated Sep 10, 2026 · Source: OSV.dev

Nov 29, 2025

v7.3.8 patch

1 CVE

CVE-2026-45756 GHSA-8v8v-g73j-492j May 28, 2026

Symfony's JsonPath Evaluates Attacker-Controlled Regular Expressions in match()/search() Without Limits — ReDoS

Low

Network Low None None

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 for branch 7.4.

Credits

Symfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois for providing the fix.

Affected versions


          v7.3.0


          v7.3.1


          v7.3.10


          v7.3.2


          v7.3.4


          v7.3.5


          v7.3.8


          v7.3.9


          v7.4.0


          v7.4.0-BETA1


          v7.4.0-RC1


          v7.4.1

+ 8 more


            v7.4.3


            v7.4.4


            v7.4.8


            v8.0.0


            v8.0.1


            v8.0.3


            v8.0.4


            v8.0.8

Fixed in


          7.4.12


          8.0.12

References

Updated Sep 10, 2026 · Source: OSV.dev

Nov 24, 2025

v8.0.0 major

1 CVE

CVE-2026-45756 GHSA-8v8v-g73j-492j May 28, 2026

Symfony's JsonPath Evaluates Attacker-Controlled Regular Expressions in match()/search() Without Limits — ReDoS

Low

Network Low None None

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 for branch 7.4.

Credits

Symfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois for providing the fix.

Affected versions


          v7.3.0


          v7.3.1


          v7.3.10


          v7.3.2


          v7.3.4


          v7.3.5


          v7.3.8


          v7.3.9


          v7.4.0


          v7.4.0-BETA1


          v7.4.0-RC1


          v7.4.1

+ 8 more


            v7.4.3


            v7.4.4


            v7.4.8


            v8.0.0


            v8.0.1


            v8.0.3


            v8.0.4


            v8.0.8

Fixed in


          7.4.12


          8.0.12

References

Updated Sep 10, 2026 · Source: OSV.dev

Nov 05, 2025

v7.4.0 minor

1 CVE

CVE-2026-45756 GHSA-8v8v-g73j-492j May 28, 2026

Symfony's JsonPath Evaluates Attacker-Controlled Regular Expressions in match()/search() Without Limits — ReDoS

Low

Network Low None None

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 for branch 7.4.

Credits

Symfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois for providing the fix.

Affected versions


          v7.3.0


          v7.3.1


          v7.3.10


          v7.3.2


          v7.3.4


          v7.3.5


          v7.3.8


          v7.3.9


          v7.4.0


          v7.4.0-BETA1


          v7.4.0-RC1


          v7.4.1

+ 8 more


            v7.4.3


            v7.4.4


            v7.4.8


            v8.0.0


            v8.0.1


            v8.0.3


            v8.0.4


            v8.0.8

Fixed in


          7.4.12


          8.0.12

References

Updated Sep 10, 2026 · Source: OSV.dev

Nov 03, 2025

v8.0.0-BETA1 pre

Oct 01, 2025

v7.4.0-BETA1 pre

1 CVE

CVE-2026-45756 GHSA-8v8v-g73j-492j May 28, 2026

Symfony's JsonPath Evaluates Attacker-Controlled Regular Expressions in match()/search() Without Limits — ReDoS

Low

Network Low None None

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 for branch 7.4.

Credits

Symfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois for providing the fix.

Affected versions


          v7.3.0


          v7.3.1


          v7.3.10


          v7.3.2


          v7.3.4


          v7.3.5


          v7.3.8


          v7.3.9


          v7.4.0


          v7.4.0-BETA1


          v7.4.0-RC1


          v7.4.1

+ 8 more


            v7.4.3


            v7.4.4


            v7.4.8


            v8.0.0


            v8.0.1


            v8.0.3


            v8.0.4


            v8.0.8

Fixed in


          7.4.12


          8.0.12

References

Updated Sep 10, 2026 · Source: OSV.dev

Sep 30, 2025

v7.3.5 patch

1 CVE

CVE-2026-45756 GHSA-8v8v-g73j-492j May 28, 2026

Symfony's JsonPath Evaluates Attacker-Controlled Regular Expressions in match()/search() Without Limits — ReDoS

Low

Network Low None None

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 for branch 7.4.

Credits

Symfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois for providing the fix.

Affected versions


          v7.3.0


          v7.3.1


          v7.3.10


          v7.3.2


          v7.3.4


          v7.3.5


          v7.3.8


          v7.3.9


          v7.4.0


          v7.4.0-BETA1


          v7.4.0-RC1


          v7.4.1

+ 8 more


            v7.4.3


            v7.4.4


            v7.4.8


            v8.0.0


            v8.0.1


            v8.0.3


            v8.0.4


            v8.0.8

Fixed in


          7.4.12


          8.0.12

References

Updated Sep 10, 2026 · Source: OSV.dev

Sep 27, 2025

v7.3.4 patch

1 CVE

CVE-2026-45756 GHSA-8v8v-g73j-492j May 28, 2026

Symfony's JsonPath Evaluates Attacker-Controlled Regular Expressions in match()/search() Without Limits — ReDoS

Low

Network Low None None

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 for branch 7.4.

Credits

Symfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois for providing the fix.

Affected versions


          v7.3.0


          v7.3.1


          v7.3.10


          v7.3.2


          v7.3.4


          v7.3.5


          v7.3.8


          v7.3.9


          v7.4.0


          v7.4.0-BETA1


          v7.4.0-RC1


          v7.4.1

+ 8 more


            v7.4.3


            v7.4.4


            v7.4.8


            v8.0.0


            v8.0.1


            v8.0.3


            v8.0.4


            v8.0.8

Fixed in


          7.4.12


          8.0.12

References

Updated Sep 10, 2026 · Source: OSV.dev

Sep 15, 2025

v7.3.2 patch

1 CVE

CVE-2026-45756 GHSA-8v8v-g73j-492j May 28, 2026

Symfony's JsonPath Evaluates Attacker-Controlled Regular Expressions in match()/search() Without Limits — ReDoS

Low

Network Low None None

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 for branch 7.4.

Credits

Symfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois for providing the fix.

Affected versions


          v7.3.0


          v7.3.1


          v7.3.10


          v7.3.2


          v7.3.4


          v7.3.5


          v7.3.8


          v7.3.9


          v7.4.0


          v7.4.0-BETA1


          v7.4.0-RC1


          v7.4.1

+ 8 more


            v7.4.3


            v7.4.4


            v7.4.8


            v8.0.0


            v8.0.1


            v8.0.3


            v8.0.4


            v8.0.8

Fixed in


          7.4.12


          8.0.12

References

Updated Sep 10, 2026 · Source: OSV.dev

Jul 29, 2025

v7.3.1 patch

1 CVE

CVE-2026-45756 GHSA-8v8v-g73j-492j May 28, 2026

Symfony's JsonPath Evaluates Attacker-Controlled Regular Expressions in match()/search() Without Limits — ReDoS

Low

Network Low None None

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 for branch 7.4.

Credits

Symfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois for providing the fix.

Affected versions


          v7.3.0


          v7.3.1


          v7.3.10


          v7.3.2


          v7.3.4


          v7.3.5


          v7.3.8


          v7.3.9


          v7.4.0


          v7.4.0-BETA1


          v7.4.0-RC1


          v7.4.1

+ 8 more


            v7.4.3


            v7.4.4


            v7.4.8


            v8.0.0


            v8.0.1


            v8.0.3


            v8.0.4


            v8.0.8

Fixed in


          7.4.12


          8.0.12

References

Updated Sep 10, 2026 · Source: OSV.dev

Jun 16, 2025

v7.3.0 initial

1 CVE

CVE-2026-45756 GHSA-8v8v-g73j-492j May 28, 2026

Symfony's JsonPath Evaluates Attacker-Controlled Regular Expressions in match()/search() Without Limits — ReDoS

Low

Network Low None None

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 for branch 7.4.

Credits

Symfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois for providing the fix.

Affected versions


          v7.3.0


          v7.3.1


          v7.3.10


          v7.3.2


          v7.3.4


          v7.3.5


          v7.3.8


          v7.3.9


          v7.4.0


          v7.4.0-BETA1


          v7.4.0-RC1


          v7.4.1

+ 8 more


            v7.4.3


            v7.4.4


            v7.4.8


            v8.0.0


            v8.0.1


            v8.0.3


            v8.0.4


            v8.0.8

Fixed in


          7.4.12


          8.0.12

References

Updated Sep 10, 2026 · Source: OSV.dev

May 24, 2025

v7.3.0-BETA2 pre

Apr 27, 2025

Activity

Reach

Details