[jira] [Commented] (ZOOKEEPER-5038) Upgrade Jetty to address CVE-2026-2332

["Diego Rivera (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18089529#comment-18089529 ] 

Diego Rivera commented on ZOOKEEPER-5038:
-----------------------------------------

Hi, all!

I have no idea if this has been considered and discarded already, but has anyone considered a third approach by way of a [multi-release JAR|https://www.baeldung.com/java-multi-release-jar] where if one is using JDK 17, the JVM uses the classes that bind to the updated Jetty 12+ stuff, vs. people using the older JDKs (8, 11) can stick with the older, vulnerable stuff?

The `zkServer.sh` (et al) script(s) could be adjusted to detect the JVM version early, and set up the classpath using alternate supplementary directories that would include the appropriate Jetty stuff (i.e. `${zkHome}/lib-17` vs. `${zkHome}/lib-8` or whatever). Thus, the classpath could end up being something like `${zkHome}/lib-XX:${zkHome}/lib:....` 

The multi-release JARs would live in `${zkHome}/lib`, and the "supplementary" sets of JARs (i.e. Jetty 9 or Jetty 12) would each live in `${zkHome}/lib-${JDK_VER}` ... you could go with only two values for `${JDK_VER}`:  `17` for all JDKs >= 17, and `8` for all others:

- `${zkHome}/lib-17` contains the latest Jetty 12+ stuff, and is only "activated" when the launch scripts identify that you're using Java 17+
- `${zkHome}/lib-8` contains the old, outdated, never-to-be-fixed Jetty 9 stuff, and is activated for all Java versions prior to 17
- `${zkHome}/lib` contains all the common-use stuff that would be used regardless of which JVM is in use (any multi-release JARs would be stored here)

This might prove to be much less risky since you'd be leaving the older classes intact for people who are willing to accept the risk from the vulnerability without accruing additional risk from modifications, while being able to add the modified classes (i.e. the new classes using `jakarta.*`, etc., as described above) for use by everyone else.

This would at least provide relief for those of us facing issues to do that vulnerability coming up in security reports (i.e. for compliance reasons), and should be less labor intensive and less risky than either of the above scenarios.

Is this even a possiblity?

Cheers!

> Upgrade Jetty to address CVE-2026-2332
> --------------------------------------
>
>                 Key: ZOOKEEPER-5038
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-5038
>             Project: ZooKeeper
>          Issue Type: Task
>          Components: server
>    Affects Versions: 3.9.5, 3.8.6
>            Reporter: Jota Martos
>            Assignee: Dávid Paksy
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Jetty versions lower than 9.4.60 are affected by this CVE. 
> bq. Jetty incorrectly parses quoted strings in HTTP/1.1 chunked transfer encoding extension values, enabling request smuggling attacks.
> You can find more information in the [security advisory|https://github.com/jetty/jetty.project/security/advisories/GHSA-355h-qmc2-wpwf].



--
This message was sent by Atlassian Jira
(v8.20.10#820010)