DEV Community

Cover image for Debian 12 Bookworm EOL is June 10, 2026 — Your 18-Day Action Checklist
endoflife-ai
endoflife-ai

Posted on • Originally published at endoflife.ai

Debian 12 Bookworm EOL is June 10, 2026 — Your 18-Day Action Checklist

Debian 12 "Bookworm" regular security support ends June 10, 2026 — 18 days away.

Most teams know the date. Fewer know what actually changes on that date, or have done anything about it yet. This is the practical breakdown.


What actually changes on June 10

The Debian Security Team stops issuing patches. This is the team behind security.debian.org — the one that responds to CVEs within days and covers the full package archive.

What takes over: the Debian LTS Team — a separate group of volunteers — maintains approximately 230 packages on a best-effort basis until June 2028. Slower cadence, narrower scope.

The security.debian.org repository keeps working. But the team behind it changes, and so does what gets patched.


The three support phases (most people only know one)

Phase Dates Maintained by
Regular support Jun 2023 – Jun 10, 2026 Debian Security Team
LTS Jun 10, 2026 – Jun 30, 2028 Debian LTS Team (volunteers)
ELTS 2028 – Jun 2033 Freexian (paid)

Current upgrade target: Debian 13 "Trixie" — stable since August 2025, supported through 2028+.


The compound June 2026 timing

Two deadlines in the same 20-day window:

  • June 10 — Debian 12 regular support ends
  • June 30 — Debian 11 (Bullseye) LTS ends

If you're running both versions across different systems, you're facing a double migration in June. Plan accordingly.


The part developers miss: Docker base images

debian:12 and debian:bookworm are among the most common Docker base images in production. After June 10, every container you build on them has an EOL OS layer that will never receive another Debian Security Team patch — regardless of how current your application code is.

The fix is one line:

# Before
FROM debian:12

# After  
FROM debian:13
Enter fullscreen mode Exit fullscreen mode

Rebuild. Run your tests. For most standard application containers this is a drop-in change.

Also check: official application images like python:3.12, node:22, php:8.3 — if you're using non-alpine variants, verify which Debian version they currently build on. Some maintainers are slower to update base images than others.


If you can't upgrade by June 10

You don't have to panic. Debian LTS activates automatically after June 10 — no configuration change required. For standard server stacks (kernel, glibc, OpenSSL, nginx, Apache, PHP, Python) LTS coverage is likely adequate as a 3–6 month bridge while you plan the Debian 13 upgrade.

What you must do:

  1. Verify your critical packages are in the Debian LTS scope
  2. Document the transition in your risk register — compliance teams will ask
  3. Set a hard target date for Debian 13 — don't treat LTS as permanent

The upgrade in 4 steps

# 1. Bring Debian 12 fully current first
apt update && apt upgrade && apt full-upgrade

# 2. Update sources.list — replace bookworm with trixie
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
# Also update any files in /etc/apt/sources.list.d/

# 3. Run the upgrade
apt update && apt full-upgrade

# 4. Reboot and verify
reboot
lsb_release -a
Enter fullscreen mode Exit fullscreen mode

Use full-upgrade not upgrade — it handles package removals and replacements that occur during a major version transition.

Note: Debian 13 dropped i386 support. If you have 32-bit x86 systems or packages, check the Debian 13 release notes before upgrading.


Compliance implications

If your systems are in scope for a compliance framework, the June 10 transition needs to be documented before it happens — not discovered in an audit.

  • PCI DSS — requires vendor-supported software. Clarify with your QSA whether Debian LTS satisfies your requirements before June 10.
  • SOC 2 Type II — CC7.1 requires patch management. CVEs against packages outside LTS scope remain permanently open after June 10. Document your gap management.
  • ISO 27001 — Annex A.12.6.1 flags EOL systems. LTS must be documented as a managed compensating control.
  • FedRAMP — EOL OS in a FedRAMP boundary is a showstopper. Upgrade or obtain approved extended support before your assessment window.

Your checklist before June 10

  • [ ] Inventory every Debian 12 system — servers, VMs, containers, CI runners, build images
  • [ ] Audit Dockerfiles for debian:12 or debian:bookworm base images — update to debian:13
  • [ ] Update IaC templates (Terraform, Packer, Ansible) hard-coding Debian 12 image IDs
  • [ ] Verify LTS package coverage for systems you can't upgrade immediately
  • [ ] Document the support tier change in your risk register
  • [ ] Test the Debian 13 upgrade in a non-production environment first
  • [ ] Brief compliance and security teams — June 10 should be a calendar event
  • [ ] Set a 30-day post-June 10 review reminder to check for accumulating unpatched CVEs

EOL Risk Scores

Using the EOL Risk Score™ methodology — which weighs EOL recency, attack surface, CISA KEV exposure, and extended support availability:

Version Score Status
Debian 10 (Buster) 86 / Critical Fully EOL since Jun 2024
Debian 11 (Bullseye) 64 / High LTS ending Jun 30, 2026
Debian 12 (Bookworm) 55 / High Regular EOL Jun 10, 2026
Debian 13 (Trixie) 12 / Low Current stable

Debian 12's score rises after June 10 as the regular support phase closes. You can check live scores for every Debian version — and every product in your stack — at endoflife.ai.


EOL dates sourced from endoflife.date (MIT) and debian.org. Full Debian lifecycle guide with migration steps at endoflife.ai/article-debian-eol.html.

Top comments (0)