Debian Release History: Every Version, Codename and Support Date

Debian has shipped 18 codenamed stable releases, from Debian 1.1 "Buzz" on 17 June 1996 to Debian 13 "Trixie" on 9 August 2025. Debian 14 "Forky" is the current testing release with no release date set, and Debian 15 has been named "Duke". Every release since Debian 6 gets about three years of support from the Security Team, then two years of community Long Term Support (LTS), for roughly five years in total. Freexian, a company outside the Debian project, sells Extended LTS (ELTS) that stretches selected packages to ten years.

As of this writing (23 October 2026), the state of play is simple. Debian 13 Trixie is stable and fully supported, at point release 13.7 (12 September 2026). Debian 12 Bookworm moved to LTS on 12 July 2026 and is covered until 30 June 2028. Debian 11 Bullseye left LTS on 31 August 2026 and now lives only in paid ELTS until 30 June 2031. Anything older than that is either in ELTS or gone.

Key takeaways

• Five years is the standard Debian lifetime. Debian's releases page describes the cycle as "three years of full support followed by two years of Long Term Support". The Security Team covers the first three years; the LTS team covers the last two.
• The three support tiers have three different owners. The Debian Security and Release Teams run regular support. The Debian LTS team, a group of volunteers and paid contributors funded largely through Freexian's sponsorship offer, runs LTS. Freexian alone runs ELTS, which is "not an official Debian project".
• Support narrows as a release ages. LTS supports fewer architectures than stable, and ELTS supports only the packages that paying customers use. Install debian-security-support and run check-support-status to see what is not covered on a given machine.
• Debian backports fixes, it does not chase upstream versions. A version string such as 1:9.2p1-2+deb12u3 can be fixed even though the upstream number looks old. Compare against the Debian Security Tracker, not against the upstream changelog.
• DSAs cover stable, DLAs cover LTS. Debian Security Advisories (DSA) come from the Security Team; Debian LTS Advisories (DLA) come from the LTS team. Low impact issues often skip an advisory and land in the next point release.
• Security defaults moved in specific releases. AppArmor and Secure Boot support arrived in Debian 10, yescrypt password hashing and the bullseye-security suite name in 11, the non-free-firmware component and mandatory merged /usr in 12, and arm64 PAC/BTI hardening, /tmp on tmpfs and the end of SSH DSA keys in 13.
• Upgrades go one release at a time. Debian supports upgrades only from the immediately previous release, so a Debian 11 machine goes to 12 and then to 13. There is no supported downgrade, which makes a snapshot or tested backup your only real rollback.

This post goes one level deeper than our earlier Debian posts. If you just need the Debian 11 dates, see is Debian 11 Bullseye end of life. For container base images, see moving a container from Debian 12 to 13 and base image support dates for Debian, Ubuntu and Alpine side by side. For the sibling family tree, see every Ubuntu release from 4.10 to 26.10.

Every Debian release from Buzz to Forky

The authority for dates is the Debian releases page, which lists release date, end of life (EOL), end of LTS and end of ELTS for every version. The project history chapter on releases adds what each release introduced, and the DebianReleases wiki page links each date to its announcement. Where the three disagree, the table uses the releases page and the notes below say what differs.

Timeline table

Sources: the Debian releases page for every date in the first five date columns, the ELTS wiki page and Freexian's ELTS page for ELTS, and the project history and per release notes for the last column. Debian 1.0 was never released: the project history explains that a CD vendor shipped a development snapshot labelled 1.0 in late 1995, so Debian renamed its next release 1.1 to avoid confusion.

Where Debian's own pages disagree

Dates for a project this old drift between pages. None of these change a planning decision, but they matter if you are reconciling an inventory report against a source:

