Common Weakness Enumeration

CWE-1333

Allowed

Inefficient 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:38
VLAI
Summary
Transformers vulnerable to ReDoS attack through its get_imports() function
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.

Show details on source website

{
  "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:32
VLAI
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.

Show details on source website

{
  "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:05
VLAI
Summary
Wagtail regular expression denial-of-service via search query parsing
Details

Impact

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:

Show details on source website

{
  "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:32
VLAI
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's susceptibility to second-degree polynomial time complexity, which can be triggered by a large number of braces in the input.

Show details on source website

{
  "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:15
VLAI
Summary
markdown2 Regular Expression Denial of Service
Details

markdown2 >=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.

Show details on source website

{
  "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:14
VLAI
Summary
CKEditor 4 ReDoS Vulnerability
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).

Show details on source website

{
  "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:37
VLAI
Summary
Denial of Service (DoS) vulnerability in RSSHub
Details

Impact

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

Show details on source website

{
  "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:40
VLAI
Summary
PyJWT: ReDoS vulnerability when calling the `is_pem_format` function.
Details

Summary

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.

Show details on source website

{
  "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:47
VLAI
Summary
Sync-in Server has a ReDoS via Unsanitized Regex in Sync Diff `pathFilters`
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.

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:

  1. Register a sync client: POST /api/app/sync/register with credentials and clientId.
  2. Authenticate: POST /api/app/sync/auth/cookie to get a JWT with clientId embedded.
  3. Create or use a sync path targeting an application-managed directory containing files.
  4. Ensure the sync path contains a worst-case filename or directory name for the regex, for example a long sequence of a characters.
  5. 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-regex2 or an equivalent safety checker.
  • Return a BadRequestException for 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.

Show details on source website

{
  "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:31
VLAI
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.

Show details on source website

{
  "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
Architecture and Design

Use regular expressions that do not support backtracking, e.g. by removing nested quantifiers.

Mitigation
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.

Mitigation
Implementation

Do not use regular expressions with untrusted input. If regular expressions must be used, avoid using backtracking in the expression.

Mitigation
Implementation

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.