Every Ubuntu Release 4.10 to 26.10: Codenames, Kernels, Support

Ubuntu has shipped 45 releases, from 4.10 "Warty Warthog" in October 2004 to 26.10 "Stonking Stingray" on 15 October 2026, with 27.04 "Tenacious T-Rex" in development. Four are still in standard support today: 22.04 LTS, 24.04 LTS, 26.04 LTS and 26.10. Two more, 18.04 and 20.04, get security fixes only through Ubuntu Pro, and 14.04 and 16.04 only through the paid Legacy add-on.

This page is the hub for our Ubuntu release history series. It gives one master table built only from Canonical's own pages, fetched on 23 October 2026: the release notes on documentation.ubuntu.com, the release cycle and kernel lifecycle pages on ubuntu.com, the release schedules and the old-releases archive. Where an official page does not state a fact, the table says so instead of filling the gap from memory. After the table come the version scheme, the support model and how it changed, the security defaults by era, and the commands to check what a machine or container is actually running.

Key takeaways

• 45 releases so far. Thirteen interim releases with 18 months of support (4.10 to 12.10), nine month interims from 13.04 onward, and an LTS every two years since 6.06.
• Supported today (23 October 2026): 26.10 until July 2027; 26.04 LTS until May 2031; 24.04 LTS until May 2029; 22.04 LTS until May 2027. Dates are from Canonical's release cycle page.
• Security fixes with Ubuntu Pro only: 20.04 LTS (ESM until May 2030) and 18.04 LTS (ESM until May 2028).
• Legacy add-on only: 16.04 LTS (ESM ended May 2026, Legacy until May 2031) and 14.04 LTS (Legacy until May 2029).
• Everything else is fully end of life, including every interim release before 26.10 and the LTS releases 6.06, 8.04, 10.04 and 12.04.
• Default kernels run from Linux 2.6.15.6 in 6.06 to 7.0 in 26.04 LTS and 7.3 in 26.10. For about a dozen early releases the official notes do not state a kernel, and the table marks them.
• The LTS window grew from three years on desktop and five on server (6.06), to five years for all main editions, to ten years with ESM and fifteen with the Legacy add-on.
• Check any machine with lsb_release -a, cat /etc/os-release, uname -r, hwe-support-status and pro status.

What is every Ubuntu release? The master table

Read the columns this way. Released gives the exact day only where an official page states it (a release schedule, a release note or the release announcement); otherwise it gives the month that the version number encodes and says the day is not stated. Default kernel is the kernel the release notes say the release shipped, or, for LTS releases from 14.04 onward, the GA kernel listed on Canonical's kernel lifecycle page. Support end uses the release cycle page for 14.04 onward and each release's own notes before that.

A few notes on how to read the gaps.

• No official notes for five early releases. The release notes index on documentation.ubuntu.com starts at 6.06 and then jumps to 7.10. Pages for 4.10, 5.04, 5.10, 6.10 and 7.04 return 404, and the old wiki pages they used to live on also return 404 since the wiki migration. The releases are real and still downloadable from old-releases.ubuntu.com, which lists all of them by version and codename, but their kernels are not stated on any official page we could fetch.
• The 7.10 page is a stub. The archived 7.10 notes contain only a redirect line to a wiki page that no longer resolves.
• 12.04 and 12.10 split their notes. The archived pages for both are short overviews that link to per edition wiki pages (desktop, server, flavours). Those sub-pages return 404 today, so the kernel is not stated on any page we could reach.
• Kernel versions for 8.10 and 9.10 are indirect. The 8.10 notes describe a driver issue "included in Linux kernel version 2.6.27" and name the linux-restricted-modules-2.6.27-7-generic package. The 9.10 notes show vmlinuz-2.6.31-14-generic only inside a GRUB upgrade example, so we do not treat it as a stated default.
• Release days. Release notes rarely carry a date. We used the published release schedules for 22.04 and 24.04 to 26.10 (the "Final Release" row), the 26.04 and 26.10 release notes, and the release team's 23.04 announcement on Ubuntu Discourse. Every other row gives only the month that the version number encodes.

