Ubuntu 16.04 LTS Xenial Xerus: Release Facts, Kernel 4.4, Security

Ubuntu 16.04 LTS "Xenial Xerus" was released in April 2016 with Linux kernel 4.4 and the Unity 7 desktop, and its standard security maintenance ended in April 2021. Expanded Security Maintenance through Ubuntu Pro ended in May 2026, so in October 2026 a 16.04 machine gets security fixes only through the paid Legacy add-on, which runs to May 2031.

That makes 16.04 the oldest Ubuntu release many teams still find in production, usually inside an old container base image, an appliance or a server nobody wanted to touch. Below are the release facts with a citation for each, what changed since 14.04 LTS "Trusty Tahr", and the security story: systemd, snaps, Livepatch, APT privilege separation, OpenSSH defaults and the extended support window. Where an official page does not state a fact, we say so.

Key takeaways

• Released April 2016, codename Xenial Xerus. Canonical's release cycle and kernel lifecycle pages give the month; none of the official pages we fetched states the day.
• Kernel 4.4, from the upstream long-term 4.4 series. The 16.04.5 point release added a 4.15 hardware enablement (HWE) kernel in July 2018.
• Unity 7 desktop, with most GNOME components at 3.18. Ubuntu Software replaced the Ubuntu Software Center, and online searches in the Dash were switched off by default.
• Support: standard security maintenance ended April 2021. ESM ended May 2026. The Legacy add-on runs to May 2031, which is 15 years from release. Flavours other than Desktop, Server, Core and Ubuntu Kylin got 3 years.
• First LTS on systemd. systemd replaced Upstart in 15.04, so 14.04 LTS users met it for the first time on 16.04.
• Snaps arrived as a new package format beside debs, confined with AppArmor, seccomp and namespaces.
• Security defaults changed quietly: APT 1.2 fetches as an unprivileged _apt user, OpenSSH 7.2p2 turned off SSH protocol 1 and several weak algorithms, and MySQL 5.7 switched an empty root password to socket authentication.
• Upgrade path: 16.04 can only go to 18.04 LTS, which is itself past standard support. Plan for several hops or a rebuild on a supported release.

What are the Ubuntu 16.04 LTS release facts?

The release notes link flavour notes for Kubuntu, Lubuntu, Ubuntu GNOME, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Xubuntu and Mythbuntu. Most point to wiki.ubuntu.com, and the XenialXerus/ReleaseNotes wiki page returned 404 on 23 October 2026, so flavour specifics are thin in the official record.

What happened when: the 16.04 timeline

The version number is the year and month of release; the release cycle page says releases "are versioned by the year and month of delivery."

How long is Ubuntu 16.04 LTS supported?

The short answer for October 2026: only through the Legacy add-on, until May 2031.

The 16.04 release notes set the original promise: "Ubuntu 16.04 LTS will be supported for 5 years for Ubuntu Desktop, Ubuntu Server, Ubuntu Core, and Ubuntu Kylin. All other flavours will be supported for 3 years." Note the flavour line. Compared with 14.04, whose notes gave 5 years to Kubuntu and Edubuntu as well, the 16.04 five year list is shorter; Kubuntu 16.04 got 3 years.

Canonical's release cycle page and ESM page give the current dates:

What each window means comes from the same pages. Standard support covers the Main repository for 5 years. The Ubuntu Pro page says Pro "extends the life of every Ubuntu LTS from 5 years of standard security maintenance for the Main repository to 10 years for the entire Ubuntu Archive (Main and Universe repositories)," and "With the Legacy add-on, this is extended an additional 5 years, giving you a 15 year security maintenance and support commitment." The release cycle page describes the Legacy add-on as something that "can be purchased" at the end of the 10 year ESM period.

The ESM page splits ESM into two streams. "esm-infra" covers Main after the free five years end, and "esm-apps" "covers all 'Universe' packages for ten years from the release of the LTS." For 16.04 the ESM page lists both Main and Universe coverage to May 2031, Kernel Livepatch on amd64, and ESM architectures of amd64 and s390x. The release cycle page lists six architectures for 16.04, so if you run 16.04 on arm64, armhf, i386 or ppc64el, the ESM page does not list your architecture for extended coverage. Confirm with Canonical before you rely on it.

