"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.
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.