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