The support story changed twice

16.04's support window was extended after the fact, and older internal documents may carry the old dates. A Canonical tutorial posted on Ubuntu Discourse on 14 April 2021 said that after April 2021, patches would come only through ESM, "with security patches provided for an additional three years beyond the traditional five-year standard support." That would have ended ESM around 2024. The release cycle and ESM pages fetched on 23 October 2026 show ESM to May 2026 and a Legacy add-on to May 2031. We use the current release cycle page in every table here. If a risk register or vendor contract still says 2024 for 16.04, it was written against the older statement.

The same tutorial calls the token an "Ubuntu Advantage token," the earlier name for Ubuntu Pro.

What "Legacy only" means in practice

Since May 2026, a 16.04 machine without the Legacy add-on receives no new security updates. The Pro page says Pro is free "for personal use on up to 5 physical machines," but none of the pages we fetched says that free tier includes Legacy coverage. Ask Canonical before you assume it does.

Our posts on whether Ubuntu patches Universe packages and on the general choice to upgrade, extend, isolate or retire end-of-life software cover the decision in more depth.

What kernel does Ubuntu 16.04 LTS use?

Ubuntu 16.04 LTS uses Linux 4.4. The release notes say it "is based on the long-term supported Linux release series 4.4," and the release cycle page lists 4.4 for 16.04.

Later point releases changed the default kernel on desktops. The kernel lifecycle page says "The 16.04.2 and newer point releases ship with an updated kernel and X stack by default for the desktop. Server installations default to the GA kernel and provide the enablement kernel as optional," and that "The 16.04 HWE stacks follow the Rolling Update Model." The rolling HWE kernel ended on 4.15, the 18.04 kernel, which arrived as the 16.04.5 HWE kernel in July 2018.

All rows are from the kernel lifecycle page. Two practical points follow. First, a 16.04 server can be on either 4.4 or 4.15 depending on how it was installed and whether someone moved it to HWE, so uname -r is the only reliable answer for a given host. Second, the 4.4 kernel also lives on many 14.04 hosts as their HWE kernel; the 14.04 release notes say the 14.04.5 point release "will ship with a newer 4.4 Linux kernel from Ubuntu 16.04." A 4.4 kernel in an inventory is not proof of a 16.04 userland.

The kernel lifecycle page gives the 16.04 HWE install commands, still found in old build scripts:

# Desktop
sudo apt-get install --install-recommends linux-generic-hwe-16.04 xserver-xorg-hwe-16.04
# Server
sudo apt-get install --install-recommends linux-generic-hwe-16.04

What desktop does Ubuntu 16.04 LTS ship?

Ubuntu Desktop 16.04 ships the Unity 7 desktop on Compiz. The release notes call the theme for the desktop "one of bug fixes and incremental quality improvements." They name Unity 7 in the known issues section but do not give a Unity point version, so we do not state one.

From the 16.04 release notes:

• "GNOME is mostly upgraded to 3.18," with GLib at 2.48, which corresponds to GNOME 3.20.
• GNOME Software replaced the Ubuntu Software Center and was renamed "Ubuntu Software."
• "Online searches in the dash are now disabled by default." That is a privacy relevant default worth knowing about if you still audit 16.04 desktops.
• All default applications and libraries moved to WebKit 2.
• Firefox 45, Chromium 48 and LibreOffice 5.1 shipped.

The proprietary fglrx driver was deprecated, and upgrading removed it in favour of the open source radeon and amdgpu drivers.

First LTS on systemd: what changed in service management and security?

16.04 was the first LTS release to boot with systemd. The 16.04 notes themselves do not discuss it, because the switch happened two releases earlier. The 15.04 release notes say "systemd has replaced Upstart as the standard boot and service manager on all Ubuntu flavors except Touch," while "Upstart continues to control user sessions." The 14.04 release notes still list Upstart 1.12.1. An organisation that went LTS to LTS therefore met systemd for the first time when it upgraded from 14.04 to 16.04.

What changed in practice, according to the 15.04 notes:

