Skip to content
Log inStart free trial

GHSA-8v8v-g73j-492j CVE-2026-45756

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

High Packagist
Severity
0.0 / 10
High · CVSS 4.0
Exploit chance (EPSS)
0.63%
Chance of exploitation in the next 30 days. Higher than 50.19% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-1333 Inefficient Regular Expression Complexity
CWE-400 Uncontrolled Resource Consumption
Fix
Available
2 packages have a fixed version

Description

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

Packagist

PackageVulnerableFixed in
symfony/json-path
>= 7.3.0, < 7.4.12
7.4.12
symfony/json-path
>= 8.0.0, < 8.0.12
8.0.12
symfony/symfony
>= 7.3.0, < 7.4.12
7.4.12
symfony/symfony
>= 8.0.0, < 8.0.12
8.0.12

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

symfony/json-path Packagist → 7.4.12

composer
composer require symfony/json-path:^7.4.12

symfony/symfony Packagist → 7.4.12

composer
composer require symfony/symfony:^7.4.12

Severity breakdown

CVSS 4.0 0.0

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:U

Attack vector
Network
Attack complexity
Low
Attack requirements
None
Privileges required
None
User interaction
None
Confidentiality (vulnerable system)
None
Integrity (vulnerable system)
None
Availability (vulnerable system)
Low
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None
Exploit maturity
Unreported

CVSS 3.1 7.5

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Weakness

CWE-1333: Inefficient Regular Expression Complexity

The product uses a regular expression with a worst-case computational complexity that is inefficient and possibly exponential.

How to prevent it
  • Architecture and Design: Use regular expressions that do not support backtracking, e.g. by removing nested quantifiers.
  • System Configuration: Set backtracking limits in the configuration of the regular expression implementation, such as PHP's pcre.backtrack_limit. Also consider limits on execution time for the process.
  • Implementation: Do not use regular expressions with untrusted input. If regular expressions must be used, avoid using backtracking in the expression.
  • Implementation: Limit the length of the input that the regular expression will process.

CWE-400: Uncontrolled Resource Consumption

The product does not properly control the allocation and maintenance of a limited resource.

How to prevent it
  • Architecture and Design: Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
  • Architecture and Design: Mitigation of resource exhaustion attacks requires that the target system either: recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed. The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
  • Architecture and Design: Ensure that protocols have specific limits of scale placed on them.
  • Implementation: Ensure that all failures in resource allocation place the system into a safe posture.

References

Packages

Other links

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-2v3c-qxhr-7vpv
Symfony: Unbounded Recursion in the YAML Inline Lexer Lets a Single Document Crash the Process
High Also affects symfony/symfony
GHSA-r925-mgvr-h9cc
Symfony: ReDoS in HeaderUtils::split() Reachable Through the Cache-Control Request Header
High Also affects symfony/symfony
GHSA-h5x3-xfc9-m39h
Symfony: UrlGenerator Dot-Segment Encoding Skips Every Other Chained `../` or `./` → Generated URL Collapses Off-Route Under RFC 3986 Normalization
Medium Also affects symfony/symfony
GHSA-v3wm-qf9p-c549
Symfony: HtmlSanitizer URL Parser Deny Gates Underinclusive: Percent-Encoded BiDi Marks and Unicode Whitespace Bypass Visual-Spoofing Defense
Medium Also affects symfony/symfony
GHSA-rrj9-5q2j-4gvr
Symfony: Mailomat Mailer Webhook Parser Reads the HMAC Algorithm from the Request: Signature Algorithm Downgrade
Medium Also affects symfony/symfony
GHSA-38cx-cq6f-5755
Symfony: IpUtils::PRIVATE_SUBNETS Omits IPv6 Transition Forms (6to4, NAT64, Teredo, IPv4-compatible): SSRF Bypass in NoPrivateNetworkHttpClient
High Also affects symfony/symfony
GHSA-6h46-9jf5-q59x
Symfony: Security Firewall Bypass via failure_forward Subrequest: Unauthenticated Access to access_control-Protected GET Routes
High Also affects symfony/symfony
GHSA-x5qj-865h-mgvm
Symfony: HtmlSanitizer UrlAttributeSanitizer Misses URL Attributes
Medium Also affects symfony/symfony
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor