v0.7.1 (2025-08-19) is built with Go 1.24.6. Scanning the published linux-amd64 binary today reports 22 HIGH Go stdlib CVEs that already have fixes available upstream — among them CVE-2026-56853 (net/http), CVE-2026-56858 (html/template), CVE-2026-56862 (crypto/tls), CVE-2026-33818 (encoding/asn1), CVE-2026-56859 (encoding/xml) and CVE-2026-56860 (net/url).
This isn't a maintenance concern — the repo is clearly active, with commits landing daily. It's a gap between commit cadence and release cadence: the last tag is a year old, so there's no published artifact carrying a current toolchain.
The impact falls on downstream consumers who install the release binaries. Because these are Go toolchain issues rather than d2 bugs, there is nothing a consumer can patch and nothing to report as a defect in d2 itself — the findings simply sit in every image that ships the binary, failing container security gates with no available remediation.
What we measured
We ship d2 in a server-side image (it backs an SVG rendering endpoint), so we had to work through this. Scanning the same v0.7.1 three ways, against one vulnerability-database snapshot:
| build |
HIGH/CRITICAL with fixes available |
| published v0.7.1 tarball |
30 |
go build of v0.7.1 with Go 1.25.13 |
8 |
| same, plus minimum-version bumps of four dependencies |
0 |
Two things worth passing on:
A rebuild alone clears 22. Every stdlib finding disappears just by compiling the existing tag with a current Go — no code change of any kind.
The remaining 8 are dependency pins, and they move cleanly. They sit in golang.org/x/net (×5), golang.org/x/text, golang.org/x/image, and github.com/go-jose/go-jose/v3. Bumping those four to current — x/net v0.58.0, x/text v0.41.0, x/image v0.45.0, go-jose v3.0.5 — takes it to zero.
We checked that bump is behaviourally neutral before relying on it: the resulting binary renders 20 of our own diagrams (including near:-positioned and grid layouts) byte-identically to the unbumped build. That's not a proof of general equivalence, but it's some evidence the dependency bumps are uneventful.
The ask
A tagged release built with a current Go 1.25.x would clear the 22 stdlib findings with no code change at all. Bumping those four dependencies in the same release would clear the rest.
If cutting releases by hand for toolchain refreshes isn't something you'd want to take on, a scheduled job that rebuilds and re-tags against the current Go minor series would cover it — that's a fairly common pattern for Go CLIs with a slower feature cadence.
We've worked around it by building from source with a pinned module graph, which is fine for us but isn't available to anyone consuming the release artifacts.
Thanks for d2 — the tool is genuinely excellent, and this is the only friction we've hit with it. Happy to supply the full scan output or the module manifest we used if either would be useful.
v0.7.1 (2025-08-19) is built with Go 1.24.6. Scanning the published
linux-amd64binary today reports 22 HIGH Go stdlib CVEs that already have fixes available upstream — among them CVE-2026-56853 (net/http), CVE-2026-56858 (html/template), CVE-2026-56862 (crypto/tls), CVE-2026-33818 (encoding/asn1), CVE-2026-56859 (encoding/xml) and CVE-2026-56860 (net/url).This isn't a maintenance concern — the repo is clearly active, with commits landing daily. It's a gap between commit cadence and release cadence: the last tag is a year old, so there's no published artifact carrying a current toolchain.
The impact falls on downstream consumers who install the release binaries. Because these are Go toolchain issues rather than d2 bugs, there is nothing a consumer can patch and nothing to report as a defect in d2 itself — the findings simply sit in every image that ships the binary, failing container security gates with no available remediation.
What we measured
We ship d2 in a server-side image (it backs an SVG rendering endpoint), so we had to work through this. Scanning the same
v0.7.1three ways, against one vulnerability-database snapshot:go buildof v0.7.1 with Go 1.25.13Two things worth passing on:
A rebuild alone clears 22. Every
stdlibfinding disappears just by compiling the existing tag with a current Go — no code change of any kind.The remaining 8 are dependency pins, and they move cleanly. They sit in
golang.org/x/net(×5),golang.org/x/text,golang.org/x/image, andgithub.com/go-jose/go-jose/v3. Bumping those four to current —x/net v0.58.0,x/text v0.41.0,x/image v0.45.0,go-jose v3.0.5— takes it to zero.We checked that bump is behaviourally neutral before relying on it: the resulting binary renders 20 of our own diagrams (including
near:-positioned and grid layouts) byte-identically to the unbumped build. That's not a proof of general equivalence, but it's some evidence the dependency bumps are uneventful.The ask
A tagged release built with a current Go 1.25.x would clear the 22 stdlib findings with no code change at all. Bumping those four dependencies in the same release would clear the rest.
If cutting releases by hand for toolchain refreshes isn't something you'd want to take on, a scheduled job that rebuilds and re-tags against the current Go minor series would cover it — that's a fairly common pattern for Go CLIs with a slower feature cadence.
We've worked around it by building from source with a pinned module graph, which is fine for us but isn't available to anyone consuming the release artifacts.
Thanks for d2 — the tool is genuinely excellent, and this is the only friction we've hit with it. Happy to supply the full scan output or the module manifest we used if either would be useful.