The release notes index also lists two future placeholders: 27.10 and 28.04, both still shown with placeholder codenames ("U U" and "V V") on 23 October 2026.

How does the Ubuntu version number work?

The number is the year and month of delivery. Canonical's release notes index puts it plainly: releases "are versioned by the year and month of delivery", with the example that Ubuntu 26.04 was released in April 2026. So 24.04 is April 2024 and 26.10 is October 2026. The first part is not a major version in the semantic versioning sense; 25.10 is not a bigger change than 25.04 just because the second number is higher.

Each release also gets a development codename: an adjective and an animal with the same first letter. From 6.06 Dapper Drake the letters ran in alphabetical order (Edgy, Feisty, Gutsy and so on) to 17.04 Zesty Zapus, then wrapped round to A with 17.10 Artful Aardvark. The second lap has now reached T: 26.04 is Resolute Raccoon, 26.10 Stonking Stingray and 27.04 Tenacious T-Rex. The very first three releases (Warty, Hoary, Breezy) came before the alphabetical run began. Internally, the archive uses the lower case adjective as the series name, which is why you see noble, jammy and resolute in /etc/apt/sources.list.d/ files and in VERSION_CODENAME in /etc/os-release.

Point releases add a third number. 24.04.1 to 24.04.5 are refreshed install images of the same 24.04 release with accumulated updates and, from the second point release on, newer hardware enablement kernels. They are not separate releases and do not change the support dates. The old-releases archive lists the superseded point releases for each LTS: 14.04.5, 16.04.6, 18.04.5, 20.04.4, 22.04.4 and 24.04.1 at the time of writing.

Why is 6.06 not 6.04?

Because it shipped in June 2006, and the number encodes the delivery month. Every other release of that era landed in April or October, so 6.06 stands out as two months later than the usual April slot. The official 6.06 release notes on documentation.ubuntu.com describe what shipped (GNOME 2.14.1, X.org 7.0, Linux 2.6.15.6, a new live CD installer, separate server kernels) but do not explain the schedule. We could not find an official Canonical page that states the reason, so we leave it at that rather than repeat second hand accounts. What the notes do record is why 6.06 mattered: it was the first release with long term support, "supported with security updates for 5 years on the server and 3 years" on the desktop.

Which Ubuntu releases are still supported today?

As of 23 October 2026, per the release cycle page and the kernel lifecycle page:

A machine on 25.10 Questing Quokka lost security updates in July 2026. 25.10 users should already be on 26.04 LTS or 26.10. If you run 22.04, you have about seven months of standard support left; our post on whether Ubuntu 22.04 is end of life covers the May 2027 date and the ESM options, and Ubuntu 22.04 container base images covers what that means for images. If you still run 20.04, its standard support ended in May 2025; is Ubuntu 20.04 end of life walks through ESM and the upgrade options.

Two things are easy to miss. First, the interim rows have no ESM at all: the release cycle page shows "Not applicable" for 26.10's expanded maintenance, break and bug support and Legacy add-on. Second, the HWE kernels on an LTS carry their own dates. The kernel lifecycle page shows the 6.17 kernel on 24.04.4 (HWE) reaching end of standard support in July 2026, the same month as 25.10 which it was taken from, while the 7.0 kernel on 24.04.5 (HWE) runs to May 2029 with the rest of 24.04. An LTS machine that tracks HWE and is not up to date can be on an unsupported kernel inside a supported release.

How did the release cadence and LTS support length change?

The six month cadence has held since the start. What changed is how long each release is supported, and what "supported" covers.

The release cycle page now describes the model in three layers. Standard security maintenance covers packages in Main for five years. Expanded Security Maintenance, available through Ubuntu Pro, gives "10 years of security updates for the 'Main' repository" and also adds ten years of coverage for Universe. The Legacy add-on "can be purchased to cover additional 5 years", for a total of fifteen. The ESM page names the two package streams: esm-infra covers Main after its standard five years end, and esm-apps "covers all 'Universe' packages for ten years from the release of the LTS." Our explainer on whether Ubuntu patches Universe packages goes deeper on that split.

