CVE: Test Dependency io.undertow:undertow-core 2.2.37.Final

[hughpearse]

Description
A test dependency in the main pom.xml has a number of CVEs with a CVSS score as high as 7.5. This is not shipped with the main artefact but will interfere with any corporate approvals process.

Vulnerabilities:
CVE-2024-7885
CVE-2024-6162
CVE-2024-5971
CVE-2024-3653

Cause:
Test Dependency io.undertow:undertow-core 2.2.37.Final

Reference

1. https://mvnrepository.com/artifact/com.networknt/json-schema-validator/1.5.3
2. https://mvnrepository.com/artifact/io.undertow/undertow-core/2.2.37.Final
3. https://github.com/networknt/json-schema-validator/blob/1.5.3/pom.xml#L83

[justin-tay]

mvnrepository typically has incorrect information about CVEs. You should take it up to them or whatever tooling you are using.

You can refer to GitHub's Advisory Database or even Undertow's release notes https://github.com/undertow-io/undertow/releases. 2.2.37.Final should not have the CVEs you have listed.

CVE-2024-7885 < 2.2.36.Final
CVE-2024-6162 < 2.2.33.Final
CVE-2024-5971 < 2.2.34.Final
CVE-2024-3653 < 2.2.34.Final

[stevehu]

Since our project is now feature complete, it’s a good time to release with Java 11 as the main version while still supporting our loyal users who cannot upgrade from Java 8. We’ll keep a Java 8 branch, versioned under the 1.5.x tag, which will receive only backported bug fixes as needed. The new Java 11 release will be marked with a 2.0.x tag, allowing us to move forward with modern enhancements. This approach balances progress with continued support for our long-time users and provides a clear path forward for both versions. What do you think?

[justin-tay]

I think it depends of what else is planned for 2.0.x. One of the breaking change I would like to make is to change the return result from Set to List for performance. We can also remove all the deprecated methods. I think it would make sense to have a period where development of 2.0.x is done without cutting a release to incorporate breaking changes.

[stevehu]

You have the point, we cannot create 2.0.x just for Java versions. It will confuse our users. Let's wait for other breaking changes. We can branch out 1.5.x once we have the first breaking change.

[kmalski]

What do you think about targeting Java 17 (or even higher e.g. 21), instead of 11? Is there any reason to upgrade only to Java 11?

[stevehu]

Some users are on Java 8 and Java 11 now and we have to support them at the moment. We can discuss the upgrade to Java 17 and 21 once we need features from Java 17/ 21.