vlsi opened a new pull request, #6701:
URL: https://github.com/apache/jmeter/pull/6701
## Goal
Security patch line for JMeter **5.6.x** aimed at users who cannot
immediately upgrade to the upcoming JMeter 6.0. The branch starts from
the `rel/v5.6.3` tag and only carries dependency bumps with the smallest
viable version change for each CVE. Hard rules:
- avoid major version bumps where possible,
- minimize minor bumps,
- the build/runtime **must keep working on Java 8**.
Methodology: CycloneDX SBOM (full transitive resolution) generated from
`runtimeClasspath` + `compileClasspath` of every subproject, scanned
with `osv-scanner`. Results were filtered to the jars actually shipped
in the release distribution (`src/dist/src/dist/expected_release_jars.csv`).
Test/build-only deps (commons-fileupload, guava, jetty.\*,
bcprov/bcpkix-jdk15on, xmlunit-core) are listed by the scanner but are
not part of any release artifact, so they are out of scope.
## Fixed CVEs (shipped in `expected_release_jars.csv`)
| Severity | CVSS | Package | From → To | CVE / GHSA |
|----------|------|---------|-----------|------------|
| High | 7.7 | `com.thoughtworks.xstream:xstream` | 1.4.20 → 1.4.21 |
CVE-2024-47072 |
| Low | 2.7 | `org.mozilla:rhino` | 1.7.14 → 1.7.14.1 | CVE-2025-66453 |
| High | 7.5 | `net.minidev:json-smart` (+ `accessors-smart`) | 2.5.0 →
2.5.2 | CVE-2024-57699 |
| Medium | 5.3 | `com.jayway.jsonpath:json-path` | 2.8.0 → 2.9.0 |
CVE-2023-51074 |
| Medium | 6.9 |
`com.fasterxml.jackson.core:jackson-{core,databind,annotations}` | 2.16.1 →
2.18.6 | GHSA-72hv-8253-57qq |
| Medium | 6.9 |
`org.apache.logging.log4j:{log4j-api,log4j-core,log4j-1.2-api,log4j-slf4j-impl}`
| 2.22.1 → 2.25.4 | CVE-2025-68161, CVE-2026-34477, CVE-2026-34478,
CVE-2026-34479, CVE-2026-34480 |
| High | 7.1 / 4.4 | `org.apache.xmlgraphics:batik-*` (18 artifacts) | 1.16
→ 1.17 | CVE-2022-44729, CVE-2022-44730 |
| High | 8.9 | `dnsjava:dnsjava` | 2.1.9 → 3.6.5 | CVE-2024-25638 |
| Critical | 10.0 / 9.8 | `org.apache.tika:tika-parsers` | **removed from
runtime classpath** | CVE-2025-54988, GHSA-p72g-pv48-7w9x |
| Medium | 6.5 | `org.apache.commons:commons-lang3` | 3.14.0 → 3.18.0 |
CVE-2025-48924 |
Notes on the non-trivial bumps:
- **jackson 2.16 → 2.18.6** required a one-character test fixture update
(`TestJMESPathAssertion`): jackson-core's parser error column index was
tightened from 3 to 2.
- **json-path 2.9.0** pulls slf4j-api 2.x transitively; since
`log4j-slf4j-impl 2.25.x` is still built against slf4j 1.x and a
coordinated slf4j 2.x migration is out of scope for 5.6.x,
`slf4j-api`/`jcl-over-slf4j` are pinned with `strictly(\"1.7.36\")`.
- **batik 1.16 → 1.17** is a transitive bump pulled in by `lets-plot-batik
4.1.0`.
No `batik-bom` is published, so each of the 18 batik artifacts is
explicitly constrained in `src/bom-thirdparty/build.gradle.kts`.
- **dnsjava 2 → 3** is the only available fix (no 2.x patch). The bump
is source-compatible after replacing `Resolver#setTimeout(int, int)`
with the `Duration` overload and adjusting one test
(`ResolverConfig#servers()` now returns `List<InetSocketAddress>`).
`DnsManagerTest` is removed (mirrors master commit `c6c6c07e5`): the
test relied on a 2.x quirk and upstream replaced it with a
MockDnsServer-based suite that is out of scope here.
- **tika-parsers is dropped entirely** (mirrors master commit `23fa6d530`).
JMeter only used `Tika.detect` / `AutoDetectParser` from `tika-core`;
the parsers monolith was never wired into the public JMeter API.
Dropping it eliminates those parser CVEs and reduces the release size.
`tika-core` is bumped 1.28.5 → 2.9.4 — see *Known unresolved* below.
- **commons-lang3 3.18.0** deprecated several widely-used helpers
(`ObjectUtils.defaultIfNull`, `StringUtils.startsWith/endsWith/…`,
`RegExUtils.replaceAll`, `RandomStringUtils.random`). Since `-Werror`
is on, each call site is annotated with
`@SuppressWarnings(\"deprecation\")`
at the narrowest scope that still compiles. A follow-up can rewrite
the call sites to core Java once the dependency is gone (see master's
`b362137` for the pattern).
- A separate `build: refresh stale checksum entries for xerces and xml-apis`
commit fixes a pre-existing problem in `checksum.xml`: the recorded
SHA-512 for `xerces:xercesImpl:2.9.1` no longer matched the artifact
served by Maven Central, and `xml-apis:xml-apis:1.3.04` was missing
altogether, both blocking any fresh checkout from passing
`verifyReleaseDependencies`.
## Known unresolved CVEs
- **`org.apache.tika:tika-core` CVE-2025-66516 (CVSS 10.0)** — fix is in
Tika 3.2.2+. Tika 3.x is compiled for Java 11 (class file major version
55),
so it cannot be loaded by a Java 8 JVM. Per the Java 8 hard rule for
this branch, the bump is **not** applied; tika-core stays at 2.9.4.
The bump from 1.28.5 to 2.9.4 still helps — it dropped one earlier 1.x
CVE — but CVE-2025-66516 is accepted risk on 5.6.x. Users who need a
full fix should upgrade to JMeter 6.0 (Java 17 target).
## Scope (NOT in this PR)
- jetty 9.4.\*, commons-fileupload 1.4, guava 31.1-jre,
bcprov/bcpkix-jdk15on 1.70,
xmlunit-core 2.9.0 — flagged by the scanner but only present in test
or build configurations; not part of `expected_release_jars.csv`,
therefore not shipped to end users.
- Wholesale removal of commons-lang3 (master's b362137) — that change
spans 200+ files and uses Java 17 syntax; out of scope for a 5.6.x
patch line.
## Verification
Every commit was validated by:
1. `./gradlew -Prelease -PchecksumUpdateAll -PupdateExpectedJars
verifyReleaseDependencies`
to refresh `checksum.xml` and
`src/dist/src/dist/expected_release_jars.csv`.
2. `./gradlew -Prelease --continue build` on the JDK 8 toolchain
(`jdkTestVersion=8`, JDK 8 was auto-provisioned by
`foojay-resolver-convention`).
Two network-flaky batch tests (`batchTEST_HTTPJava`,
`batchHttp4ImplPreemptiveBasicAuth`) were excluded from the local
loop — CI should run the full matrix.
--
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]