Ubuntu Pro is "free for personal use on up to five machines", per the release cycle page, and the Ubuntu Pro page says "Always free for personal use." Flavours follow their own rules; the release cycle page notes that "The release cycle for flavours may differ" and points to each flavour's own site. Our two flavour posts cover them: Kubuntu, Xubuntu, Lubuntu, Edubuntu and Ubuntu Studio and MATE, Budgie, Unity, Kylin and Cinnamon. The full lifecycle model, including HWE and point releases, is in the Ubuntu release support lifecycle explained.

Where the official pages disagree on dates

Canonical's own pages do not always agree on the month an LTS ends. The release notes for 20.04 and 22.04 say maintenance runs "until April 2025" and "until April 2027", and the 26.04 notes say "supported until April 2031". The release cycle page says May 2025, May 2027 and May 2031. The 24.04 notes say "until 31 May 2029" and that Pro extends this to ten years or "12 years with the Legacy add-on", while the release cycle page gives a Legacy end of May 2039, which is fifteen years. The 26.04 notes also mention ESM "for ten years" without the Legacy add-on. In every table on this page we used the release cycle page, because it is the page Canonical maintains for lifecycle dates and it is the newest. If a contract or audit depends on the exact day, ask Canonical.

How the kernel story changed: GA, HWE and the rolling model

Before 14.04, an LTS kept its launch kernel for life. From 14.04, the kernel lifecycle page describes a Hardware Enablement (HWE) stack that brings a newer kernel from a later release back to the LTS. On 14.04, the 14.04.2 and later point releases shipped with an updated kernel and X stack by default. For 16.04 and 18.04, the .2 and later point releases ship HWE by default on desktop, while "Server installations default to the GA kernel and provide the enablement kernel as optional." From 20.04, "Desktop installations ... default to tracking the HWE stack" and servers still default to GA. The 16.04 to 24.04 HWE stacks follow a rolling update model, so an HWE machine moves kernel versions over the life of the LTS until it settles on the next LTS's kernel in the .5 point release (for example 7.0 on 24.04.5).

Some desktop machines are on a separate OEM kernel track. The same page says to run ubuntu-drivers list-oem; if it prints anything, the machine follows the OEM cadence instead of HWE.

What were the biggest security default changes by era?

This is a summary across the series. Each per release post goes into detail; the links are at the end of each era.

2004 to 2008: the first LTS and the long tail

The 6.06 notes list GNOME 2.14.1, X.org 7.0, GCC 4.0.3, glibc 2.3.6 and Linux 2.6.15.6, plus "New kernels targeted at server platforms." The headline security fact is the support promise itself: five years on the server and three on the desktop. The 8.04 notes say users of 7.10 or 6.06 LTS "can upgrade to Ubuntu 8.04", the first LTS to LTS path. See Ubuntu 6.06 LTS Dapper Drake, 8.04 LTS Hardy Heron and the interim releases from 4.10 to 9.10.

2009 to 2013: AppArmor profiles for risky desktop apps, encrypted home, shorter interims

The 9.10 notes record that Evince, the GNOME document viewer, "now ships with an enforcing AppArmor profile", to protect users against flaws in PDF and image libraries. The 9.04 notes carry a warning about eCryptfs encrypted home directories (users of the alpha builds were told to re-encrypt after an upstream 2.6.28 kernel bug). The 11.04 notes record "upstream acceptance of AppArmor" into the mainline kernel. In 2013, 13.04 cut interim support from 18 months to 9, which is the single biggest change to the interim model. Read more in 10.04 LTS Lucid Lynx, 12.04 LTS Precise Pangolin and the Unity years, 10.10 to 17.10.

2013 to 2016: AppArmor mediation grows, Secure Boot shim, snaps arrive

