What's the problem?
Several services build their container images with the official Go builder image and were still pinned to Go 1.26.3. The Go 1.26.3 standard library contains a HIGH-severity vulnerability, CVE-2026-42504, which is fixed in Go 1.26.4 (and 1.25.11).
Our CI runs a Trivy image scan that fails on CRITICAL/HIGH findings (ignore-unfixed). Because a fix exists, any service still building on the 1.26.3 image fails that scan on its next PR — even when the PR has nothing to do with the vulnerable code.
What we did
Bumped the builder image in each affected Dockerfile from golang:1.26.3 to golang:1.26.4 (the patched release), keeping each file's existing registry-prefix style. This is a build-time-only change: rebuilding on 1.26.4 picks up the patched standard library. No application/Go code changes were needed — every go.mod go directive is already <= 1.26.x and is unaffected by the builder bump.
Services and status
| Service |
Builder image |
Done in |
| dis-pgsql-operator |
golang:1.26.4 |
#3676 |
| dis-console |
golang:1.26.4 |
#3726 |
| dis-apim-operator |
docker.io/golang:1.26.4 |
#3680 |
| dis-identity-operator |
docker.io/golang:1.26.4 |
#3680 |
| dis-vault-operator |
golang:1.26.4 |
#3680 |
| lakmus |
golang:1.26.4-alpine |
#3680 |
The remaining services (dis-apim-operator, dis-identity-operator, dis-vault-operator, lakmus) are addressed by #3680.
Note on lakmus
lakmus previously pinned an exact image digest (golang:1.26.3-alpine@sha256:...). We bumped it to the plain golang:1.26.4-alpine tag and dropped the digest. Renovate manages the digest pins for these Go images and will open a follow-up PR to re-pin the digest, so the tag is intentionally left bare for now.
🤖 Generated with Claude Code
What's the problem?
Several services build their container images with the official Go builder image and were still pinned to Go 1.26.3. The Go 1.26.3 standard library contains a HIGH-severity vulnerability, CVE-2026-42504, which is fixed in Go 1.26.4 (and 1.25.11).
Our CI runs a Trivy image scan that fails on CRITICAL/HIGH findings (
ignore-unfixed). Because a fix exists, any service still building on the 1.26.3 image fails that scan on its next PR — even when the PR has nothing to do with the vulnerable code.What we did
Bumped the builder image in each affected Dockerfile from
golang:1.26.3togolang:1.26.4(the patched release), keeping each file's existing registry-prefix style. This is a build-time-only change: rebuilding on 1.26.4 picks up the patched standard library. No application/Go code changes were needed — everygo.modgodirective is already <= 1.26.x and is unaffected by the builder bump.Services and status
golang:1.26.4golang:1.26.4docker.io/golang:1.26.4docker.io/golang:1.26.4golang:1.26.4golang:1.26.4-alpineThe remaining services (dis-apim-operator, dis-identity-operator, dis-vault-operator, lakmus) are addressed by #3680.
Note on lakmus
lakmuspreviously pinned an exact image digest (golang:1.26.3-alpine@sha256:...). We bumped it to the plaingolang:1.26.4-alpinetag and dropped the digest. Renovate manages the digest pins for these Go images and will open a follow-up PR to re-pin the digest, so the tag is intentionally left bare for now.🤖 Generated with Claude Code