You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Trivy detects CVEs in Version v1.10.0,
most of them can be fixed by upgrading stdlib from "1.26.0" to "1.26.1" and docker from "v28.5.2+incompatible" to "29.3.1"
Thanks for the detailed report. Here's where things stand:
stdlib CVEs (CVE-2026-25679, CVE-2026-27137, CVE-2026-27142, CVE-2026-27138, CVE-2026-27139): These were reported against v1.10.0 which was built with Go 1.26.0. The main branch is currently on Go 1.25.9 and govulncheck reports no known vulnerabilities. We'll evaluate upgrading the Go toolchain for the next release to pick up the stdlib fixes.
Adding the current CVE set scanners report against the v1.10.0 release binaries, for anyone tracking: Go stdlib go1.26.0 → CVE-2026-39822 (os.Root), CVE-2026-27145 (crypto/x509 hostname parsing), CVE-2026-42505 (crypto/tls ECH); golang.org/x/crypto v0.48.0 → CVE-2026-39835 (ssh CertChecker panic). All are fixed by a release built on Go >= 1.26.5 with current deps — same toolchain-bump ask as the original issue. Thanks!
Certificate validation issue allows multiple email address constraints with common local portions but different domain portions to be improperly applied.
Certificate verification can panic when a certificate in the chain has an empty DNS name and another certificate in the chain has excluded name constraints, potentially crashing programs using TLS.
crypto/x509 and crypto/tls are vulnerable to a denial of service due to excessive work done during chain building with a large number of intermediate certificates.
Certificate validation is unexpectedly inefficient when processing chains with a large number of policy mappings, potentially causing denial of service.
Docker is vulnerable to arbitrary code execution with full daemon privileges due to incorrect ordering of operations when resolving decompression binaries from a container's filesystem.
Docker is affected by a race condition during docker cp mount setup, allowing a malicious container to redirect a bind mount target to an arbitrary host path.
The v1.10.0 tag pins x/crypto v0.48.0; main currently pins v0.54.0, so neither dependency version contains all three fixes. Please include x/crypto v0.56.0 or newer in the next official release and check the release binaries with govulncheck.
These advisories concern SSH paths. This is a dependency-version report, not a claim that the affected SSH symbols are reachable through sqlcmd.
One data point for the release. Built from main at b359e41 for linux/arm64 with Go 1.26.8, Trivy 0.74.0 reports one HIGH (golang.org/x/crypto 0.54.0, CVE-2026-56854). With x/crypto at 0.57.0 it reports none at HIGH or CRITICAL, and the binary runs scripts against SQL Server 2022 as expected. The 1.10.0 release binary reports 40 the same way. Could 1.11.0 (#740) include the x/crypto bump, and is anything blocking it that users could help with?
Activity
shueybubbles commentedon Apr 13, 2026
some of those links give 404
FrankAnk commentedon Apr 13, 2026
Yes correct. Some seem to have been removed.
I`ve corrected the list.
dlevy-msft-sql commentedon Apr 17, 2026
Thanks for the detailed report. Here's where things stand:
stdlib CVEs (CVE-2026-25679, CVE-2026-27137, CVE-2026-27142, CVE-2026-27138, CVE-2026-27139): These were reported against v1.10.0 which was built with Go 1.26.0. The main branch is currently on Go 1.25.9 and govulncheck reports no known vulnerabilities. We'll evaluate upgrading the Go toolchain for the next release to pick up the stdlib fixes.
Docker CVEs: The deprecated github.com/docker/docker dependency has already been removed from main and replaced with the supported github.com/moby/moby modules (Migrate off deprecated github.com/docker/docker to supported Docker/Moby SDK modules #727, now closed).
We're tracking this for the next release. govulncheck is now part of our CI pipeline to catch these proactively going forward.
esetnik commentedon Jul 22, 2026
Adding the current CVE set scanners report against the v1.10.0 release binaries, for anyone tracking: Go stdlib go1.26.0 → CVE-2026-39822 (os.Root), CVE-2026-27145 (crypto/x509 hostname parsing), CVE-2026-42505 (crypto/tls ECH); golang.org/x/crypto v0.48.0 → CVE-2026-39835 (ssh CertChecker panic). All are fixed by a release built on Go >= 1.26.5 with current deps — same toolchain-bump ask as the original issue. Thanks!
markusboehme commentedon Jul 27, 2026
David Levy (@dlevy-msft-sql) Is there a release roadmap or ETA for the next release that can be shared?
scsaba commentedon Aug 26, 2026
David Levy (@dlevy-msft-sql) could you please share any update on this issue?
Spectra Assure reported the following vulnerabilities in sqlcmd.exe:
esetnik commentedon Sep 12, 2026
[Written by Claude]
Three additional published x/crypto advisories are relevant to the dependency refresh for the next release:
The v1.10.0 tag pins x/crypto v0.48.0; main currently pins v0.54.0, so neither dependency version contains all three fixes. Please include x/crypto v0.56.0 or newer in the next official release and check the release binaries with govulncheck.
These advisories concern SSH paths. This is a dependency-version report, not a claim that the affected SSH symbols are reachable through sqlcmd.
SQLHorizons commentedon Oct 5, 2026
One data point for the release. Built from
mainat b359e41 for linux/arm64 with Go 1.26.8, Trivy 0.74.0 reports one HIGH (golang.org/x/crypto 0.54.0, CVE-2026-56854). With x/crypto at 0.57.0 it reports none at HIGH or CRITICAL, and the binary runs scripts against SQL Server 2022 as expected. The 1.10.0 release binary reports 40 the same way. Could 1.11.0 (#740) include the x/crypto bump, and is anything blocking it that users could help with?djkormo commentedon Oct 25, 2026
My PR #820 is ready to review.