• Bo (1.3). The releases page says 2 July 1997. The project history chapter says 5 June 1997.
• Jessie (8). The releases page says 25 April 2015. The LTS and ELTS wiki tables say 26 April 2015.
• Buster (10). The releases page and the release announcement say 6 July 2019. The LTS wiki table shows 2019-06-06, which looks like a typo.
• Bookworm (12) end of regular support. The releases page says 11 July 2026, the day the final regular point release (12.15) shipped. Debian's news item handing Bookworm to the LTS team is dated 12 July 2026. The LTS wiki table shows the LTS period starting 2026-06-11, which conflicts with both.
• Stretch (9) end of LTS. The releases page says 1 July 2022; the LTS wiki says 30 June 2022.
• Wheezy and Jessie LTS windows in the ELTS table. The ELTS wiki page lists the Wheezy LTS window as 2014 to 2016 and the Jessie LTS window as 2016 to 2018, which are the Squeeze and Wheezy windows shifted by one row. The main LTS wiki page has the correct values.
• Buster LTS architectures. The LTS wiki lists i386, amd64, armhf and arm64. The project history chapter says i386, amd64, armel and armhf. The LTS wiki is maintained by the LTS team and is the better source.

Where the codenames come from

Every codename is a character from the Toy Story films, a tradition that began when Bruce Perens, then project leader, was working at Pixar. The unstable distribution is always called sid. The Raspberry Pi announcement of its Trixie release puts it well: the well known characters have all been used, so the names are getting more obscure. Codenames matter in practice because APT sources refer to them, which is why Debian recommends using codenames rather than status names such as stable in your sources (more on that below).

How the version numbers changed

The numbering scheme changed twice, which explains why old documentation looks inconsistent. According to the point releases wiki page, Etch used an r suffix for point releases (4.0r1, 4.0r2). From Lenny's first point release the third digit counted point releases (5.0.1). From Wheezy's first point release the minor number does that job (7.1, 7.2), which is why the current release is 13.7 rather than 13.0.7.

How Debian's support lifecycle works

Debian runs three tiers of support. Each one is run by different people, covers a different set of packages and architectures, and uses different channels.

Regular support: the Security Team and the Release Team

The Debian security FAQ says the Security Team supports a stable distribution "for three years after its release", and adds that supporting three distributions at once is not possible. In practice that is "until about a year after the next stable release ships". The DebianReleases wiki states the rule of thumb directly: the EOL date for a stable release is roughly one year after the release of the following stable release.

During this period:

• The Security Team publishes DSAs to the debian-security-announce list and the archive at security.debian.org.
• The Stable Release Managers publish point releases roughly every couple of months, which fold in security fixes plus selected bug fixes from proposed-updates.
• All release architectures are covered. For Trixie that is amd64, arm64, armel, armhf, ppc64el, riscv64 and s390x, according to the Debian 13 release announcement.

Long Term Support (LTS): the LTS team

The Debian LTS wiki page describes LTS as a project "to extend the lifetime of all Debian stable releases to (at least) 5 years". It is explicit that LTS is not handled by the Security and Release Teams. When the Security Team stops, the LTS team takes over the same release.

Key facts from the LTS pages:

• Same mirrors, same suite. The LTS/Using page calls LTS "just a responsibility handover" that reuses the same mirror infrastructure. If your sources already include <codename>-security, you get LTS updates automatically.
• Separate advisories. LTS updates are announced as DLAs on the debian-lts-announce list and the LTS security information page.
• Fewer architectures. LTS supported architectures are listed per release. Bookworm LTS covers amd64, i386, arm64, armhf and, for the first time in any LTS, ppc64el, according to Debian's handover announcement. Bullseye LTS covered i386, amd64, armhf and arm64.
• Not every package. Some packages are not supported in LTS. The debian-security-support package flags them, and check-support-status lists them on demand.

Who funds it. The LTS funding page explains that several Debian developers set up a sponsorship offer under the Freexian umbrella. Freexian, founded by Debian developer Raphaël Hertzog, collects money from sponsors, assigns the paid hours to Debian contributors and pays them once they publish their work report. Volunteers also contribute directly. The LTS page notes that "the number of properly supported packages depends directly on the level of support that the LTS team receives".

Extended LTS (ELTS): Freexian's commercial service

The ELTS wiki page is direct about what ELTS is: a commercial offering to extend Debian releases to ten years, "not an official Debian project", with no involvement from Debian's package building infrastructure. Freexian's ELTS page lists three restrictions compared with LTS:

• Only packages used by Freexian's customers are supported.
• A limited set of architectures (at least amd64; others on request).
• The Linux kernel is supported only through a backport of a newer kernel version.

Subscribers get a private repository of updates, Freexian's own security tracker, technical support, and CSAF/VEX data feeds. The Debian wiki adds that Freexian aims to keep updates freely available to individual users and small non-profit organisations on request. Treat those two statements as describing access policy, and check with Freexian for your situation before you plan around it.

