rantoniuk opened a new issue, #6853:
URL: https://github.com/apache/jmeter/issues/6853
### Use case
JMeter 5.6.3 was released in January 2024 and is still the latest release.
Many of us run JMeter in environments where security scanners gate what is
allowed in production or in CI, and 5.6.3 now fails those gates. The 6.0.0
milestone is moving forward (thanks for all the work on it!), but it raises the
baseline to Java 17 and carries larger behaviour changes, so even after it
ships a lot of users will need some time to migrate.
This issue tries to collect in one place what a 5.x maintenance release
would need, so it can be discussed and tracked. Related threads:
- #6766 Expected timeline for new JMeter release
- #6424 Security Vulnerability Roadmap Inquiry
- #6714 Security Update: Address high/critical CVEs in dependencies
- #6653 Log4j issue CVE-2025-68161 in JMeter 5.6.3
- #6701 fix(deps): backport security fixes to 5.6.x (open, last updated
2026-07-10)
- dev@ thread "Dependency updates for 5.6.x branch" (2026-05-24)
### Needs
#### 1. Security (dependency CVEs)
#6701 already does the heavy lifting on `release/5.6.x`: xstream,
json-smart, json-path, jackson, log4j, batik, dnsjava, commons-lang3,
neo4j-java-driver (shaded netty, see #6714), and dropping `tika-parsers` from
the runtime classpath. Its description also documents the accepted,
not-reachable `tika-core` CVE-2025-66516 and the unpatched jackson
GHSA-5jmj-h7xm-6q6v.
What seems to be missing is review, CI on the full matrix and a release
vote. Downstream users can help with smoke runs against their own plans (see
"How we can help" below).
#### 2. Unmaintained dependencies
Some shipped jars are not affected by known CVEs today, but they are
unmaintained, so nobody will fix them if a CVE turns up. They also get flagged
by licence and supply-chain policies (for example, `oro` declares no licence in
its POM):
| Jar | Status | Fix on master | Notes for 5.x |
|---|---|---|---|
| `xmlpull:xmlpull:1.1.3.1`, `io.github.x-stream:mxparser` | xmlpull
unmaintained since ~2006 | 920fa60dc "chore: replace xmlpull with Woodstox" |
Needs #6767 (fix for #6761) before it is safe in any release |
| `oro:oro:2.0.8` | Apache Attic | #6661 switches the default regex engine
to the JDK (open) | `HTTPArgument`/`EncoderCache` still uses
`org.apache.oro.util.CacheLRU`, so the jar cannot be dropped yet even after
#6661 |
#### 3. Java compatibility
The 5.x line keeps Java 8 as a hard rule (per #6701). I checked the bytecode
level of the jars the xmlpull replacement would add:
| Artifact | Class file major | Java 8 OK? |
|---|---|---|
| `com.fasterxml.woodstox:woodstox-core:7.1.0` | 52 | yes |
| `org.codehaus.woodstox:stax2-api:4.2.2` | 50 | yes |
| `org.glassfish.jaxb:txw2:4.0.6` (used for `IndentingXMLStreamWriter`) | 55
| **no** |
| `org.glassfish.jaxb:txw2:2.3.9` (same `com.sun.xml.txw2` package) | 52 |
yes |
The Kotlin and Java changes in 920fa60dc look Java 8 compatible to me (5.6.x
already builds Kotlin), so a backport looks possible with `txw2` 2.3.9 instead
of 4.0.6. I have not built it, so please treat this as a starting point, not a
verified result.
### Possible solution
Two options, depending on how much maintainer time is available:
**A. 5.6.4: security only (smallest step)**
- Merge #6701 as is and release it from `release/5.6.x`.
- No behaviour changes, no new or removed jars apart from `tika-parsers`.
**B. 5.7: A plus selected low-risk modernisation**
- Everything in A.
- Backport 920fa60dc (xmlpull/mxparser to Woodstox) with `txw2` 2.3.9,
**only after** #6767 is merged on master and passes the #6761 attachments and
5.6.3 legacy files.
- Optionally backport #6661 (JDK regex as default, ORO opt-in).
- Release notes must call out user-visible changes:
- `xmlpull` and `mxparser` removed from `lib/`, so plugins that call `new
XStream()` or use `XppDriver` need to bundle them
- JMX/JTL serialization differences: empty elements written as `<x/>`,
empty values omitted, header written by the StAX writer
- StAX factory is fixed to Woodstox
If B is too much for now, A alone would already unblock most of the people
in #6424, #6714 and #6766.
### Possible workarounds
- Replacing jars in `lib/` by hand (as suggested in #6653). This works for
single libraries, but it is hard to do for transitive or shaded ones, and it is
not something most organisations can sign off.
- Nightly builds. These are not acceptable in many regulated environments,
and they include the open 6.0 regressions (for example #6761).
### How we can help
We use JMeter 5.6.3 through jmeter-java-dsl in a CI performance suite and
can:
- run our suite against a `release/5.6.x` build or a release candidate and
report results here or on dev@
- test a 5.7 backport of the Woodstox change against our JTL/JMX files
### JMeter Version
5.6.3
### Java Version
Not specific to one version; the point is that the 5.x line keeps working on
Java 8
### OS Version
Any
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