13.10 added AppArmor mediation for DBus, 14.04 LTS added fine grained mediation of signals and ptrace, and 14.10 added mediation of abstract and anonymous Unix sockets. The 14.10 notes also document a shim update that showed a "Booting in insecure mode" message and a two second delay on UEFI systems with Secure Boot disabled, so the shim was by then part of the normal UEFI boot path. 16.04 LTS introduced the snap package format alongside debs, and 16.10 added AppArmor profile stacking for LXD containers. See 14.04 LTS Trusty Tahr and 16.04 LTS Xenial Xerus.

2017 to 2020: GNOME returns, PIE by default, full disk encryption over encrypted home

17.10 replaced Unity with GNOME and made Wayland the default display server "On supported systems"; 18.04 LTS went back to X by default with Wayland as a technical preview. The 18.04 notes record two lasting security defaults: gcc now compiles applications as position independent executables "as well as with immediate binding, to make more effective use of Address Space Layout Randomization", and the installer "no longer offers the encrypted home option using ecryptfs-utils", recommending full disk encryption instead. 18.04 also improved UEFI Secure Boot handling for third party kernel modules by letting you generate a signing key during installation. 20.04 LTS shipped kernel 5.4 with built in WireGuard and "lockdown in integrity mode". Details in 18.04 LTS Bionic Beaver and what shipped in 20.04 LTS.

2021 to 2024: Wayland default, OpenSSL 3, user namespace restrictions, TPM-backed FDE

21.04 made Wayland the default "on most configurations, which features better security and performance". 22.04 LTS moved to OpenSSL 3.0 and enabled systemd-oomd on the desktop. 22.10 notes that "AppArmor gained support for restricting access to unprivileged user namespaces"; 23.10 added a kernel ability to require an AppArmor profile before a program can use them (off by default) and introduced TPM-backed full disk encryption "as an experimental feature". 24.04 LTS switched the user namespace restriction on: per its notes, the kernel "now restricts the use of unprivileged user namespaces" for unprivileged, unconfined programs, with a default profile that allows the namespace but denies capabilities inside it. 24.04 also moved the compiler default to -D_FORTIFY_SOURCE=3 and changed needrestart so services restart after a library upgrade, including under unattended upgrades. See what shipped in 22.04 LTS, 24.04 LTS Noble Numbat and the interim releases from 18.10 to 23.10.

2025 to 2026: sudo-rs, Wayland only, TPM FDE without a hardware root of trust

25.04 started an AppArmor profile writing effort for unconfined programs that use user namespaces. In 25.10, per its notes, "sudo-rs is the default sudo provider", the Ubuntu on X.org session was dropped in favour of Wayland only, and the installer's TPM-backed encryption gained passphrase support and recovery key regeneration. The 26.04 LTS summary for LTS users lists TPM-backed full disk encryption in the desktop installer, an update from kernel 6.8 to 7.0, and Livepatch support on ARM64. In 26.10, computers "without a hardware root of trust can now be installed with TPM-backed full disk encryption", as long as a PIN or passphrase is set, and the notes say this was already backported to 26.04.1. The same notes warn that systems running TPM-backed FDE cannot upgrade from 26.04 to 26.10 at release. See 26.04 LTS Resolute Raccoon and the interim releases from 24.10 to 26.10.

What changed from one LTS to the next?

This table compares each LTS with the one before it. Every row is taken from the newer release's notes or the lifecycle pages.

How do you check which Ubuntu release a machine or container is running?

These steps use only commands documented on Canonical's pages. Run them on any Ubuntu host, VM or container shell.

Step 1: Read the release and codename

The lsb_release manual page says the -a option shows "all of the above information", meaning distributor ID, description, release number and codename. On current releases it reads its data from /etc/os-release.

lsb_release -a

Minimal container images often do not include lsb_release. Read the file it uses instead. The os-release manual page documents /etc/os-release and fields such as VERSION_ID and VERSION_CODENAME:

cat /etc/os-release

The codename here (noble, jammy, resolute) is the one that appears in your APT sources, so it is also what to search for when you check whether a package fix exists for your release. Note that the 26.04.1 point release notes include a base-files fix for a missing "LTS" in the VERSION field, so do not parse that field for the word LTS; use VERSION_ID.