Current ELTS end dates, according to Freexian: Stretch until 30 June 2027, Buster until 30 June 2029, Bullseye until 30 June 2031, Bookworm until 30 June 2033 and Trixie until 30 June 2035.

Support window comparison table

The status names move, the codenames do not

At any time Debian has one stable, one oldstable, often one oldoldstable and a testing and unstable. On 23 October 2026, stable is Trixie, oldstable is Bookworm (in LTS), testing is Forky and unstable is always sid. When Forky releases, every status name shifts by one. If your sources say stable, the next apt update after a release will offer you a major upgrade. The Trixie upgrade chapter recommends codenames for exactly this reason: you "will never be surprised by a new release".

How the Debian Security Team publishes DSAs and DLAs

What a DSA is, and what it is not

A Debian Security Advisory is an announcement for a fixed source package in a supported release. The Debian security information page lists recent DSAs, each with a link to the tracker. On 23 October 2026 the newest entries were DSA-6581-1 (unbound), DSA-6580-1 (erlang) and DSA-6579-1 (roundcube). The -1 suffix is the revision: a regression fix later reuses the same number with -2 or -3, as with DSA-6534-3 for webkit2gtk on 22 October 2026.

The security FAQ answers several questions that trip up vulnerability scanners and auditors:

• Not every CVE gets a DSA. The team tracks every CVE, assesses its impact "in a Debian context", and issues a DSA only for serious issues. Low impact fixes can land in a point release or ride along with a later DSA.
• Debian does not use CVSS for triage. The FAQ states that Debian "does not provide CVSS scores and doesn't use CVSS scores from external sources when triaging security issues." If your scanner shows a high CVSS score on a Debian package that Debian marks as minor, that is expected.
• Gaps in DSA numbers are normal. Some advisories are prepared in advance for coordinated disclosure and parked, so a later number can publish first.
• Missing architecture builds can follow later. An advisory can publish before slower architectures finish building, but never without i386 and amd64 builds.
• contrib, non-free and non-free-firmware are not supported by the Security Team. Some of those packages cannot legally be modified at all.
• Debian is a CVE Numbering Authority and publishes a vulnerability disclosure policy.

Why the version number looks vulnerable when it is not

This is the most common Debian security misunderstanding. The FAQ explains that Debian backports security fixes to the version shipped in the stable release instead of moving to a new upstream version, so that "a release changes as little as possible". The Debian revision suffix tells you which stable update you have:

• +deb12u3 means the third stable update of this package for Debian 12.
• +deb13u4 means the fourth stable update for Debian 13.

For example, the tracker page for CVE-2024-6387 in OpenSSH lists the Bookworm fix as 1:9.2p1-2+deb12u3 via DSA-5724-1, while upstream fixed it in OpenSSH 9.8p1. A scanner that compares only 9.2p1 against 9.8p1 will report a false positive on a patched Bookworm machine. The same page marks Bullseye as "not affected" because the vulnerable code was introduced later. Reading the tracker, not the upstream number, is how you avoid both kinds of error.

Testing and unstable are a different security model

The security FAQ says security for unstable is "primarily handled by package maintainers", and security fixes for testing have "a minimum two-day migration delay" that can stretch when transitions hold packages back. In the months after a new stable release, fixes in testing can lag. That matters for derivatives that build on testing, as covered below.

How to read the Debian Security Tracker

The Debian Security Tracker is the source of truth. Its data comes from the Security Team's own Git repository and combines DSAs, the CVE list, the NVD and Debian bug reports. Each CVE page has three parts:

1. Vulnerable and fixed packages: one row per release and suite, with the version currently in that suite and a status of fixed or vulnerable.
2. Fixed version data: the version that first fixed it per release, with the DSA or DLA reference, an urgency and any Debian bug numbers.
3. Notes: free text such as <not-affected> (with a reason), <no-dsa> (will be fixed in a point release instead) or <ignored>.

The tracker also offers per-suite lists of vulnerable packages, a dsa-needed list of planned updates, and the entire dataset as JSON at /tracker/data/json. Debian also publishes OVAL definitions from the security pages for tools that consume them.

Subscribing

