Share this post
A vulnerability in Go's crypto/tls library (CVE-2025-68121) is currently affecting every version of Docker Engine except the most recent release. The CVSS score is 10.0 critical. Whether or not you believe this is genuinely dangerous in your environment, that score alone will trigger automated compliance alerts, and most enterprise security policies prohibit running software with a CVE above 9.0. The practical consequence is that this lands on someone's desk regardless of how you assess the actual risk.
Let’s explain what's actually going on, and why the fix is more involved than it looks.
What the vulnerability is
This is not a bug in Docker itself. It's a flaw in the Go standard library that affects any binary compiled with a vulnerable version of Go. The issue is in crypto/tls: under specific conditions involving TLS session resumption, certificate validation can be bypassed if the underlying TLS config is mutated between the initial handshake and a resumed one. Wiz's research team has noted that exploitation requires an attacker to already possess a previously valid certificate, which argues that the NVD score of 10.0 is aggressive... but that nuance does not change your compliance posture. The score is what it is, and your tooling will flag accordingly.
Which Docker versions are affected
All Go versions below 1.24.13, and Go 1.25.0 through 1.25.6, are vulnerable. Working through Docker's release history, that means (as of writing) every currently deployed Docker Engine version except 29.3.0. The entire 28.x branch shipped with Go 1.24.9 at its most recent patch and has not received a backported fix. The 29.x branch was vulnerable through 29.2.1, which shipped with Go 1.25.6. Docker Engine 29.3.0, released March 2026, is the first clean build.
You can verify what you're running with:
docker version --format '{{.Server.GoVersion}}'
If the output is anything below go1.24.13 or between go1.25.0 and go1.25.6, you're on a vulnerable build.
Why the update is not straightforward
The fix requires updating to Docker Engine 29.3.0. That means crossing the v29.0 boundary, which introduced breaking API changes with real operational consequences. Persistent volume drivers that were compatible with 28.x and earlier may not work correctly after the upgrade. Swarm behavior changed materially in v29.0 as well, with changes to encrypted overlay networking that directly affect production Swarm deployments.
The short version: do not trigger an automated update without testing first. If you have persistent storage drivers (anything beyond bind mounts and native NFS), validate those explicitly before rolling out to production. If you are running Docker Swarm at scale, the 29.0 API changes are significant enough to warrant a proper upgrade plan with a tested rollback path.
A word on Swarm specifically
If you are running Docker Swarm in production today, this vulnerability creates some pressure to address your orchestration strategy. Remediating CVE-2025-68121 requires an upgrade that meaningfully changes how Swarm behaves. That is not a reason to panic. It is, however, a reasonable prompt to ask whether the upgrade effort is better spent migrating toward Kubernetes rather than patching your way through another generation of a platform Docker Inc. has been quietly deprioritizing for years. If you have been deferring that conversation, this is a good moment to have it. Portainer supports both paths, and can manage a Kubernetes migration without forcing you to rebuild your entire operational model from scratch.
For more guidance around how to begin your migration from Docker Swarm to Kubernetes, we’ve prepared a whitepaper to outline your options and start you on your journey.
{{article-cta}}
We’re also here to help as well - reach out to our team for assistance.
A note on Portainer
Portainer is built as a Go binary, so it was also affected. Our latest LTS patch release (2.39.1) includes the updated Go runtime, and we recommend upgrading Portainer alongside your Docker update if you haven’t already.
.png)
.png)
