One example of this was a CVE for ReDoS in the `py` support library, which caused failed CI runs and "noise for hundreds of thousands of pytest users" despite being of questionable severity (as original article explains) and not actually used anywhere in the wild.
Yes! That was the report that originally inspired me to write this post.
There was some ambiguity in that case, because the original reporter claims that they never actually hit “publish” on their drafted CVE. But it’s out there now, and nobody has responded to my (repeated) requests to revoke it, given the lack of any evidence of exploitability.
"lack of any evidence of exploitability" or not detected yet?
I do understand that a CVE can be non pertinent since it could require a technical context, which reasonably cannot exist, to make any "production" exploits using it that "just work".
I guess this is one of them?
At the time I was meeting computer security ppl (decade ago), they told me they usually do not publish "production" exploits, they keep that for themselves or the vendor (if it is listening), but they have some.
> "lack of any evidence of exploitability" or not detected yet?
Lack of evidence and likelihood.
This is a "vulnerable" module for interaction with paths in SVN repositories (in order to grab SVN metadata) in the utility library of a testing framework.
So the normal use case is that the "exploit" would be the repository itself, likely because your repo server has been compromised, and it would require that the test suite binds tightly to SVN for some reason.
I don't think an ReDOS in your test suite is the biggest issue you're facing if your repository has been compromised.
I meant by that, it needs reading between the lines: some ppl were exploiting the "convenient bug" in other kind of benign systems while publishing, but they had real exploits using the "same convenient bug" on more troublesome production systems.
For instance, in a fantasy world, path parsing in SVN has a "convenient bug" and you can find the same "convenient bug" deep in blink URL parsing.
https://github.com/pytest-dev/py/issues/287