Thanks a lot for working on this, JB! The approach looks good to me. I will take a look at the PR.
Yufei On Fri, Nov 6, 2026 at 8:05 AM Jean-Baptiste Onofré <[email protected]> wrote: > > 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
