Repository navigation
transport-zerodep 3.7.1 bundles httpcore5 5.3.6 affected by CVE-2026-54399/CVE-2026-54428 (fixed in 5.4.3) — please cut a release with the fixed version #2672
Description
Summary
com.github.docker-java:docker-java-transport-zerodep:3.7.1 (latest release) shades Apache httpcore5 5.3.6 (and httpclient5 5.5.1). httpcore5 up to and including 5.4.2 is affected by:
- CVE-2026-54399 — memory exhaustion DoS in the HTTP/1.1 message parser (GHSA-hf6x-8p5f-cgmf), fixed in 5.4.3;
- CVE-2026-54428 — memory exhaustion DoS in the HPACK decoder before the SETTINGS ACK (GHSA-v3jc-474w-2wm6), fixed in 5.4.3 (
httpcore5-h2).
Because the classes are shaded into the zerodep artifact, downstream dependencyManagement pins cannot remediate this — only a new docker-java release embedding httpcore5/httpcore5-h2 ≥ 5.4.3 can. Both CVEs are CVSS 7.5 and fail any OWASP Dependency-Check gate with failBuildOnCVSS=7, including for every Testcontainers user (the latest Testcontainers release still depends on docker-java 3.7.1).
Evidence
$ unzip -p docker-java-transport-zerodep-3.7.1.jar \
META-INF/maven/org.apache.httpcomponents.core5/httpcore5/pom.properties | grep version
version=5.3.6
Ask
Please cut a patch release (3.7.2 or later) with the shaded httpcore5/httpcore5-h2 upgraded to ≥ 5.4.3.
Reacted by Wytze Gelderloos, Spoon-Sanding, merkuspunto, sebastiendupire-ctie, HuardT, Sébastien DUPIRE, Inge Becht, Tim Mewe, Godo, Daniel Pflüger and 7 more
Activity
Wytzepakito commentedon Aug 19, 2026
I would love to help out and make a release but I'm not a maintainer 😿
NeilTheDevGuy commentedon Aug 20, 2026
There is also CVE-2026-71290 (Improper TLS hostname verification vulnerability) in httpclient5 5.5.1, which is rated CVSS 9.1 Critical.
This urgently needs updating to 5.6.4
ryj3k commentedon Sep 29, 2026
Hello. Please bump this httpclient5 version. I have critical vulnerability on my production projects just because tests :(
ngreengo commentedon Oct 29, 2026
Hi, do you have any news regarding the task?
jpmartins-ca commentedon Oct 29, 2026
I believe vulnerability scanners treat test-scoped dependencies differently from compile-scoped dependencies.
If you're using a multi-module Maven setup, it may be worth checking whether test-related dependencies are being exposed through intermediate modules that do not end up in the production artifact but declare them with compile scope.
If Testcontainers is the source of the finding, and since this is a shaded transitive dependency, I did not find many options to address it directly. One possible workaround, which I used in a somewhat similar situation, is to ensure that Testcontainers remains strictly test-scoped. This may require some refactoring, especially if you have shared test-code modules consumed by other projects, but it can help prevent test-only dependencies from leaking into what vulnerability scanners perceive as production dependency trees.