For a person, the mailing lists are the simplest feed: debian-security-announce for DSAs and debian-lts-announce for DLAs. Both pages also offer RSS. Our earlier post how to subscribe to Ubuntu and Debian security advisories covers the options in detail, including filtering by package.

Security defaults that changed release by release

Debian rarely announces "security features". It changes defaults, packaging rules and archive layout, and the security consequences follow. This table collects the changes with a clear security angle, each confirmed in that release's notes or Debian's history chapter.

AppArmor by default in Debian 10

The Buster release notes state that Buster "has AppArmor enabled per default". AppArmor confines programs with per-program profiles that restrict file access and capabilities such as mount, ptrace and signals. The detail that trips people up: AppArmor is pulled in by a Recommends from the Buster kernel package, so systems configured not to install recommended packages do not get it unless you install apparmor yourself. Check with aa-status (see the walkthrough).

Secure Boot through a signed shim

The Debian SecureBoot wiki explains that since Debian 10, Debian supports UEFI Secure Boot through shim, a small loader signed by Microsoft that embeds Debian's own signing keys. Debian then signs GRUB, the kernel and other UEFI programs itself. Kernel modules built locally with DKMS cannot carry Debian's signature, so DKMS signs them with a Machine Owner Key (MOK) at /var/lib/dkms/mok.key that you enroll with mokutil. The wiki also flags a current issue: some 2024 and newer machines ship only the "Windows UEFI CA 2023" certificate, and newer Debian releases include a shim signed with that certificate.

The non-free-firmware split in Debian 12

Following a 2022 General Resolution, Bookworm introduced the non-free-firmware archive area and moved most firmware there. The Bookworm release notes explain that this lets the official installer include firmware without pulling in the rest of non-free. The security angle is twofold. Machines get CPU microcode and device firmware at install time instead of running without them. And because non-free-firmware is not covered by the Security Team, firmware updates depend on what vendors release.

Merged /usr

In February 2021 the Technical Committee resolved that Bookworm would support only the merged /usr layout, where /bin, /sbin and /lib are symlinks into /usr. According to the UsrMerge wiki page, a system that still has a real /bin directory cannot install the current base-files package and must run the usrmerge package first. One layout means fewer path confusion bugs and simpler integrity checks.

Signed-by and the end of global trust

The UseThirdParty wiki page sets the rules for adding non-Debian repositories. Every source "SHOULD have the signed-by option set", it must point to a keyring file rather than a fingerprint, and the key "MUST NOT be placed in /etc/apt/trusted.gpg.d or loaded by apt-key add". The reason is the important part: a key in the global trust directory is trusted for every repository without signed-by, including Debian's own. A compromised third party key could then sign packages that replace Debian packages. Trixie goes further by making .pgp the canonical keyring extension and moving sources to the deb822 format.

Limits the release notes document

Every release's notes include a "Limitations in security support" section, and you should read it before choosing Debian for a workload. The Trixie notes say:

• Browsers and engines. Firefox, Chromium and Thunderbird are kept current by rebuilding upstream ESR or stable releases rather than backporting. Applications using webkit2gtk are covered, but those using qtwebengine are not. Chromium gets only 6 months of support in oldstable.
• Go and Rust. Because these ecosystems link statically, Debian's infrastructure struggles to rebuild every dependent package. Fixes for Go and Rust libraries usually arrive only in point releases.

Point releases versus security updates

These two channels overlap, which is why people mix them up.

The 13.7 announcement is a good example. It says the point release "mainly adds corrections for security issues" and lists two groups: miscellaneous bug fixes (some with CVE numbers, fixed without a DSA) and the security updates already published as DSAs. If you only follow -security, you miss the first group. If you only take point releases, you wait weeks for serious fixes. Configure both, which is what Debian's default sources do.

A third suite, <codename>-updates, appears in the default Trixie debian.sources file shown below. Keep it alongside the main and security suites unless you have a specific reason to drop it.

How derivatives inherit Debian's security work

Debian is the base for many distributions, but each one connects to Debian's security work differently. The key question is which Debian branch it builds from, because that decides whether DSAs mean anything for it.

Ubuntu

Ubuntu's own page on Debian calls Debian "the rock on which Ubuntu is built". Ubuntu builds on Debian's architecture and infrastructure and collaborates with Debian developers, but has a separate developer community and a different release process: interim releases every six months and LTS releases every two years. Ubuntu ships its own security updates and notices rather than Debian's advisories. The Ubuntu release history post maps each Ubuntu release to its support window.

