Regular-expression backtracking in Symfony JsonPath can cause denial of service

Symfony is a PHP framework for web and console applications and a set of reusable PHP components. From 7.3.0-BETA1 until 7.4.12 and 8.0.12, the JsonPath component compiles attacker-controlled match() and search() filter patterns directly into preg_match() without a length cap, i-regexp restriction, or bounded backtracking, allowing catastrophic-backtracking expressions to pin worker CPU and cause denial of service. This issue is fixed in versions 7.4.12 and 8.0.12.

• symfony/json-path and the JsonPath component in symfony/symfony are affected in >= 7.3.0-BETA1, < 7.4.12. The corresponding patched release is 7.4.12.
• The same packages and components are affected in >= 8.0.0-BETA1, < 8.0.12. The corresponding patched release is 8.0.12.
• The Symfony advisory lists the same affected ranges and patched releases for both symfony/json-path and symfony/symfony.
• The repository changelog also records the fix in the 8.1.x line, but the available evidence does not provide an exact affected or patched boundary for that line. Do not infer that an 8.1.x build is safe without separate verification.

The JsonPath component accepts caller-supplied JSONPath expressions and passes patterns from match() or search() into preg_match(). transformJsonPathRegex() performs only cosmetic escaping, with no pattern-length cap, no restriction to the RFC 9485 i-regexp subset, and no backtracking bound. A regular expression with pathological complexity can therefore trigger catastrophic backtracking when evaluated against non-trivial JSON input. Each evaluation can hold a CPU core for an extended period, while concurrent requests can exhaust the worker pool. The preg_match() calls are prefixed with @, so PCRE backtrack-limit errors can be suppressed and may leave no corresponding log entry. The patch routes matching through a helper that temporarily sets pcre.backtrack_limit to a bounded value and then restores the previous setting. Exposure depends on whether the application actually evaluates attacker-influenced JSONPath; the record does not establish that every use of JsonPath permits this control.

The issue can be reached over the network when an endpoint, query parameter, or API field lets an attacker supply JSONPath that the application evaluates through JsonCrawler. The required condition is an attacker-controlled match() or search() filter evaluated against non-trivial JSON input. The normalized record describes the vulnerability as requiring no privileges and no user interaction at the vulnerability level, although application-layer access controls may still restrict reachability. The record marks public exploit as false and does not identify known exploitation; that does not prove exploitation is impossible or has not occurred. The available evidence names no campaign, victim, or specific exploit.

When the exposure condition exists, an attacker can cause regular-expression evaluation to consume excessive CPU and hold workers longer than expected. If enough requests arrive concurrently, the worker pool may be occupied, increasing latency, causing timeouts, or rejecting legitimate traffic. Based on the available evidence, the impact is limited to availability; the record does not show that the issue enables data disclosure, data modification, or privilege escalation. Actual severity depends on the JSON document size, worker configuration, and whether the endpoint permits attacker control of the expression.

A Symfony application that allows external users or systems to provide JSONPath may suffer availability degradation when requests force workers to evaluate regular expressions with very expensive backtracking. A single request can hold worker CPU for an extended period, while concurrent requests can exhaust the worker pool, increase latency, or cause request failures. This can affect APIs, web applications, or console-backed services that use the component with attacker-influenced input. The record does not establish data disclosure or data modification; the documented consequence is primarily an availability impact.

1. Upgrade symfony/json-path or the symfony/symfony package to the exact patched release for the branch in use: 7.4.12 for the affected branch beginning at 7.3.0-BETA1, or 8.0.12 for the affected branch beginning at 8.0.0-BETA1.
2. After updating, verify the resolved dependency in composer.lock and the vendor directory, then restart or redeploy all request-processing workers so old in-memory code is removed.
3. If the deployment uses the 8.1.x line, verify the specific build against Symfony guidance before concluding that it is protected, because the advisory reviewed here does not fully state that line's boundaries.
4. If an upgrade is not immediately possible, prevent untrusted data from supplying JSONPath to JsonCrawler, especially filters using match() and search(). This is a usage-based mitigation, not a substitute for patching.

• Inventory dependencies from composer.lock, the vendor directory, and build systems to identify symfony/json-path or the symfony/symfony package in affected branches.
• Review application data flows to determine whether JsonCrawler receives JSONPath from query parameters, request bodies, API fields, or other attacker-controlled sources.
• Focus code review on filters using match() and search(), especially where the pattern is passed into searches over JSON documents.
• Monitor worker CPU, request processing time, worker-pool exhaustion, and request queues as supplementary operational checks. These are possible symptoms of exploitation, not confirmed indicators.
• Do not treat the absence of PCRE errors or log entries as proof of safety because the @ operator can suppress backtrack-limit errors.