• Custom jobs had to be rewritten. "If you use custom or third-party Upstart jobs, you need to write a corresponding systemd service file or SysV init.d script for it." An upgraded host with an unconverted Upstart job could boot without that service running, which for a monitoring agent, log shipper or backup job is a quiet security gap.
• Resource limits moved. "With the switch to systemd, process limits such as the maximum number of open files can now be controlled by tuning the unit configuration file," and the notes give MySQL as the example, advising administrators to move open_files_limit style tuning into the unit file to avoid conflicting settings.

The Ubuntu AppArmor documentation now notes that "On boot, systemd manages AppArmor profiles directly when it comes to early policy loading." Whether 16.04 did the same is not stated in its notes.

Snaps arrive: confinement and AppArmor

The headline new feature in the 16.04 release notes is a new package format: "Ubuntu 16.04 LTS introduces a new application format, the 'snap', which can be installed alongside traditional deb packages." The notes say the two formats "live quite comfortably next to one another." The 15.04 and 15.10 notes had already shipped "Snappy" Ubuntu Core images, which the 15.10 notes describe as "a super-lean, transactionally updated version of Ubuntu."

The security model is documented in the current snap docs. The snap confinement page describes the levels:

• Strict, "used by the majority of snaps." Strictly confined snaps "can not access files, network, processes or any other system resource without requesting specific access via an interface."
• Classic, which "allows access to the system's resources in much the same way traditional packages do." Publishing one "requires manual approval," and installing one requires an explicit classic flag.
• Devmode, a developer mode that cannot be released to the stable channel.

How strict confinement is enforced, from the same page: "Strict confinement uses security features of the Linux kernel, including AppArmor, seccomp and namespaces." The snap security policies page goes further. When a snap is installed, "its metadata is examined and is used to derive AppArmor profiles, Seccomp filters and device cgroup rules." AppArmor profiles are "generated for each command" and mediate "file access, application execution, Linux capabilities, mount, ptrace, IPC, signals, coarse-grained networking." A seccomp filter is generated per command for allowlist system call filtering, and a policy violation returns EPERM (the page notes snapd releases before 2.32 sent SIGSYS instead).

Two cautions. These pages describe snapd today, not the April 2016 version, and the 16.04 notes do not describe confinement in detail. And the security policies page warns that classic snaps "do not benefit from snapd's sandboxing and isolation features." The confinement page says to "look for classic under the Notes column in the output of snap list." Our post on snap and Flatpak security models compares the approaches.

The next interim release built on this. The 16.10 release notes added "Support for AppArmor profile stacking," which "allows containers to load their own AppArmor profiles," and made it possible to install snaps inside LXD containers.

Canonical Livepatch: which releases and what it covers

Livepatch applies fixes to a running kernel without a reboot. The Livepatch page says it "shrinks the exploit window for critical and high severity Linux kernel vulnerabilities, by patching the Linux kernel between security maintenance windows," and that it "provides security coverage for 10 years with Ubuntu Pro, and an additional five years with Ubuntu Pro's Legacy add-on, for a total of 15 years." The Livepatch docs describe it as "part of the Ubuntu Pro offering."

What it covers, from the Livepatch page: patches for kernel vulnerabilities "with critical and high Common Vulnerability Scoring System (CVSS) and Ubuntu Priority ratings," targeting issues "such as privilege escalation or remote code execution" that "are practical to patch safely in-memory." What it does not do: "Canonical Livepatch is not a replacement for rebooting." Medium and low kernel fixes, and anything not practical to patch in memory, still need a new kernel and a reboot.

For 16.04 specifically, the ESM page lists Kernel Livepatch on amd64 only, through May 2031 with the Legacy add-on. When Livepatch first became available for 16.04 is not stated on any official page we fetched, so we do not give a launch date here. The Livepatch page gives the commands to attach a machine and enable it:

sudo pro attach [TOKEN]
sudo pro enable livepatch

Our post on what kernel Livepatch fixes and what still needs a reboot goes deeper.

ZFS, APT 1.2 and archive signatures

ZFS. The TOPICS brief for this series asked us to confirm that ZFS on Linux shipped in the 16.04 archive. The 16.04 release notes on documentation.ubuntu.com do not mention ZFS, and neither does any other page we fetched for this post. The closest official reference is in the 14.04 notes, where LXC 1.0 supports "LVM or zfs backing stores." We leave ZFS out of the release facts as not stated in the official release notes.