Kali Linux

Kali's documentation on its relationship with Debian says Kali "is based on Debian Testing" and imports most packages as is, sometimes taking newer packages from unstable or experimental. The Kali branches page shows the flow: debian-testing and kali-debian-picks feed kali-dev, which feeds kali-rolling. Kali also warns that "a package bug may slip into here, due to bugs in debian-testing". Combine that with Debian's own statement that testing security fixes have a minimum two day migration delay and can lag, and the takeaway is clear: Kali's security posture follows Debian testing, not Debian stable, and Debian DSAs are not a Kali patch feed. Our Kali history posts cover how this evolved, from BackTrack to Kali 1.0, through Kali 2.0 and the move to rolling releases, to every quarterly release since 2020.

Raspberry Pi OS

Raspberry Pi OS follows Debian stable. The Raspberry Pi announcement of Raspberry Pi OS Trixie, dated 2 October 2025, notes that a new Debian major release "in turn means there is a new major release of Raspberry Pi OS". It also says Raspberry Pi does "not recommend or support" upgrading a running Bookworm image in place, and recommends flashing a clean Trixie image instead. That is a stricter position than Debian's own, which supports in-place upgrades from the previous release.

For a side by side of who should use which, see Ubuntu vs Kali vs Debian.

How reproducible builds and archive keys protect what you install

When apt installs a package, two separate mechanisms back up the claim that what you got is what Debian built: a chain of signatures from the archive key down to each file, and reproducible builds that let anyone check the binary against the source.

The signature chain

The Debian releases page describes the chain. A signed Release file holds the checksums of every Packages and Sources index. Those indexes hold checksums of every package. APT checks the Release signature against keys in /usr/share/keyrings/, then each checksum down the chain. The security FAQ makes the same point: checking package integrity means checking the Release file signature against the archive public key.

The ftp-master archive keys page explains which key signs what:

• Stable releases are signed by both the automatic ftp-master archive key in use at release time and a per-release stable key held offline by a Stable Release Team member.
• Other suites (testing, unstable, proposed-updates, experimental) are signed by the automatic key only.
• The security archive is signed by the ftp-master key only.
• The current procedure is one ftp-master key per release, instead of the older one key per year.

For Trixie, the page lists these fingerprints:

The page itself says these details are "for information only" and that you should verify through other means as well. The debian-archive-keyring package is the normal route.

Reproducible builds

Reproducible builds are, in the words of reproducible-builds.org, practices that "create an independently-verifiable path from source to binary code". If the same source, build environment and instructions always produce the same bytes, anyone can rebuild a package and confirm that the archive binary was not altered after the fact.

Debian's progress, according to its own sources:

• By Debian 9 Stretch, over 90% of source packages built bit for bit identically, according to the project history.
• Debian records the build environment in .buildinfo files, documented on the ReproducibleBuilds wiki.
• Trixie added the debian-repro-status package, which reports the reproducibility status of packages installed on your system, with overall statistics at reproduce.debian.net.
• The shim bootloader build has been fully reproducible since shim 15, according to the SecureBoot wiki.

The wiki is frank about the limit: "Reproducible builds of Debian as a whole is still not a reality". Individual packages are reproducible and checked; the full archive is not yet guaranteed.

Walkthrough: check a Debian machine's release and support status

These commands are read only. Run them on any Debian or Debian based host or container.

1. Identify the release

cat /etc/debian_version          # for example 13.7, or 12.15
. /etc/os-release && echo "$PRETTY_NAME ($VERSION_CODENAME)"
uname -r                         # running kernel, may lag the installed one until reboot

Inside a container there is no kernel of its own; uname -r shows the host's kernel, which your image does not control.

2. Check which suites APT pulls from

# Old one-line format (Debian 12 and earlier)
grep -hv '^#' /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/null

