security-geeks / redos-vulnerabilities

A list of ReDoS vulnerabilities in npm modules found by the Software Lab at TU Darmstadt. For each vulnerability, there is a proof-of-concept exploit, showing how the slowdown may occur. The resources in this repository are provided for research purpose only. Please read below for more details.

Reported ReDoS Vulnerabilities

Below there is a list of ReDoS vulnerabilities reported as part of the research paper Freezing the Web: A Study of ReDoS Vulnerabilities in JavaScript-based Web Servers:

Vulnerable module	Bug Report	Response	Advisory
debug	Issue 501	FIXED	534
lodash	Issue 3359	"limiting the size is fine"	N/A
mime	Issue 167	FIXED	535
ajv	Issue 557	"it needs to be better investigated"	N/A
tough-cookie	Issue 92	FIXED	525
fresh	Issue 24	FIXED	526
moment	Issue 4163	FIXED	532
forwarded	Issue 3	FIXED	527
underscore.string	Issue 510	N/A	N/A
parsejson	Issue 4	FIXED	528
no-case	Issue 17	FIXED	529
marked	Issue 937	FIXED	531
content-type-parser	Issue 3	"a pull request is welcome" and "there are much worse attacks than a six second slowdown"	N/A
platform	Issue 139	"I'll accept a PR for this" and "using any utils withinputs of arbitrary length runs a performance risk"	N/A
timespan	Issue 10	N/A	533
string	Issue 212	N/A	536
content	Issue 14	N/A	537
slug	Issue 82	FIXED	530
htmlparser	Issue 79	N/A	N/A
charset	Issue 10	FIXED	524
mobile-detect	Issue 67	"I limited the length of User-Agent to max 500 characters"	N/A
ismobilejs	Issue 66	N/A	N/A
dns-sync	Issue 5	N/A	N/A

Running the Exploits Set

The current folder contains a set of exploits for the identified vulnerabilities. To run the exploits on your local machine perform the following steps:

1. checkout the current repository
2. install the vulnerable package by running npm install in the checked out folder
3. run the benchmarks by executing the following command node ./run-all.js

The exploits are harmless to run locally since they do not perform any malicious actions other than exploiting the slowdown in the regular expression matching. For each benchmark, we print an execution time that shows how long a specific exploit takes.