Step 2: Check the running kernel

The 18.04 release notes use uname -r to verify the running kernel version:

uname -r

Compare the major and minor numbers with the table above. If the host is an LTS on the HWE stack, the version will be newer than the GA kernel. In a container, uname -r reports the host's kernel, not anything in the image, which is a common source of confusion.

Step 3: Check HWE support status

The kernel lifecycle page gives this command to check whether your kernel and enablement stack are still supported:

hwe-support-status --verbose

On desktop LTS machines, also check whether you are on an OEM kernel track:

ubuntu-drivers list-oem

Step 4: Check Ubuntu Pro and ESM status

The Ubuntu Pro client basic commands tutorial uses pro status to show which services are available and whether the machine is attached:

pro status

If the release is past standard support and the machine is not attached, it is not getting security updates. The attach how to gives the command, which prints a link and a code to confirm in your Ubuntu Pro account:

sudo pro attach

Step 5: Upgrade to the next supported release

Canonical's server guide, How to upgrade your Ubuntu release, sets the rules: you "can only upgrade from one LTS release directly to the next sequential LTS release", you cannot skip (16.04 to 20.04 means going through 18.04 first), and LTS to LTS upgrades "are only available after the first point release". First bring the system fully up to date, including phased updates:

sudo apt update
sudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true

If the file /run/reboot-required exists, reboot. Then back up your data and start the upgrade:

sudo do-release-upgrade

The guide warns that third party repositories and PPAs are disabled during the upgrade and are "the most common cause of upgrade issues". On a desktop with TPM-backed FDE on 26.04, note the 26.10 release notes: upgrades from 26.04 to 26.10 were not available at release for those systems. For background on why updates may arrive in stages, see what Ubuntu phased updates are, and for the decision itself, should you adopt a new LTS release right away.

Checking a container base image

For a base image, the same check applies: run cat /etc/os-release inside the container. Our guide on how to check if your base image operating system is end of life covers doing this at scale across a registry, and base image support dates for Debian, Ubuntu and Alpine puts the Ubuntu dates next to the alternatives.

Where do you get ISOs for old Ubuntu releases?

Canonical keeps them. The old-releases.ubuntu.com index lists every end of life release from 4.10 Warty Warthog to 25.10 Questing Quokka, with the final point release for each old LTS (6.06.2, 8.04.4, 10.04.4, 12.04.5), plus superseded point releases of supported LTS releases. Current images are on releases.ubuntu.com. Do not download old Ubuntu images from anywhere else.

Why you should not put an old release on a network

An end of life release does not get security updates. The archived release notes for 12.04, 18.10 and 19.04 open with the same banner: "WARNING: Release reached End of Life". Every vulnerability published since that date in the kernel, OpenSSL, OpenSSH, glibc, sudo and the rest of the base system is unpatched on that machine, and many of those have public advisories. There is no fix coming from the distribution for 4.10 to 12.10 or for any interim before 26.10.

If you need an old release for research, reproducing a bug or reading old data, run it in a virtual machine with no network interface, or on an isolated network segment with no route to the internet or to production. Take a snapshot before you start. Do not expose services from it, and do not reuse credentials from your normal environment inside it. Our post on whether to upgrade, extend, isolate or retire end of life software lays out the options for systems you cannot simply replace.

What about Ubuntu Server, Ubuntu Core, Ubuntu Pro and Kali?

This hub covers the main Ubuntu releases. Separate posts in the series cover Ubuntu Server's installer, cloud images and security defaults, Ubuntu Core 16 to 24, and Ubuntu Pro and ESM release by release.

Kali Linux is not an Ubuntu release. It is a Debian based distribution from OffSec for authorised security testing, forensics and research, and it should be used only on systems you own or have written permission to test; our guide on how to scope a penetration test and define rules of engagement covers that permission. Its history is in BackTrack to Kali 1.0, Kali 2.0 and the move to rolling releases and Kali quarterly releases from 2020 to 2026, and Ubuntu vs Kali vs Debian explains who should use which.

Common mistakes

