Hi all, Several open PRs override transitive dependency versions to clear CVE scanner findings:
- #5981: Brotli4j 1.23.0 -> 1.24.0 (CVE-2026-111497) - #5959: ZooKeeper 3.8.6 -> 3.8.7 (ZooKeeper server CVEs) - #5940: commons-configuration2 -> 2.15.1 (CVE-2026-45205) - #5939: Jetty 9.x -> 9.4.58 (CVE-2024-13009) I checked each one against the Polaris server and admin distributions, both from the 1.8.0 release and main, looking at the jars we actually ship and how each library is used. The good news is that none of these CVEs is exploitable in Polaris: 1. Brotli4j (CVE-2026-111497): the vulnerable code is the native Brotli decoder, which only ships in the Brotli4j native-* jars. We only ship the pure Java brotli4j and service jars, with no native Brotli library. Brotli4jLoader.isAvailable() returns false, so Netty never decodes "br" request bodies, and a direct decode attempt fails with UnsatisfiedLinkError before any native code runs. 2. ZooKeeper 3.8.6: every published CVE affecting 3.8.6 is in the ZooKeeper server. Polaris only uses the ZooKeeper client (through Ranger and Hadoop), and nothing we ship starts a ZooKeeper server. 3. commons-configuration2 (CVE-2026-45205): a StackOverflowError when parsing untrusted YAML with cycles. Nothing we ship uses the library's YAML support. 4. Jetty (CVE-2024-13009): the bug is in jetty-server, which we don't ship. We only ship jetty-client and its supporting jars. The overrides also would not make the scanners quiet: - hadoop-client-runtime bundles shaded copies of commons-configuration2 2.10.1 and Jetty 9.4.58. Gradle constraints and resolution rules can't change those, so the findings stay. - There are five more ZooKeeper CVEs also affect 3.8.7 (but Polaris is not impacted either ;)). - Scanners flag jetty-http 9.4.x for CVEs that 9.4.58 doesn't fix anyway. So I propose the following to you: - For Polaris 1.9.0, we accept these findings as false positive (they exist on 1.8.0 already as false positive). We don't block the release on them, and we don't add per-CVE version overrides to the build. Fixed versions come in through regular upgrades. - We publish our assesments as VEX documents, similar to what Apache Solr does (https://solr.apache.org/security-dependency-cves.html). I created #6001 (https://github.com/apache/polaris/pull/6001) to add a "CVE Status for Dependencies" page to the website, with one page per assessed CVE, and generate CycloneDX 1.6 and OpenVEX files form them. Users can point VEX-aware scanners such as Docker Scout at these files, so findings that don't apply to Polaris are dropped instead of each one becoming a PR. Adding a assessment is just adding a Markdown file, and we would review the entries as part of each release. - As a follow-up, we generate SBOMs for the distributions and container images. Thoughts? Regards JB