APT 1.2. This one is documented, and it is a real security change. The release notes say "Apt 1.2 includes the new privilege separation features introduced in Apt 1.1. Importantly, the unprivileged '_apt' user is now used when making outgoing network connections and parsing the results for the various apt transport methods (HTTP, HTTPS, FTP)." That moves the code that talks to mirrors and parses their responses out of the root account, so a bug in a transport method or a parser handling a hostile response runs with far less privilege.

Stronger archive signature checks. The 16.04 release notes do not describe any change to how APT verifies archive signatures, so we cannot confirm that claim from official sources. What is documented is that Ubuntu archives are signed and that APT verifies them; our explainer on Linux distribution package signing covers how that works.

Other security relevant changes in 16.04

OpenSSH 7.2p2: weak cryptography off by default

The release notes warn that "Recent OpenSSH releases disable several pieces of weak, legacy, and/or unsafe cryptography," and that anyone upgrading over SSH should check they do not rely on them. In 16.04:

• Support for SSH protocol 1 "is disabled by default at compile time." The separate openssh-client-ssh1 package exists only for reaching old SSH1-only servers.
• The 1024-bit diffie-hellman-group1-sha1 key exchange is disabled at run time.
• ssh-dss host and user keys are disabled at run time.
• The legacy v00 certificate format was removed.
• blowfish-cbc, cast128-cbc, all arcfour variants and the rijndael-cbc aliases are disabled in the client, as are MD5-based and truncated HMAC algorithms.

The known issues section adds one more: "The default of the 'UseDNS' configuration option has changed from yes to no." Anyone using from= host restrictions in authorized_keys could be locked out after a remote upgrade.

MySQL 5.7 and socket authentication

"Packaging now enables socket authentication when the MySQL root password is empty. This means that a non-root user can't log in as the MySQL root user with an empty password." An empty MySQL root password used to be a common default on test hosts; on 16.04 only the system root user can use it.

Python 3 by default, Python 2 off server images

"Python2 is not installed anymore by default on the server, cloud and the touch images." Python 3 moved to the 3.5 series.

Server stack versions

The server baseline you will find in old images: PHP 7.0, MySQL 5.7, nginx 1.9.15 (1.10.0 expected as a stable update), OpenStack Mitaka, QEMU 2.5, Open vSwitch 2.5.0, LXD 2.0 (pre-installed on all server installs) and docker 1.10. The toolchain was glibc 2.23, binutils 2.26 and GCC 5, and Apache httpd was built without HTTP/2.

AppArmor

The 16.04 release notes do not list AppArmor changes. The three releases before it did: 14.04 added fine grained mediation of signals and ptrace, 14.10 added mediation of abstract and anonymous Unix sockets, and the 15.04 kernel notes mention "a slew of improvements in Apparmor as well as improved seccomp support." Snap confinement in 16.04 built on all of that. For profile modes on a modern machine, see our AppArmor complain or enforce post.

Firewall

The 16.04 release notes do not state ufw's default state. The current Ubuntu firewall documentation says ufw is "available in Ubuntu, but disabled by default," and records one 16.04 specific change: "Starting with Ubuntu 16.04 LTS (Xenial Xerus), the iptables package provides versions of the iptables, ip6tables, arptables, and ebtables tools that work with the nftables API." The nftables backend did not become the default until 20.10. See our ufw first steps for turning it on.

Compiler hardening

Most 16.04 packages on 64-bit architectures were not built as position independent executables by default. The Ubuntu compiler flags documentation says PIE was first "used only for a select number of security-critical packages," then made "the default on amd64, ppc64el, and s390x as of Ubuntu 16.10," and across all architectures from 17.10. The same page documents stack protector, Fortify Source and RELRO, but does not give the release each became default, so we do not assign them to 16.04.

Secure Boot

The Ubuntu Secure Boot documentation says Secure Boot "was first introduced in Ubuntu 12.04 LTS (Precise Pangolin) with enforcing mode enabled for the bootloader but non-enforcing mode for the kernel," and that "Starting with Ubuntu 18.04 LTS (Bionic Beaver), Secure Boot verifies all critical components: bootloader, kernel, and kernel modules." 16.04 sits before that change.