• Reading the version as a feature level. 26.10 is newer than 26.04 but has far less support: nine months against five years standard. For servers, the LTS is almost always the right choice.
• Assuming an LTS is supported because the release is. A 24.04 machine stuck on the 6.17 HWE kernel lost kernel support in July 2026. Run hwe-support-status in verbose mode, as shown in step 3 below, and keep HWE machines updated through to the .5 point release.
• Trusting uname -r inside a container. It reports the host kernel. Use /etc/os-release for the image's release and scan the image for package versions.
• Treating ESM as automatic. On 18.04 and 20.04, security updates arrive only if the machine is attached to Ubuntu Pro. pro status tells you.
• Forgetting Universe. Standard support covers Main. Universe packages get security coverage through esm-apps with Pro, so a supported release can still carry unpatched Universe packages if Pro is not attached.
• Skipping LTS releases in an upgrade. do-release-upgrade goes one LTS at a time. Moving from 18.04 to 24.04 means two upgrades through 20.04 and 22.04, or a rebuild.
• Leaving PPAs enabled and expecting them to follow. They are disabled during the release upgrade and are the most common cause of failed upgrades.
• Quoting support end dates from memory. Canonical's own pages differ by a month for several LTS releases. Quote the release cycle page and say which page you used.

FAQ

What is the latest version of Ubuntu?

As of 23 October 2026 the newest release is Ubuntu 26.10 "Stonking Stingray", released on 15 October 2026 with Linux 7.3 and GNOME 51, supported until July 2027. The newest LTS is Ubuntu 26.04 LTS "Resolute Raccoon", released on 23 April 2026 with Linux 7.0, with standard support to May 2031 on the release cycle page.

Is Ubuntu 18.04 still supported?

Only through Ubuntu Pro. Standard security maintenance ended in May 2023. Expanded Security Maintenance runs until May 2028 and the Legacy add-on until May 2033, both per the release cycle page. Without an attached Pro subscription an 18.04 machine gets no security updates.

Is Ubuntu 20.04 still supported?

Standard support ended in May 2025 per the release cycle page (the 20.04 release notes say April 2025). ESM through Ubuntu Pro continues until May 2030, and the Legacy add-on until May 2035. Our post on Ubuntu 20.04 end of life covers the options.

When does Ubuntu 22.04 reach end of life?

Standard security maintenance ends in May 2027 on the release cycle page (April 2027 in the release notes). ESM continues to May 2032 and the Legacy add-on to May 2037. See is Ubuntu 22.04 end of life.

What kernel does Ubuntu 24.04 use?

Ubuntu 24.04 LTS shipped with Linux 6.8, per its release notes, and 26.04 LTS moved the GA kernel to 7.0. Desktop installs track the HWE stack, which moved to 6.17 with 24.04.4 and to 7.0 with 24.04.5 in July 2026, per the kernel lifecycle page. Servers default to the 6.8 GA kernel with HWE optional.

What does LTS mean in Ubuntu?

Long term support. The release notes index says LTS releases come every two years and "receive 5 years of standard security maintenance" for packages in Main. With Ubuntu Pro, ESM extends that to ten years and the Legacy add-on to fifteen.

How long are Ubuntu interim releases supported?

Nine months since 13.04. Before that, interim releases were supported for 18 months, as the 13.04 and 13.10 notes record.

How do I check my Ubuntu version from the terminal?

Run lsb_release -a or cat /etc/os-release. For the kernel, run uname -r. For Ubuntu Pro and ESM status, run pro status.

Is Kali Linux based on Ubuntu?

No. Kali's own history page says Kali started on Debian stable and moved to Debian testing when it became a rolling distribution. Its predecessor BackTrack switched from Slackware to Ubuntu for versions 4 and 5, which were based on Ubuntu 8.10 and 10.04. See Ubuntu vs Kali vs Debian.

Fix it without waiting for upstream

A release table tells you which operating system packages Canonical still patches. It says nothing about the application dependencies you install on top, and on an end of life release even the operating system packages stop getting USNs. The steps below cover the part you build and ship yourself.

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