# deb822 format (Debian 13 default)
grep -hE '^(URIs|Suites|Components|Signed-By):' /etc/apt/sources.list.d/*.sources 2>/dev/null

You want to see the release codename, <codename>-updates and <codename>-security. If the security suite is missing, the machine is getting only point releases.

3. Find packages that have lost security support

sudo apt-get update
sudo apt-get install -y debian-security-support
check-support-status

check-support-status prints packages with limited or ended support for your release, such as browser engines in older releases or packages dropped from LTS. It runs automatically each time packages are installed once the package is present.

4. Check a specific package against the tracker

# Installed version and Debian revision
dpkg-query -W -f='${Package} ${Version}\n' openssh-server

# Which updates are pending
apt list --upgradable 2>/dev/null

# Read the Debian changelog for the fix entry
apt-get changelog openssh-server | head -40

Then open the CVE page on the tracker, for example https://security-tracker.debian.org/tracker/CVE-2024-6387, and compare your version to the "fixed" version for your release. To check many CVEs in a script, pull the tracker's JSON once:

curl -s https://security-tracker.debian.org/tracker/data/json -o debian-tracker.json
# Status of one CVE for one source package and release
jq '.["openssh"]["CVE-2024-6387"].releases.bookworm' debian-tracker.json

The JSON file is large, so download it once and cache it rather than fetching it per query.

5. Confirm AppArmor, Secure Boot and the arm64 hardening state

sudo aa-status | head -5                 # AppArmor loaded profiles and modes
mokutil --sb-state                       # SecureBoot enabled or disabled
grep -o -w -E 'paca|pacg|bti' /proc/cpuinfo | sort -u   # arm64 only: CPU support for PAC/BTI
findmnt /tmp                             # tmpfs on Debian 13 by default

6. Check that services picked up library fixes

sudo apt-get install -y needrestart
sudo needrestart -r l      # list services that still use old libraries, restart nothing

Walkthrough: upgrade from Debian 12 to Debian 13 with a rollback plan

The Trixie upgrade chapter is the authority and is worth reading in full. This is a condensed version for a server, with the rollback plan Debian leaves to you. Debian supports upgrades only from Debian 12, and the release notes state that skip upgrades are not supported, so a Debian 11 machine goes to 12 first.

Step 0: decide your rollback before you touch anything

Debian has no supported downgrade path. Your rollback is a restore from something taken before the upgrade:

Warning: snapshot and restore commands act on block devices. Before running an LVM command, confirm the exact volume names with lsblk -f and sudo lvs, and confirm the volume group has free space with sudo vgs. Merging a snapshot back (lvconvert --merge) overwrites the origin volume with the snapshot's contents. Never guess a device path.

# Check device paths first. Read the output before continuing.
lsblk -f
sudo vgs
sudo lvs

# Example only: replace vg0/root with YOUR volume group and root LV from the output above
sudo lvcreate --snapshot --size 10G --name root-pre-trixie /dev/vg0/root

Step 1: back up what the release notes ask for

sudo tar czf /root/pre-trixie-etc.tgz /etc
sudo tar czf /root/pre-trixie-dpkg.tgz /var/lib/dpkg /var/lib/apt/extended_states
dpkg --get-selections '*' > ~/pre-trixie-selections.txt   # the quotes are important

Step 2: get to a clean, current Bookworm

sudo apt update && sudo apt full-upgrade     # latest 12.x point release first
cat /etc/debian_version                      # expect 12.x
dpkg --audit                                 # half-installed or broken packages
apt-mark showhold                            # held packages block upgrades
apt list '?narrow(?installed, ?not(?origin(Debian)))'   # non-Debian packages

Remove or plan around third party repositories and held packages. The release notes describe the process as designed for "pure" Debian systems.

Step 3: switch sources to Trixie

The release notes recommend replacing old .list files with a single deb822 file at /etc/apt/sources.list.d/debian.sources:

Types: deb
URIs: https://deb.debian.org/debian
Suites: trixie trixie-updates
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: https://security.debian.org/debian-security
Suites: trixie-security
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Comment out or remove the Bookworm entries. Note that the suite names are codenames, not stable.

Step 4: run the upgrade inside tmux or screen, in two stages

tmux new -s upgrade
sudo apt update
sudo apt -o APT::Get::Trivial-Only=true full-upgrade   # dry run: shows download size and space needed
sudo apt upgrade --without-new-pkgs                    # minimal upgrade first
sudo apt full-upgrade                                  # then the full upgrade

Read every configuration file prompt. For remote upgrades, the release notes advise having console access ready, because a new kernel or network interface naming change can lock you out.

Step 5: Trixie specific checks before you reboot

Several Trixie changes break things silently. Check these before the first reboot:

# Users who still rely on DSA SSH keys will be locked out (OpenSSH 9.8+ dropped support)
sudo grep -l 'ssh-dss' /home/*/.ssh/authorized_keys /root/.ssh/authorized_keys 2>/dev/null

