Debian 12 Is Now EOL —
support ended June 10, 2026. What to do today

Debian 12 "Bookworm" was released on June 10, 2023 — exactly three years before its regular support ends. On June 10, 2026, the Debian Security Team stops issuing patches. This does not mean Debian 12 immediately becomes unsupported — it transitions to LTS — but the team, the pace, and the scope of security coverage all change. Understanding that difference is what determines your actual risk.

What Actually Changes on June 10

Most coverage of Debian EOL stops at the date. Here is what the transition means operationally.

What stops

The Debian Security Team — responsible for the official security.debian.org repository — stops issuing patches for Debian 12. This team responds to CVEs within days and covers the full package archive. It is the source of every security update prompt you see when running apt upgrade.

What continues (LTS)

A separate Debian LTS Team — volunteers and Freexian-sponsored contributors — takes over. They maintain approximately 230 of the most critical packages and issue patches on a best-effort basis. Response time is slower and scope is narrower.

The Exact Dates, Stated Plainly

Version	Regular EOL	LTS EOL	Status
Debian 10 (Buster)	Aug 2022	Jun 30, 2024	Fully EOL
Debian 11 (Bullseye)	Aug 14, 2024	Jun 30, 2026	LTS ending Jun 30
Debian 12 (Bookworm)	Jun 10, 2026	Jun 30, 2028	EOL
Debian 13 (Trixie)	Aug 2028	Jun 2030	Current stable

Who Is Most at Risk

• Internet-facing servers on Debian 12 Web servers, API endpoints, reverse proxies, load balancers. Every day without patches after EOL is an open window. Attackers actively track what CVEs land against EOL systems — you won't see them until after exploitation.
• Compliance-scoped systems Systems under PCI DSS, SOC 2, HIPAA, ISO 27001, or FedRAMP. "End of vendor security support" is an automatic finding in most audit frameworks. Verify with your compliance team whether Debian LTS satisfies your specific requirements before assuming it qualifies.
• CI/CD build runners on Debian 12 Often invisible in upgrade planning. A compromised build runner is a supply chain attack vector. Every artifact produced after June 10 on an unpatched Debian 12 runner carries that risk forward.
• Automated deployments pinned to Debian 12 Terraform, Packer, Ansible, Kubernetes node image templates that hard-code a Debian 12 AMI or image reference. These will continue provisioning EOL OS layers indefinitely unless the templates are updated.
• Database and middleware servers PostgreSQL, MySQL, Redis, and similar instances running on a Debian 12 OS layer. The application may be on a fully supported version while the OS beneath it is EOL — a hidden attack surface that vulnerability scanners routinely miss.

Docker and Container Images

debian:12 and debian:bookworm are among the most widely used Docker base images in production. If your Dockerfile contains either of these, every container you build after June 10 will have an EOL OS layer — one that will never receive another Debian Security Team patch, regardless of how current your application code is.

Also check images that derive from Debian 12 indirectly. Official application images for Python, Node.js, PHP, and Ruby use Debian as their default base. If you are using non-alpine tags (e.g. python:3.12 rather than python:3.12-alpine), confirm which Debian version that image currently builds on — and whether the maintainer has updated it to Debian 13.

Compliance Implications

If your systems operate under a compliance framework, the June 10 transition needs to be documented in your risk register before it happens — not discovered in an audit finding.

• PCI DSS Requires vendor-supported software. Debian LTS is a community volunteer effort, not a vendor-backed support contract. Clarify with your QSA whether it satisfies Requirement 6.3.3 in your specific audit scope before June 10.
• SOC 2 Type II The CC7.1 control requires patch management for vulnerabilities. CVEs disclosed against Debian 12 packages outside the LTS scope after June 10 remain permanently open. Document how you are managing that gap.
• ISO 27001 Annex A.12.6.1 requires management of technical vulnerabilities. EOL systems are a standard flag. LTS status must be documented as a managed compensating control to satisfy this requirement.
• FedRAMP EOL OS components in a FedRAMP boundary are a showstopper. Upgrade or obtain an approved third-party extended support contract before the assessment window if Debian 12 is in scope.

The Upgrade Path to Debian 13

Debian 13 "Trixie" became the current stable release in August 2025. Regular support runs through August 2028. If you can upgrade, this is your target.

• 01
  Bring Debian 12 fully current first Run apt update && apt upgrade && apt full-upgrade on your Debian 12 system. You must be on the latest point release before switching the release channel.