A CVE example: Dirty COW on 16.04

The best known kernel flaw of the 16.04 era shows how to read Ubuntu's records for an old release. The Ubuntu CVE page for CVE-2016-5195, published 19 October 2016, describes a race condition in the kernel memory manager's handling of copy-on-write for private read-only memory mappings, which "a local attacker could use" to gain administrative privileges. Ubuntu rates it High priority, with a CVSS 3 score of 7.0.

For 16.04 the fix shipped in USN-3106-1 on 20 October 2016. The CVE page lists the xenial linux package as "Fixed in 4.4.0-45.66." The USN says that after updating "you need to reboot your computer to make all the necessary changes," and warns of an ABI change that means third party kernel modules must be rebuilt.

To confirm a host has that fix, check that the running kernel is the fixed version or later. uname -r shows the running kernel ABI, for example 4.4.0-45-generic or higher. A host that installed the update but never rebooted still runs the old kernel. That gap between "installed" and "running" is exactly what Livepatch was built for. Our guide on checking a distro backported security fix explains why Ubuntu's version numbers, not upstream kernel versions, are what you compare.

What changed from Ubuntu 14.04 LTS to 16.04 LTS?

Three interim releases sat between the two LTS releases. Each was supported for 9 months, according to its own release notes.

Sources: the 14.04, 14.10, 15.04, 15.10 and 16.04 release notes, and the release cycle page for the 14.04 kernel. The 15.04 notes call signed kexec "a key gap in secure boot support."

And the direct LTS to LTS comparison:

To upgrade a 14.04 server, the 16.04 notes say to install update-manager-core, set /etc/update-manager/release-upgrades to lts, and run sudo do-release-upgrade. Kubuntu was the exception: "LTS to LTS upgrade to Xerus is currently problematic," so install fresh. Our post on the 14.04 Trusty Tahr release covers the release before.

Why 16.04 still turns up in container images, and how to spot it in an SBOM

16.04 had five years of free updates and a server baseline (PHP 7.0, MySQL 5.7, Python 3.5) that many applications were written against, so images built on it often still sit in registries. A base image that "still works" rarely gets rebuilt without a reason, and the host kernel and its Livepatch status do nothing for the packages inside it.

How to spot it:

1. Read the OS component in the SBOM. An SBOM generated from a container image records the operating system the image is built on. Look for Ubuntu 16.04 or the codename xenial.
2. Look for the 16.04 version baseline. Packages at the release notes versions, such as OpenSSH 7.2p2, PHP 7.0, MySQL 5.7, Python 3.5, glibc 2.23 or nginx 1.9 and 1.10, are a strong hint even when the OS metadata has been stripped.
3. Check the CVE status per package. On the Ubuntu CVE tracker, 16.04 entries are listed under "xenial," as on the Dirty COW page above. A package fixed only in an ESM or Legacy update will not reach an image that pulls only from the public archive. Our explainer on Ubuntu CVE statuses in a container scan explains what "deferred" and similar labels mean.
4. Check the end-of-life status of every base image. Our guide to checking whether a base image's operating system is end of life covers the general method, and our Docker Ubuntu image post covers tags.

How do you check and upgrade an Ubuntu 16.04 system?

These steps use only commands from Canonical's docs. The first five only read state.

Step 1: Confirm the release

The Ubuntu Desktop docs use this command; on a 16.04 machine the description line names 16.04 LTS:

lsb_release --description

Step 2: Check the kernel and HWE status

uname -r prints the running kernel, which on 16.04 starts with 4.4 or 4.15. The kernel lifecycle page gives the support check:

uname -r
hwe-support-status --verbose

Step 3: Check Ubuntu Pro and security coverage

The Pro Client docs explain pro security-status, which splits installed packages into Main, Universe, third party and "no longer available for download." The docs show the message a machine prints when its LTS period has ended and it has no extended coverage: "This machine is NOT receiving security patches because the LTS period has ended." The status explainer covers pro status, including the full view.

pro status
pro status --all
pro security-status
pro security-status --esm-infra
pro security-status --esm-apps
pro security-status --thirdparty
pro security-status --unavailable

