I am admin on a few high profile js projects. Github has enabled sending alerts for vulnerabilities, I haven’t yet seen one that was actually a real one. Lots of times there’s a deep dependency that we’re not even using that can accept a regex that may cause a DoS.
There is a type of regex called a "pathological" regex which can be used to make certain regex implementations have exponential time complexity. If you exposed this in your application, someone could DoS you. Some libraries might have accidentally pathological regular expressions, and so some user input might be able to trigger the pathological case (Atom had a bug a few years ago where certain source files would cause the editor to lock up, and it was caused by a bad regex they used for parsing to figure out the auto indentation[1]).
Russ Cox wrote an article about this in 2007[2], and the situation is still the same. Go doesn't have this problem since Russ Cox is one of the lead authors of Go, and wrote Go's regex library.
Rust's regex library also doesn't have this issue [1], and is easily usable by other languages [2]. If you're concerned about this issue in your code and your not using go it's probably easier to use this than the go one.
Sure, but the only reason I mentioned Go is because Russ Cox literally wrote the paper on this problem and also happened to write the Go regex library (as well as a large part of Go itself). I wrote an FSA-based regex implementation in Python some years ago[1] as a learning experience, but that's not really relevant to someone asking "what is a pathological regex".
I wasn't trying to say "you should have linked this instead", just trying to point anyone who sees this and goes "that's an issue in my code" in the right direction.
Often there isn't one, but those reports don't take context into account.
Sometimes there is one, but it's something like if you pipe large amounts of data to socket.io (or whatever else is parsing any input) in a certain way it will hang (often marked as a 7.5/High on CVSS).
And then every once in a while there is an actual, serious vulnerability because you or someone in your dependency chain glued libs together in a certain way and by that point you have already stopped listening to any report looking similar to the two previous examples.
I'm not sure how anyone maintaining a large node app built using current js ecosystem best-practices could ever keep track well enough to actually find the exploitable ones.