• 02
  Update sources.list Edit /etc/apt/sources.list and any files in /etc/apt/sources.list.d/. Replace every instance of bookworm with trixie. Update security.debian.org bookworm to trixie as well.
• 03
  Run apt full-upgrade Run apt update then apt full-upgrade. Use full-upgrade, not upgrade — this handles package removals and replacements that occur during a major version transition. Review configuration file prompts carefully.
• 04
  Reboot and verify Reboot. Run lsb_release -a to confirm Debian 13. Test your application. Review the Debian 13 release notes for dropped packages and changed defaults — especially if you use i386 packages, which are no longer supported in Debian 13.

If You Cannot Upgrade by June 10

Option 1 — Debian LTS (free, automatic)

Debian LTS activates automatically after June 10 with no configuration change required. Your existing security.debian.org repository continues serving LTS patches for ~230 covered packages. For standard server stacks — kernel, glibc, OpenSSL, Apache, nginx, PHP, Python — LTS coverage is typically adequate as a 3–6 month bridge while you plan the Debian 13 upgrade.

What you must do: verify your critical packages are in scope, document the transition in your risk register, and set a hard target date for the Debian 13 upgrade. Do not treat LTS as a permanent operating state.

Option 2 — Commercial extended lifecycle support

For organizations that cannot upgrade within a short window and need broader, guaranteed patch coverage with defined SLAs and compliance documentation, commercial extended lifecycle support is available. Providers offer extended security patching for Debian with wider package coverage than community LTS, CVE response SLAs, and the documentation that compliance auditors require.

Your Action Checklist Before June 10

• Inventory every Debian 12 systemServers, VMs, containers, CI runners, build images. You cannot plan a migration for systems you have not inventoried.
• Audit Docker base imagesSearch Dockerfiles and registries for debian:12, debian:bookworm, and application base images that derive from Debian 12. Update to debian:13.
• Update IaC templatesTerraform, Packer, Ansible, and Helm configurations hard-coding Debian 12 AMI IDs or image names must be updated before they next run.
• Triage: upgrade now vs. LTS bridge vs. extended supportClassify each Debian 12 system. This determines whether you are upgrading before June 10, relying on LTS, or need a commercial support contract.
• Verify LTS package coverage for systems staying on Debian 12Check the Debian LTS tracker for every critical package on systems you cannot upgrade immediately. Packages outside the LTS scope are unpatched after June 10.
• Document the transition in your risk registerList which systems are moving to LTS, which packages are and are not covered, and your Debian 13 migration target date. Documentation separates a managed risk from an audit finding.
• Brief compliance and security teamsThe June 10 date should be a calendar event for everyone who owns a compliance boundary. Late notification is avoidable.
• Test the Debian 13 upgrade in a non-production environmentProvision a clone and run the full upgrade. Validate your application stack against Debian 13 package versions. This is what removes the primary reason teams delay production upgrades.
• Set a post-June 10 review reminder30 days after the transition, review any new CVEs disclosed against Debian 12 packages outside LTS scope. If critical unpatched CVEs are accumulating, escalate the migration timeline.

Frequently Asked Questions

What happens to Debian 12 on June 10, 2026?

The Debian Security Team stops issuing security patches for Debian 12. Debian 12 transitions to LTS support, maintained by the Debian LTS team with coverage for approximately 230 packages until June 2028. The security.debian.org repository continues serving patches, but from the LTS team rather than the Debian Security Team.

Do I need to upgrade from Debian 12 before June 10?

If you can upgrade to Debian 13 before June 10, you should. If a full upgrade is not feasible in time, Debian 12 LTS is a viable short-term bridge — but verify your critical packages are covered and document the transition for compliance purposes. Do not treat LTS as a permanent solution.

Does Debian 12 get security updates after June 10?

Yes, for packages in the Debian LTS scope — approximately 230 packages — until June 2028. Packages outside that scope receive no further security updates after June 10.

What should I do with Docker images using debian:12?

Update your Dockerfile base image to FROM debian:13 or FROM debian:trixie. Rebuild and run your test suite. For most standard applications this is low-friction. Every container built on debian:12 after June 10 has an OS layer that will never receive another Debian Security Team patch.

Is Debian LTS acceptable for compliance frameworks?

It depends on the framework and your auditor. Debian LTS is a community effort, not a vendor-backed contract. Some auditors accept it as a documented compensating control; others require a vendor SLA. Clarify with your QSA or compliance lead before June 10, not after an audit finding.