Step 4: Attach and enable Livepatch if you have Legacy coverage

From the Livepatch page, with a token from the Ubuntu Pro portal:

sudo pro attach [TOKEN]
sudo pro enable livepatch

Step 5: Check that unattended-upgrades will pick up ESM

The automatic updates guide says that once installed, automatic security updates include "Expanded Security Maintenance (ESM) if that is available on the system," and shows the ESM origins in /etc/apt/apt.conf.d/50unattended-upgrades. Its dry run shows what would be applied without changing anything:

sudo unattended-upgrade -v --dry-run

The 16.04 release notes do not state whether unattended-upgrades was enabled by default on 16.04, so check the file rather than assume. Our post on unattended-upgrades settings covers the options.

Step 6: Upgrade to 18.04, then keep going

The Ubuntu Server upgrade guide uses 16.04 as its own example: "if you are on Ubuntu 16.04 LTS, you can upgrade to Ubuntu 18.04 LTS," but "you cannot skip releases (e.g. jump from 16.04 LTS to 20.04 LTS)." Bring the system fully up to date, back up, check /run/reboot-required, then run the upgrader:

sudo apt update
sudo apt dist-upgrade
sudo do-release-upgrade

The current guide also shows a dist-upgrade variant that includes phased updates, since phased packages can block a release upgrade. The guide also says "The system is not considered upgraded until this reboot occurs."

Here is the catch. 18.04 is past its own standard support (May 2023, per the ESM page), and so is 20.04 (May 2025). Landing on 18.04 moves you to a release whose ESM ends in May 2028. To reach a release with standard support you need 18.04, then 20.04, then 22.04 (standard support to May 2027) or 24.04 (May 2029). For servers that is four release upgrades, each with its own reboot and configuration prompts. For container images it is usually simpler and safer to rebuild on a supported base and retest the application.

Common mistakes

• Treating 16.04 as "on ESM." ESM ended in May 2026. Without the Legacy add-on there are no new fixes.
• Quoting the 2024 date. Documents written in 2021 may say ESM ends three years after April 2021. The current release cycle page says May 2026 for ESM and May 2031 for Legacy.
• Assuming every architecture is covered. The ESM page lists amd64 and s390x for 16.04, and Livepatch on amd64 only.
• Reading the kernel version as the release. A 4.4 kernel appears on 14.04.5 HWE hosts too, and a 16.04 host may run 4.15. Check both lsb_release and uname -r.
• Installing a kernel update and not rebooting. The Dirty COW USN is explicit that a reboot is needed. Without Livepatch, an installed fix is not a running fix.
• Skipping LTS releases. 16.04 cannot jump to 20.04 or 24.04. The upgrader goes one LTS at a time.
• Running classic snaps without noticing. Classic snaps are not sandboxed. Check the Notes column of snap list.
• Patching the host but not the images. A 16.04 base image in a registry stays exactly as it was built, whatever you do to the hosts.
• Networking a fresh install from an old ISO. It lacks every fix since its point release.

FAQ

Is Ubuntu 16.04 still supported?

Only with the Ubuntu Pro Legacy add-on, until May 2031. Standard support ended April 2021 and ESM ended May 2026, per the release cycle page.

When did Ubuntu 16.04 reach end of life?

Free standard security maintenance ended in April 2021. Paid ESM and break/bug support ended in May 2026. The final end, with the Legacy add-on, is May 2031.

What kernel does Ubuntu 16.04 use?

Linux 4.4. Desktop installs from 16.04.2 default to the rolling HWE kernel, which ended on 4.15 with 16.04.5. Servers default to 4.4.

What desktop does Ubuntu 16.04 use?

Unity 7, with most GNOME components at 3.18.

Was Ubuntu 16.04 the first release with systemd?

No, 15.04 was. 16.04 was the first LTS release with systemd, so users moving from 14.04 LTS met it for the first time on 16.04.

Does Ubuntu 16.04 support snaps?

Yes, 16.04 introduced snaps alongside debs. Strict snaps are confined with AppArmor, seccomp and namespaces; classic snaps are not.

Can I upgrade Ubuntu 16.04 directly to 20.04 or 24.04?