# Anything large in /tmp will be hidden once /tmp becomes tmpfs, which defaults to 50% of RAM
sudo du -sh /tmp

# Settings in /etc/sysctl.conf are no longer honored; move them to /etc/sysctl.d/
grep -v '^#' /etc/sysctl.conf | grep .

Step 6: reboot, then clean up

sudo reboot
cat /etc/debian_version          # expect 13.x
sudo apt modernize-sources       # converts any remaining old-style sources
sudo apt autoremove --dry-run    # review before removing anything

The release notes also advise switching Signed-By paths from .gpg to .pgp, since the .gpg names are now compatibility symlinks that will eventually go away.

Step 7: if it fails

If the machine boots but services misbehave, the release notes describe using systemd.unit=rescue.target or emergency.target on the kernel command line, or the Debian installer's rescue mode. If you need to go back, restore the snapshot from Step 0. For LVM, that means merging the snapshot back into the origin, which needs a reboot to complete. Warning: merging overwrites everything written to the root volume since the snapshot. Run sudo lvs again and confirm the snapshot name and origin before you merge:

sudo lvs                                         # confirm names first
sudo lvconvert --merge /dev/vg0/root-pre-trixie  # example only: use YOUR snapshot path
sudo reboot

Common mistakes

• Using stable instead of a codename in sources. The next Debian release will turn a routine apt update into a major version upgrade. Pin to trixie, not stable.
• Treating upstream version numbers as truth. A Debian package can be fixed at an old upstream version because the fix was backported. Check the +debNNuN revision against the tracker.
• Expecting a DSA for every CVE. Many minor fixes arrive only in point releases. If you subscribe only to DSAs, also take point releases.
• Leaving out the security suite. Without <codename>-security, a machine waits for the next point release for every fix.
• Assuming LTS covers everything. LTS supports fewer architectures and drops some packages. Run check-support-status.
• Assuming ELTS is part of Debian. It is a Freexian service with its own repository, package scope and terms.
• Skipping a release on upgrade. Debian 11 to 13 directly is unsupported. Go through 12.
• Adding third party keys with apt-key or into trusted.gpg.d. That trusts the key for every repository. Use signed-by with a dedicated keyring file.
• Upgrading without a rollback. Debian has no downgrade path. Take a snapshot first.
• Not restarting services after library updates. A patched OpenSSL on disk does nothing for a daemon still running the old copy. Use needrestart or reboot.
• Treating Kali as Debian stable. Kali tracks Debian testing, which has a different and slower security model than stable.
• Forgetting containers. A host on Trixie can still run Bookworm or Bullseye based images that are out of regular support. Inventory the base images as well as the hosts.

FAQ

What is the latest version of Debian?

Debian 13 "Trixie" is the current stable release, first released on 9 August 2025. Its latest point release, 13.7, came out on 12 September 2026. Debian 14 "Forky" is in testing with no release date set.

How long is a Debian release supported?

About five years in total: roughly three years of regular support from the Security and Release Teams, then two years of LTS from the Debian LTS team. Freexian's paid ELTS can extend selected packages to about ten years.

Is Debian 12 Bookworm still supported?

Yes, through LTS. Regular support ended in July 2026 and the LTS team took over on 12 July 2026. Bookworm LTS runs until 30 June 2028 on amd64, i386, arm64, armhf and ppc64el. Freexian lists ELTS for Bookworm until 30 June 2033.

Is Debian 11 Bullseye end of life?

For Debian itself, yes. Bullseye LTS ended on 31 August 2026, and Debian no longer publishes security updates for it. A subset of packages is supported through Freexian's ELTS until 30 June 2031.

What is the difference between a DSA and a DLA?

A DSA (Debian Security Advisory) is published by the Debian Security Team for releases in regular support. A DLA (Debian LTS Advisory) is published by the LTS team for releases in LTS. Both use the same <codename>-security suite, so a correctly configured machine gets both without changes.