None of these demos changes which Ubuntu release you run or replaces Canonical's updates. They show how to see what is inside the images and repositories built on a given release, and how to move the dependencies you control to fixed versions, with a person approving each step.

In this session you install the Safeguard CLI, run safeguard to open the interactive terminal and ask it to fix the lodash CVE in a repository. It 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 running on 22.04 or 24.04: the OS packages come from Canonical, but the application's own dependencies are yours to update.

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

This demo sets up the Safeguard runner on your own machine, approves it with its device code, then scans from the terminal. Scanning a container image built on an Ubuntu base produces an SBOM that lists the operating system packages and versions alongside the application components, which is how you find every image still built on 20.04 or 22.04 before their dates arrive.

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

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask in plain language which of your projects contain a given component and version, the same question our post on using SBOMs to find affected products fast works through.

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

You can download Safeguard at safeguard.sh/download and read the CLI documentation at docs.safeguard.sh/docs/cli.

Quick check

Sources

• Ubuntu release notes: index and release policy
• Ubuntu release notes: archive of older releases
• Ubuntu release notes: 6.06 LTS
• Ubuntu release notes: 7.10 (redirect stub)
• Ubuntu release notes: 8.04 LTS
• Ubuntu release notes: 8.10
• Ubuntu release notes: 9.04
• Ubuntu release notes: 9.10
• Ubuntu release notes: 10.04 LTS
• Ubuntu release notes: 10.10
• Ubuntu release notes: 11.04
• Ubuntu release notes: 11.10
• Ubuntu release notes: 12.04 LTS
• Ubuntu release notes: 12.10
• Ubuntu release notes: 13.04
• Ubuntu release notes: 13.10
• Ubuntu release notes: 14.04 LTS
• Ubuntu release notes: 14.10
• Ubuntu release notes: 15.04
• Ubuntu release notes: 15.10
• Ubuntu release notes: 16.04 LTS
• Ubuntu release notes: 16.10
• Ubuntu release notes: 17.04
• Ubuntu release notes: 17.10
• Ubuntu release notes: 18.04 LTS
• Ubuntu release notes: 18.10
• Ubuntu release notes: 19.04
• Ubuntu release notes: 19.10
• Ubuntu release notes: 20.04 LTS
• Ubuntu release notes: 20.10
• Ubuntu release notes: 21.04
• Ubuntu release notes: 21.10
• Ubuntu release notes: 22.04 LTS
• Ubuntu release notes: 22.04.5
• Ubuntu release notes: 22.04 release schedule
• Ubuntu release notes: 22.10
• Ubuntu release notes: 23.04
• Ubuntu release notes: 23.10
• Ubuntu release notes: 24.04 LTS
• Ubuntu release notes: 24.04.5
• Ubuntu release notes: 24.04 release schedule
• Ubuntu release notes: 24.10 and its schedule
• Ubuntu release notes: 25.04 and its schedule
• Ubuntu release notes: 25.10 and its schedule
• Ubuntu release notes: 26.04 LTS
• Ubuntu release notes: 26.04 LTS summary for LTS users
• Ubuntu release notes: 26.04.1
• Ubuntu release notes: 26.04 release schedule
• Ubuntu release notes: 26.10
• Ubuntu release notes: 26.10 release schedule
• Ubuntu release notes: 27.04 release schedule
• Ubuntu: Release cycle
• Ubuntu: Kernel lifecycle and enablement stack
• Ubuntu: Expanded Security Maintenance
• Ubuntu: Ubuntu Pro
• Ubuntu Wiki: Releases
• Ubuntu: Old releases index
• Ubuntu Discourse: Ubuntu 23.04 (Lunar Lobster) released
• Ubuntu Server documentation: How to upgrade your Ubuntu release
• Ubuntu Pro client documentation: Basic commands
• Ubuntu Pro client documentation: How to attach
• Ubuntu manpages: lsb_release(1)
• Ubuntu manpages: os-release(5)
• Kali Linux documentation: Kali Linux history

Last reviewed: 23 October 2026.