On 12 September 2026 Debian released 13.7, the seventh point release of trixie. It fixed buffer overflow and underflow issues in glibc (CVE-2026-5928 and CVE-2026-5450) and rebuilt a long list of packages against the updated library, including bash, busybox and docker.io. If your service image sits on a Debian base, a fixed base tag on the registry does nothing until you rebuild your own image on top of it.
What's affected
Any image built FROM Debian 13 (trixie) before the point release was published, and not rebuilt since, still carries the old glibc and the packages built against it. The same applies to derived bases such as language images that use Debian underneath.
The Debian news page also records two lifecycle dates that matter for base image choice: Debian 11 Long Term Support reached end of life on 31 August 2026, and security support for Bookworm (Debian 12) was handed over to the LTS team on 12 July 2026. Images still on bullseye no longer get fixes from Debian's LTS team.
How to check if you're exposed
Measure the gap between your image and the base. This method uses only public data. On 18 October 2026 we queried the Docker Hub API for the last update time of a few official tags:
for t in debian/tags/trixie-slim debian/tags/13.7-slim debian/tags/bookworm-slim \
ubuntu/tags/24.04 alpine/tags/3.22; do
curl -s "https://hub.docker.com/v2/repositories/library/$t" \
| jq -r '[.name, .last_updated] | @tsv'
done
The results that day: trixie-slim, 13.7-slim and bookworm-slim all showed 6 October 2026 (12 days earlier), ubuntu:24.04 showed 17 October 2026 (1 day), and alpine:3.22 showed 18 September 2026 (30 days). The takeaway is that base tags move on their own schedule, and a fixed date in your Dockerfile history tells you nothing about the tag today.
Compare with your image. Record the base digest at build time as a label, then compare it with what the tag points to now:
docker buildx imagetools inspect debian:trixie-slim
What to do now
- Add a scheduled rebuild. Weekly is a reasonable floor for services that take traffic, and it should also fire when the base tag's digest changes.
- Rebuild without stale layers. The Docker build reference documents a pull flag that always attempts to pull referenced images and a no-cache flag that skips the cache:
docker buildx build --pull --no-cache -t registry.example.com/app:$(date +%Y%m%d) .
- Pin the base by digest in the Dockerfile and let an update bot propose digest bumps, so every base change goes through your tests and review.
- Generate an SBOM and provenance attestation at build time using the build flags for SBOM and provenance, and scan the result before it is pushed.
- Retire images on end-of-life bases. Move bullseye images to trixie, and plan the bookworm move before LTS support ends.
- Redeploy. A rebuilt image that no pod runs protects nothing, so make the rollout part of the schedule.
Why it matters
A base image advisory has two clocks. The upstream fix arrives on the distribution's schedule, and your image gets it only on yours. Teams that rebuild on release day rarely notice the gap, and teams that rebuild at each product release carry it for months.
Rebuilding is cheap if you test well. The expensive part is the fear of an unreviewed change, which digest pinning and a build gate remove.
Try it yourself
Pick one production image. Find its build date and the base tag's last update using the commands above, write the gap in days, and set a rebuild job that would have closed it. Then scan an image to see what the old base carries.
Click through it at your own pace, or open it full screen.
Quick check
Why is a fresh base tag on Docker Hub not enough?
Your image was built from an older copy of the base. It only picks up the fix when you rebuild and redeploy.
Which Debian release lost LTS support on 31 August 2026?
Debian 11 (bullseye).