No. Canonical's server guide says you cannot skip LTS releases. Go to 18.04 first, then 20.04, 22.04 and 24.04, or rebuild on a supported release.

Does Livepatch still work on Ubuntu 16.04?

The ESM page lists Kernel Livepatch for 16.04 on amd64 until May 2031, which requires the Legacy add-on now that ESM has ended. Livepatch covers high and critical kernel fixes only and does not replace reboots.

Is Ubuntu 16.04 Legacy coverage free for personal use?

Ubuntu Pro is free for personal use on up to 5 machines, but the Legacy add-on is described as a separate purchase, and none of the official pages we fetched says the free tier includes it. Check with Canonical.

Where can I download Ubuntu 16.04 ISOs?

From releases.ubuntu.com/xenial, which lists 16.04.7, and earlier point releases from old-releases.ubuntu.com. Use them only in isolated test environments.

Fix it without waiting for upstream

On an end-of-life release like 16.04, the operating system packages are the part Canonical still patches, and only for machines with the Legacy add-on. The part it never patched is the application layer you build on top: the npm, PyPI, Maven, Go and Rust dependencies in your services, plus third-party packages that pro security-status counts as outside Ubuntu's coverage. Rebuilding a service on a newer base image does nothing for a vulnerable library pinned in its lockfile.

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

Safeguard scans repositories, container images and SBOM files and matches the components it finds against vulnerability databases, so a service built on an old Ubuntu base shows its OS packages and versions next to its application dependencies:

safeguard scan --dir .
safeguard scan --image your-image:tag
safeguard scan --sbom sbom.json

Results are written as JSON under ./output, and the platform shows every project that contains a given component and version, which is how you find every image still built on 16.04. Safeguard does not patch the host kernel or deliver Canonical's ESM or Legacy updates; those stay with Ubuntu Pro.

In this Safeguard CLI session you install the 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. Moving a service off a 16.04 base is the right time to bring its own dependencies up to fixed versions too, and this is the flow for doing it.

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. For teams auditing old images, it means the images and repositories are scanned on a machine you control. Our guide to how the local runner and offline mode work covers the details.

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

This demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Once connected, you can ask Claude which of your projects still carry a component version you are tracking, for example the OpenSSH or PHP versions that shipped with 16.04, while you plan which services to rebuild first.

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

To try it yourself, download Safeguard from safeguard.sh/download and follow the CLI docs.

For the full list of Ubuntu versions with their kernels and support dates, see our Ubuntu release history hub, and for the newest LTS, Ubuntu 26.04 LTS Resolute Raccoon.

Quick check

Sources

• Ubuntu release notes: Ubuntu 16.04 LTS
• Ubuntu release notes: Ubuntu 15.10
• Ubuntu release notes: Ubuntu 15.04
• Ubuntu release notes: Ubuntu 14.10
• Ubuntu release notes: Ubuntu 14.04 LTS
• Ubuntu release notes: Ubuntu 16.10
• Ubuntu release notes index
• Ubuntu: Release cycle
• Ubuntu: Kernel lifecycle and enablement stack
• Ubuntu: Expanded Security Maintenance
• Ubuntu: Ubuntu Pro
• Ubuntu: Livepatch
• Ubuntu: Livepatch documentation
• Ubuntu CVE tracker: CVE-2016-5195
• Ubuntu security notice USN-3106-1
• Ubuntu Discourse: Purchasing and Applying 16.04 ESM (April 2021 tutorial)
• Ubuntu Security documentation: AppArmor
• Ubuntu Security documentation: Firewall
• Ubuntu Security documentation: Default compiler and linker flags
• Ubuntu Security documentation: UEFI Secure Boot
• Ubuntu Server documentation: How to upgrade your Ubuntu release
• Ubuntu Server documentation: Automatic updates
• Ubuntu Desktop documentation: Switch between an LTS and interim release
• Ubuntu Pro Client documentation: What does security-status do?
• Ubuntu Pro Client documentation: The pro status output explained
• Ubuntu Pro documentation
• Snap documentation: Snap confinement
• Snap documentation: Security policies
• Ubuntu 16.04.7 LTS images
• Old Ubuntu releases

Last reviewed: 23 October 2026.