Great contribution, thanks! I wasn't even aware of this vulnerability, even though I'm very familiar with the OWASP guidelines for the Web. It seems like the JDK team should make this the default!

Released in 4.8.112. Thanks again!

You're welcome... I'm curious how you even spotted this vulnerability. It's in an obscure piece of code that tries to determine the ClassGraph version by reading pom.xml.

Just a heads up this has been assigned CVE-2021-47621.

Just a heads up this has been assigned CVE-2021-47621.

Are you sure you have that right? That CVE is for the Guest Entries PHP library -- it doesn't even apply to the Java ecosystem.

FYI the vulnerability in the original bug report had a very low likelihood of causing a problem (you'd have to have access to the build system to execute this vulnerability, and if you had that access, you could do a lot more malicious stuff than this.

The CVE is correct https://nvd.nist.gov/vuln/detail/CVE-2021-47621

@thc202 Oh, Google Search's top result when searching for that number was the wrong result, it was 2023-47621.

So let's consider the impact of this vulnerability in some detail, since it is still coming up 3 years later:

1. You'd have to be running a version of ClassGraph from 3+ years ago (and if you are updating your deps that infrequently, you should expect to be hit by security vulnerabilities and bugs!).
2. You would have to be running in a source tree or jar in which both the ClassGraph.class binary file and the pom.xml Maven config file are both present (i.e. this would not apply to production builds, shaded jars, etc.).
3. A hacker would have to have write access to the pom.xml file (which if they did, they could use this access to do much more nefarious things with a lot less effort).

Please correct me if I'm wrong, but I see this as a non-issue.