Why does my scanner say a Debian package is vulnerable after I patched it?

Usually because the scanner compares the upstream version number and ignores the Debian revision. Debian backports fixes into the version it shipped. Look up the CVE on the Debian Security Tracker and compare your full package version, including the +debNNuN suffix, with the fixed version listed for your release.

What are the Debian codenames in order?

Buzz (1.1), Rex (1.2), Bo (1.3), Hamm (2.0), Slink (2.1), Potato (2.2), Woody (3.0), Sarge (3.1), Etch (4.0), Lenny (5.0), Squeeze (6), Wheezy (7), Jessie (8), Stretch (9), Buster (10), Bullseye (11), Bookworm (12), Trixie (13), Forky (14) and Duke (15). Unstable is always sid.

Can I upgrade from Debian 11 directly to Debian 13?

No. Debian supports upgrades only from the immediately previous release, and the Trixie release notes say skip upgrades are not supported. Upgrade 11 to 12, check the system, then 12 to 13.

Is Kali Linux the same as Debian?

No. Kali is based on Debian testing, not stable, and adds its own packages and forks. Debian's stable security advisories do not apply to Kali directly, and Debian notes that security fixes in testing can lag behind.

What changed in Debian 13 for security?

The headline changes are PAC and BTI hardening on arm64 where the CPU supports them, a 64-bit time_t on all architectures except i386, /tmp on tmpfs by default, removal of SSH DSA key support, ping without the CAP_NET_RAW capability, sshd no longer reading ~/.pam_environment, and a move to deb822 sources files with .pgp keyring paths.

Debian packages get their fixes from Debian, its LTS team or Freexian, and nothing below changes that. But every Debian host and base image also builds and runs npm, PyPI, Maven or Go dependencies that are pulled again on each rebuild and outlive the release they started on, and those need their own inventory and fix path.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. On a Debian workstation or build host, that is the route for scanning the repositories and container images you build there, for example to see what a Bookworm based image contains before you rebase it on Trixie.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session: asked to fix a lodash CVE, the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies to an application dependency inside a Debian based service, where a fixed version exists upstream and the change belongs in your repository rather than in a Debian package.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Once your projects are in Safeguard, that connection lets you ask which of them contain a given component and version, a useful question when a Debian LTS window closes and you need to find every image still built on that release's libraries.

Click through it at your own pace, or open it full screen.

To try the CLI, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Debian: Debian Releases (index of releases, EOL, LTS and ELTS dates)
• Debian project history, chapter 3: Debian Releases
• Debian Wiki: DebianReleases
• Debian Wiki: Point Releases
• Debian Security FAQ
• Debian Security Information and recent DSAs
• Debian LTS Security Information and recent DLAs
• Debian Security Tracker
• Debian Security Tracker: CVE-2024-6387
• Debian Wiki: LTS
• Debian Wiki: LTS/Using
• Debian Wiki: LTS/Funding
• Debian Wiki: LTS/Extended
• Freexian: Debian Extended LTS
• Debian News: Debian 13 trixie released (9 August 2025)
• Debian News: Security support for Bookworm handed over to the LTS team (12 July 2026)
• Debian News: Debian 11 Long Term Support reaches end-of-life (31 August 2026)
• Debian News: Updated Debian 13: 13.7 released (12 September 2026)
• Debian News from 2026
• Debian 13 release notes: What's new
• Debian 13 release notes: Issues to be aware of for trixie
• Debian 13 release notes: Upgrades from Debian 12
• Debian 12 release notes: What's new
• Debian 11 release notes (text)
• Debian 10 release notes (text)
• Debian Wiki: SecureBoot
• Debian Wiki: AppArmor
• Debian Wiki: UsrMerge
• Debian Wiki: DebianRepository/UseThirdParty
• ftp-master.debian.org: Archive signing keys
• Debian Wiki: ReproducibleBuilds
• Reproducible Builds project
• Ubuntu: Debian
• Kali Linux docs: Kali's relationship with Debian
• Kali Linux docs: Kali branches
• Raspberry Pi: Trixie, the new version of Raspberry Pi OS (2 October 2025)

Last reviewed: 23 October 2026. Debian support dates and point release numbers change during each release's life; check the Debian releases page and the LTS wiki before planning an upgrade.