Ubuntu 14.04 LTS Trusty Tahr: Release Facts, Kernel 3.13, Security

Ubuntu 14.04 LTS "Trusty Tahr" was released in April 2014 with Linux kernel 3.13 and the Unity desktop, and its standard security maintenance ended in April 2019. Expanded Security Maintenance through Ubuntu Pro ended in May 2024, so in October 2026 a 14.04 machine gets security fixes only through the paid Legacy add-on, which Canonical's release cycle page now lists as running to May 2029.

Trusty is the oldest Ubuntu release that still appears on Canonical's release cycle page, and it is the last LTS that booted with Upstart instead of systemd. It shipped in the same month as the Heartbleed disclosure and was on the front line five months later when Shellshock hit Bash. Below are the release facts with a citation for each, what changed since 12.04 LTS "Precise Pangolin" and the three interim releases in between, the security defaults of the time, and exactly what the Legacy add-on does and does not cover in 2026. Where an official page does not state a fact, we say so, and where two official pages disagree, we cite both.

Key takeaways

• Released April 2014, codename Trusty Tahr. Canonical's release cycle, ESM and kernel lifecycle pages give the month; none of the official pages we fetched states the day.
• Kernel 3.13 at release (14.04.0 and 14.04.1). The 14.04.5 point release ships a 4.4 hardware enablement (HWE) kernel taken from 16.04.
• Unity desktop, streamlined for the LTS with HiDPI scaling, a new lock screen and an option to put menus in window title bars. The release notes do not state a Unity version number for 14.04.
• Upstart was still the init system, upgraded to 1.12.1. systemd replaced Upstart in 15.04, so 14.04 is the last LTS on Upstart.
• Support: standard security maintenance ended April 2019. ESM (Ubuntu Pro) ended May 2024. The Legacy add-on runs to May 2029 per the release cycle and ESM pages, although Canonical's March 2024 announcement and the Pro Client docs describe only two extra years. Flavours other than Desktop, Server, Core, Kubuntu, Edubuntu and Ubuntu Kylin got 3 years.
• ESM and Legacy coverage on 14.04 is amd64 only, Main only. The ESM page lists Universe coverage for Trusty as "n/a".
• Security changes: AppArmor gained signal and ptrace mediation, LXC 1.0 brought unprivileged containers, strongSwan became the supported IPsec stack, and Apache 2.4 and PHP 5.5 replaced the 12.04 versions.
• Heartbleed and Shellshock: Heartbleed (CVE-2014-0160) was fixed on 7 April 2014 for the releases then supported; the tracker does not list 14.04 for it. Shellshock needed three Bash updates on 14.04, ending at 4.3-7ubuntu1.3.
• Upgrade path: 14.04 can only go to 16.04 LTS, which is itself past ESM. A Trusty machine needs several release upgrades, or a rebuild, to reach a supported release.

What are the Ubuntu 14.04 LTS release facts?

Two notes on that table. First, the release cycle page lists s390x among 14.04's supported architectures, but the release notes' download list does not include an s390x image, and the ESM page lists only amd64 for Trusty's extended coverage. If you run 14.04 on anything other than amd64, your extended coverage options ended in April 2019. Second, the release notes say the Ubuntu Desktop image had grown "bigger than a standard CD," so installation needed a USB stick or DVD.

What happened when: the 14.04 timeline

The kernel lifecycle page dates 14.04.0 to April 2014 and 14.04.1 to July 2014. The release dates of 14.04.2, 14.04.3, 14.04.4 and 14.04.6 are not stated on the pages we fetched.

How long is Ubuntu 14.04 LTS supported?

Canonical's release cycle page gives 14.04 four dates: standard security maintenance to April 2019, Expanded Security Maintenance with Ubuntu Pro to May 2024, break/bug support to May 2024, and the Legacy add-on to May 2029. The ESM page repeats the same four dates in its release table, and its coverage table lists Trusty's Main coverage to May 2029, Universe as "n/a", and both Livepatch and ESM architectures as amd64.

The general model behind those dates, from the same release cycle page: LTS releases get "5 years of standard security maintenance" for packages in Main; ESM extends Main to 10 years and adds Universe; and "at the end of the 10 year ESM period, the Legacy add-on can be purchased to cover additional 5 years," for 15 years in total. The Ubuntu Pro page says the same: "With the Legacy add-on, this is extended an additional 5 years, giving you a 15 year security maintenance and support commitment."

The support story changed more than once

Trusty's support window is the clearest example of Canonical stretching an old release. The release notes promised 5 years for the main products and 3 years for most flavours. ESM then took Main coverage to 10 years. In March 2024, a month before ESM was due to end, Canonical announced the Legacy add-on "starting with Ubuntu 14.04 LTS." The current release cycle page now shows that add-on running to May 2029, 15 years after release.

Where the official sources disagree

Three official Canonical sources give different lengths for Trusty's Legacy coverage:

• The March 2024 announcement is titled "Canonical expands Long Term Support to 12 years starting with Ubuntu 14.04 LTS." It says Pro coverage for 14.04 "will end in April 2024" and that the add-on gives "an additional two years of expanded security maintenance."
• The Pro Client guide for Trusty (last updated July 2025) also describes "an additional two years of extended security coverage."
• The release cycle page, the ESM page and the Ubuntu Pro page describe a 5 year Legacy add-on and list May 2029 as the end date for 14.04.

We use May 2029 in this post because the release cycle and ESM pages are Canonical's current lifecycle references and both give it. The month the ESM period ended also differs: the 2024 announcement says April 2024, while the release cycle and ESM tables say May 2024. If you are budgeting a Trusty fleet past April 2026, confirm the end date in your own Ubuntu Pro contract rather than relying on any web page, ours included.

What "Legacy only" means for 14.04 in 2026

In October 2026, a 14.04 machine without the Legacy add-on receives no new security updates from Canonical at all. With the add-on, it receives Main updates on amd64 through the esm-infra-legacy service, plus Livepatch on amd64. The ESM page says ESM covers "high and critical CVEs" and Livepatch; the Pro page describes ESM as fixes for "critical, high and selected medium vulnerabilities." Neither page says that low and most medium priority issues are patched on a release in its Legacy years, so plan as if they are not.

What Legacy does not cover on Trusty:

• Universe packages. The ESM table lists Universe as "n/a" for 14.04. Language runtimes, libraries and tools that live in Universe have had no Canonical security updates since April 2019.
• Non-amd64 machines. i386, armhf, arm64 and ppc64el installs are outside ESM and Legacy for 14.04.
• New Pro Client features. The Trusty guide says the client package is "almost frozen" at version 19.7, with updates only for "critical CVE maintenance or features explicitly targeted for Trusty."
• Anything you installed outside the archive: application dependencies from language package managers, vendor .deb files, PPAs and software you built yourself.

Ubuntu Pro is free for personal use on up to five machines, according to the release cycle page and the Pro page. The Legacy add-on is described on the same pages as something that "can be purchased," and the Trusty guide says you must buy it before the service becomes entitled. Our Ubuntu Pro and ESM history covers how that model developed release by release, and the support lifecycle explainer covers the terms.

What kernel does Ubuntu 14.04 LTS use?

Ubuntu 14.04 shipped with Linux 3.13. The release cycle page lists 3.13 as 14.04's kernel, the kernel lifecycle page lists 3.13 for both 14.04.0 (April 2014) and 14.04.1 (July 2014), and the 14.04 release notes refer to "the Linux 3.13 kernel shipped as default in 14.04 LTS" in their Open vSwitch section. The release notes do not give the exact Ubuntu kernel package version for 14.04.0, unlike the 13.04 and 13.10 notes, which name 3.8.0-19.29 and 3.11.0-12.19.

Hardware enablement kernels

On Trusty, newer point releases changed the default kernel for new installs. The kernel lifecycle page says "the 14.04.2 and newer point releases ship with an updated kernel and X stack by default." The 14.04 release notes describe the final state: the 14.04.5 point release ships with "a newer 4.4 Linux kernel from Ubuntu 16.04, and a matching X.org stack," based on the 4.4.0 Extended Upstream Stable Kernel Release, and "with 14.04.5, 14.04.2 through 14.04.4 have gone EOL."

The kernel versions used by 14.04.2, 14.04.3 and 14.04.4 are not stated on the release notes page or the kernel lifecycle page we fetched. The kernel lifecycle schedule lists only two kernel lines for Trusty, both with the same end dates:

Source: Ubuntu kernel lifecycle.

The release notes advise that "those running virtual or cloud images should not need this newer hardware enablement stack," and list three ways to stay on the original 3.13 stack: install from 14.04.0 or 14.04.1 media, upgrade into Trusty from an earlier release, or use the netboot images rather than the newer "utopic", "vivid", "wily" or "xenial" netboot images. To opt in to the 4.4 stack, the release notes and the kernel lifecycle page give this command for a server:

sudo apt-get install --install-recommends linux-generic-lts-xenial

On amd64 systems that boot with UEFI, the release notes add the matching signed kernel:

sudo apt-get install linux-signed-generic-lts-xenial

One trap documented in the notes: the proprietary fglrx graphics driver "will not work with the 14.04.5 kernel/X stack," and anyone who needed it had to stay on the 14.04.1 stack.

What desktop does Ubuntu 14.04 LTS ship?

Ubuntu Desktop 14.04 used Unity, which the release notes say "has been streamlined for the 14.04 LTS release." The changes they list:

• Support for high DPI screens and desktop scaling.
• A new screen saver and lock screen matching the Unity greeter, "with improved speed and security."
• An option, under Appearance settings, to show menus in the window's title bar instead of the top bar.
• A redesigned application spread (Super + W) that filters as you type.
• New window decorations, with window contents updated live while resizing.
• Dash scopes that can be switched on and off from inside the Dash.

The release notes do not give a Unity version number for 14.04. The 13.04 release notes are the ones that introduce "Unity 7," so 14.04 sits in the Unity 7 era, but the 14.04 page itself does not say so.

Other desktop changes in the notes: Nautilus switched to type-ahead find, many default applications regained menu bars under Unity, a new Ubuntu settings application derived from GNOME's control centre arrived, LibreOffice moved to 4.2.8, and Xorg moved to 15.0.1 with Mesa 10.1. Python 3.4 shipped as Canonical continued trying to remove Python 2 from the desktop image, while promising that Python 2 "will continue to be available" as the python package.

Flavours on Trusty included Edubuntu, Kubuntu, Lubuntu, Mythbuntu, Ubuntu GNOME, Ubuntu Kylin, Ubuntu Studio and Xubuntu, each with its own release notes on the wiki. Those wiki pages now return 404 after the wiki migration, so we do not give flavour desktop versions here.

Was Upstart still the init system on 14.04?

Yes. The 14.04 release notes say "Upstart has been upgraded to version 1.12.1." The switch came one release cycle later: 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."

That makes 14.04 the last LTS where services are managed by Upstart jobs under /etc/init and with the initctl, start and stop commands that the 13.10 release notes describe. The interim releases before Trusty built Upstart out further:

• 13.04 added upstart-file-bridge so jobs could react to filesystem changes, an upstart-monitor tool, and a technology preview of Upstart user sessions, off by default.
• 13.10 moved to Upstart 1.10, turned Upstart user sessions on by default, and added "native AppArmor support in Upstart."

For a team inheriting a 14.04 host, the practical consequence is that every custom service job has to be rewritten as a systemd unit during the upgrade to 16.04. The 15.04 notes say exactly that: "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."

AppArmor on 14.04

AppArmor was already enabled on Ubuntu long before Trusty, and the 14.04 cycle extended what it could mediate. The 14.04 release notes list:

• Fine grained mediation of signal(7).
• Fine grained mediation of ptrace(2).
• Improved D-Bus mediation, building on the D-Bus support added in 13.10.
• New abstractions for applications running under Unity.
• New tunables for XDG user directories, Dovecot and more.
• A new variable for referencing the current profile name inside policy.
• New Python 2 and Python 3 AppArmor libraries (python-apparmor and python3-apparmor).

The notes warn that "local policy may need to be adjusted, especially for signal and ptrace rules." So a site profile written for 12.04 could start denying signals or debugger attachment after an upgrade to 14.04. The known issues section adds that the apparmor-utils tools in "AppArmor 2.8.95" were rewritten, with early bugs in aa-genprof and aa-logprof that the notes later record as fixed.

There is a version discrepancy worth knowing. The release notes refer to AppArmor 2.8.95 for the tools at release, while the Ubuntu security documentation's AppArmor page lists 2.10.95 for 14.04 LTS, the same version it lists for 16.04. The security docs page does not say whether its figure is the version at release or after later updates; the release notes are the source for what shipped in April 2014.

The 13.10 changes Trusty inherited matter here too. The 13.10 release notes add D-Bus mediation down to member and method, native AppArmor support in Upstart, integration with the application confinement work for click packages, and better policy generation with aa-easyprof. They also warn about named AF_UNIX socket rules in older local policy.

For working with AppArmor modes on a modern system, see our post on AppArmor complain or enforce.

Firewall: ufw on 14.04

The Ubuntu security documentation's firewall page lists these versions for 14.04 LTS: iptables 1.4.21-1ubuntu1 and ufw 0.34~rc-0ubuntu2. It lists no nftables package for 14.04, where it does for 16.04 and later. The page says ufw "is available in Ubuntu, but disabled by default," and it does not single out 14.04 as an exception, so check the state on any host rather than assume.

The same page notes that nftables was introduced into the mainline kernel in version 3.13, the kernel Trusty shipped, even though Trusty's userspace firewall tooling remained iptables. Our post on ufw first steps covers configuration on current releases.

Secure Boot, compiler hardening and other platform defaults

The Ubuntu security documentation on UEFI Secure Boot 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." The page does not describe 14.04 specifically. What we can say is that 14.04 falls between those two points, and the release notes tell UEFI users on amd64 to install the signed HWE kernel package when they move to the 4.4 stack.

The default compiler and linker flags page explains that building everything as a position independent executable (PIE) was too costly on x86 at first, so Ubuntu "initially used it only for a select number of security-critical packages." PIE became the default on amd64, ppc64el and s390x in 16.10, and across all architectures in 17.10. Trusty predates both, so most of its packages are not built as PIE. The page describes stack protector, Fortify Source, RELRO and BIND_NOW, but does not give a per-release table showing which were on by default in 14.04, so we do not claim a status for each.

Full disk encryption on 14.04 was LUKS based through the installer; the release notes' only statements on it are known issues, such as the desktop installer being unable to unlock existing LUKS volumes and failing to reuse encrypted swap. The 14.04 release notes do not mention TPM backed encryption.

Server stack: what 14.04 shipped

The server section of the release notes is where most of the upgrade risk from 12.04 sits:

Two of those deserve a security note. LXC 1.0 brought unprivileged containers and a more flexible seccomp policy language, which mattered for anyone running untrusted workloads on Trusty hosts. And the move to strongSwan meant IPsec deployments on the old ipsec-tools stack were now on a community supported package, which the notes say users "are encouraged to migrate" away from "to maintain official support."

The release notes also document Oxide, a Chromium based webview that Canonical committed to keep up to date "for the duration of the LTS," while WebKit based libraries would get only "new upstream minor version releases." That is a rare case of release notes telling developers which web engine would get security updates.

Which security issues of that era hit 14.04, and how to confirm the fixes

Two 2014 vulnerabilities define Trusty's first year. We describe what was fixed and how to confirm the fix, not how either flaw is exploited.

Heartbleed (CVE-2014-0160)

The Ubuntu CVE tracker entry describes a flaw in OpenSSL 1.0.1 before 1.0.1g where the TLS and DTLS heartbeat extension was not handled properly, letting a remote party read process memory, including private keys. Ubuntu rates it High priority, CVSS 3 base score 7.5.

USN-2165-1 was published on 7 April 2014 and fixed libssl1.0.0 on 13.10 (1.0.1e-3ubuntu1.2), 12.10 (1.0.1c-3ubuntu2.7) and 12.04 (1.0.1-4ubuntu5.12). The tracker lists 10.04 as not affected. 14.04 does not appear in either the USN or the tracker's status table. The USN predates Trusty's April 2014 release, which is consistent with the fix being in place before 14.04 reached users, but neither page states which OpenSSL version 14.04 shipped, so we do not claim one.

The USN's update instructions carry a lesson that still applies: "After a standard system update you need to reboot your computer," and "since this issue may have resulted in compromised private keys, it is recommended to regenerate them." Patching the library does not undo a key that leaked before the patch, so the same advice applies to any key that sat on a machine running an affected OpenSSL build.

Shellshock (CVE-2014-6271, CVE-2014-7169)

The tracker entry for CVE-2014-6271 describes Bash through 4.3 processing trailing strings after function definitions in environment variables, reachable wherever an environment crosses a privilege boundary into Bash, for example SSH forced commands, CGI scripts and DHCP client scripts. Ubuntu rates it High, CVSS 3 score 9.8.

On 14.04, Shellshock took three updates:

The CVE-2014-7169 tracker entry confirms the end state: 14.04 is "Fixed in 4.3-7ubuntu1.3," with a security team note explaining the respin. The same notices fixed 12.04 (bash 4.2-2ubuntu2.3) and 10.04 (4.1-2ubuntu3.2).

The lesson is not about Bash in particular. A host that took the first update on 24 September and stopped there was still exposed, and on 14.04 so was a host that stopped at the second. "We patched it" needs to mean "we are on the fixed version the tracker lists today," not "we installed the update that came out first."

How to confirm you have the fixes

Ubuntu's Server package management guide uses dpkg -l filtered with grep to see the installed version of a package. On a 14.04 host:

dpkg -l | grep bash
dpkg -l | grep libssl

Compare the bash version with 4.3-7ubuntu1.3 or later. For OpenSSL, compare the libssl1.0.0 version against the 14.04 entries in later USNs for that package; the Heartbleed USN itself does not list a 14.04 version.

On current releases, the Pro Client's CVE check guide uses pro fix --dry-run CVE-XXXX-XXXX to show whether a system is affected without changing it. The Trusty client is frozen at version 19.7 and uses the ua name; the docs do not say whether 19.7 includes the fix command, so on Trusty compare package versions directly. Our post on checking for a distro backported fix explains why the version string, not the upstream version, is what counts on Ubuntu.

What changed from Ubuntu 12.04 LTS (and the 12.10 to 13.10 interims) to 14.04 LTS?

Many teams went straight from 12.04 LTS to 14.04 LTS, skipping 12.10 "Quantal Quetzal", 13.04 "Raring Ringtail" and 13.10 "Saucy Salamander." The 14.04 release notes and the 13.04 and 13.10 notes are the official record of what moved. The 12.04 and 12.10 pages on documentation.ubuntu.com are now stubs whose product overview pages we could not retrieve, so where the 12.04 value is only known from the 14.04 notes' own comparisons, we say so.

What the three interims added along the way, from their own release notes:

The 13.04 change to 9 month interim support is worth remembering: from 13.04 on, an interim release was supported for 9 months, so anyone who had moved off 12.04 to an interim was pushed onto 14.04 quickly. The release notes for 14.04 confirm the supported upgrade paths into Trusty were from 12.04 LTS or 13.10.

For the next step in the series, see Ubuntu 16.04 LTS Xenial Xerus, which covers the move from Upstart to systemd and the arrival of snaps.

Why 14.04 still turns up, and how to spot it in an SBOM

Trusty hosts tend to survive in three places: appliances and embedded systems built in 2014 to 2016, servers running software that was certified against a specific OS, and container images built from an old base and never rebuilt. The first two usually show up in an asset inventory. The third often does not, because the image builds and runs fine.

A software bill of materials of an image or host makes the release visible. The OS packages carry Ubuntu version strings, such as 4.3-7ubuntu1.3 for bash, and the release file in the image identifies Trusty. Once the release is visible, the question becomes how much of that image is actually covered: Main packages on amd64 if the host has the Legacy add-on, nothing at all in Universe, and nothing in the application dependencies layered on top. Our guide on how to check if your base image OS is end of life and the Docker Ubuntu image post cover the image side.

How do you check and upgrade an Ubuntu 14.04 system?

These steps use only commands from Canonical's docs. Steps 1 to 3 only read state.

Step 1: Confirm the release

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

lsb_release --description

Step 2: Check the kernel and HWE status

The kernel lifecycle page gives the support check:

hwe-support-status --verbose

On 14.04, the kernel line is 3.13 (installed from 14.04.0 or 14.04.1 media, or upgraded from 13.10 or 12.04) or the 4.4 lts-xenial line. The release notes say 14.04.2 to 14.04.4 HWE stacks have gone end of life, so a host still on one of those should move to the 4.4 stack with the linux-generic-lts-xenial command shown earlier.

Step 3: Check Ubuntu Pro status with the Trusty client

The Pro Client guide for Trusty notes that "on Trusty, Ubuntu Pro is referred to by its previous name: 'Ubuntu Advantage' (or ua)." First make sure the client is current. On a public cloud instance, the guide says you must first add the PPA it links to:

sudo apt update && sudo apt install ubuntu-advantage-tools

Then check which services are entitled and enabled:

sudo ua status

With the Legacy add-on, the guide shows the output including esm-infra, esm-infra-legacy and livepatch rows. If esm-infra-legacy shows as entitled but disabled, you have bought coverage that is not yet switched on.

On releases with the current Pro Client, the security-status explainer describes pro security-status, which prints "This machine is NOT receiving security patches because the LTS period has ended and esm-infra is not enabled" on an uncovered machine. The Trusty guide does not say whether client 19.7 has this command, so on 14.04 rely on ua status.

Step 4: Enable esm-infra-legacy

If the service is entitled, the Trusty guide enables it with:

sudo ua enable esm-infra-legacy

If ua status says you are not entitled, buy the add-on first, then refresh the contract and check again:

sudo ua refresh
sudo ua status

Keep esm-infra enabled as well. The guide warns that "if you disable esm-infra, this will (due to internal dependencies) also disable esm-infra-legacy," and recommends keeping both on even though updates arrive through the legacy service.

Step 5: Confirm the packages that matter

Use the package management guide's dpkg -l pattern to record versions of internet facing packages, such as OpenSSH, OpenSSL, Bash, Apache, PHP and the kernel image, and compare them with the 14.04 rows in the relevant USNs. Our guide on subscribing to Ubuntu security advisories covers how to get USNs as they are published.

Step 6: Upgrade to 16.04, then keep going

The 14.04 release notes describe the server upgrade tool, do-release-upgrade from the update-manager-core package, which runs inside GNU screen and re-attaches after a dropped connection. The Ubuntu Server upgrade guide says "you can only upgrade from one LTS release directly to the next sequential LTS release" and "you cannot skip releases." It asks you to fully update, back up, and check /run/reboot-required before running the upgrader:

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

The Trusty guide documents one Trusty specific problem: if packages are installed from esm-infra, do-release-upgrade "will fail since there will be an APT dependency issue." Its documented workaround is:

sudo RELEASE_UPGRADER_ALLOW_THIRD_PARTY=1 do-release-upgrade

After the upgrade to Xenial you must re-enable your Pro services yourself, "since Trusty lacks the correct mechanisms to re-enable the Pro services automatically after a do-release-upgrade."

Here is the catch. 16.04 is past both standard support (April 2021) and ESM (May 2026), per the ESM page, so landing on 16.04 moves you from one Legacy-only release to another. To reach a release with standard support you need 16.04, then 18.04, then 20.04, then 22.04 (standard support to May 2027) or 24.04 (May 2029). That is four or five release upgrades, each with a reboot, configuration prompts and, on the first hop, the move from Upstart to systemd. For container images, rebuilding on a supported base and retesting the application is almost always faster and safer than upgrading in place.

Common mistakes

• Assuming 14.04 is either "fully dead" or "fully covered." It is neither. Main packages on amd64 are covered with the Legacy add-on; Universe, other architectures and anything outside the archive are not.
• Trusting the two year figure or the five year figure without checking. Canonical's 2024 announcement and the Pro Client guide say two extra years; the release cycle and ESM pages say May 2029. Your contract decides.
• Disabling esm-infra to "clean up" a Legacy host. On Trusty that also disables esm-infra-legacy, and the machine silently stops receiving updates.
• Stopping at the first Shellshock update. On 14.04 the fixed Bash is 4.3-7ubuntu1.3, after two follow-up notices.
• Patching Heartbleed era OpenSSL without replacing keys. The USN says to regenerate keys that may have leaked.
• Leaving a host on a 14.04.2 to 14.04.4 HWE kernel. The release notes say those stacks are end of life; move to the 4.4 lts-xenial stack or back to 3.13.
• Expecting systemd. Trusty uses Upstart 1.12.1. Service files written for 16.04 and later do not apply, and upgrade plans must include rewriting Upstart jobs.
• Running ESM coverage checks on an i386 or ARM Trusty box. Extended coverage for 14.04 is amd64 only.
• Rebuilding the base image and calling the service fixed. Application dependencies pinned in a lockfile do not change when the OS layer does.
• Downloading Trusty ISOs from mirrors you do not control. Use releases.ubuntu.com/trusty or old-releases.ubuntu.com, and only for isolated testing.

FAQ

Is Ubuntu 14.04 still supported?

Only with the paid Legacy add-on to Ubuntu Pro. Standard support ended April 2019 and ESM ended May 2024. The release cycle page lists Legacy coverage to May 2029, for Main packages on amd64.

When did Ubuntu 14.04 reach end of life?

Standard security maintenance ended in April 2019 and ESM in May 2024, per the release cycle and ESM pages. Canonical's March 2024 announcement gives April 2024 for the end of Pro coverage. Without Legacy, May 2024 is effectively the end.

What kernel does Ubuntu 14.04 use?

Linux 3.13 at release, per the release notes and kernel lifecycle page. From 14.04.5 the default install media use the 4.4 HWE kernel from 16.04.

What desktop does Ubuntu 14.04 use?

Unity. The 14.04 release notes describe a streamlined Unity with HiDPI scaling and a new lock screen but do not state its version number.

Does Ubuntu 14.04 use systemd or Upstart?

Upstart, version 1.12.1. systemd became the default in 15.04, so 16.04 was the first LTS on systemd.

Was Ubuntu 14.04 affected by Heartbleed?

The Ubuntu CVE tracker and USN-2165-1 do not list 14.04 for CVE-2014-0160; the fix was published on 7 April 2014 for 13.10, 12.10 and 12.04, before Trusty's April release. Neither page states which OpenSSL version 14.04 shipped.

How do I know if my Ubuntu 14.04 server is patched for Shellshock?

Check the installed bash package version with dpkg -l | grep bash. The CVE-2014-7169 tracker entry lists 14.04 as fixed in 4.3-7ubuntu1.3.

Can I upgrade Ubuntu 14.04 directly to 22.04 or 24.04?

No. The Server upgrade guide says you cannot skip LTS releases. The path is 16.04, 18.04, 20.04, then 22.04 or 24.04.

Does Livepatch work on Ubuntu 14.04?

The ESM page lists Kernel Livepatch for 14.04 on amd64, and the Pro Client guide shows livepatch as a service alongside esm-infra-legacy on Trusty. It needs an Ubuntu Pro subscription with coverage for the release.

Is the Ubuntu 14.04 Legacy add-on free for personal use?

Ubuntu Pro is free for personal use on up to five machines. The Legacy add-on is described on Canonical's pages as something that "can be purchased," and the Trusty guide says you must buy it before esm-infra-legacy becomes entitled.

Fix it without waiting for upstream

On a Legacy-only release like 14.04, Canonical still patches Main packages on amd64 for paying customers. It does not patch Universe, and it never patched the application layer you build on top: the npm, PyPI, Maven, Go and Rust dependencies in your services, vendor packages and anything you compiled yourself. A Trusty image can be fully up to date with esm-infra-legacy and still carry a vulnerable library in every service it runs.

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 a Trusty 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 14.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. When you move a service off a 14.04 base, its own dependencies have usually aged just as badly, and this is the flow for bringing them up to fixed versions.

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 Trusty images that cannot leave a restricted network, it means the scan runs 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 bash or OpenSSL versions from a Trusty base, while you decide 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 every Ubuntu version with its kernel and support dates, see our Ubuntu release history hub. For deciding whether to keep paying for an old release or move off it, see upgrade, extend, isolate or retire.

Quick check

Sources

• Ubuntu release notes: Ubuntu 14.04 LTS
• Ubuntu release notes: Ubuntu 13.10
• Ubuntu release notes: Ubuntu 13.04
• Ubuntu release notes: Ubuntu 12.10
• Ubuntu release notes: Ubuntu 12.04 LTS
• Ubuntu release notes: Ubuntu 14.10
• Ubuntu release notes: Ubuntu 15.04
• Ubuntu: Release cycle
• Ubuntu: Expanded Security Maintenance
• Ubuntu: Kernel lifecycle and enablement stack
• Ubuntu: Ubuntu Pro
• Ubuntu: Livepatch
• Canonical: Canonical expands Long Term Support to 12 years starting with Ubuntu 14.04 LTS (25 March 2024)
• Ubuntu Pro documentation
• Ubuntu Pro Client documentation: How to enable esm-infra-legacy on Trusty
• Ubuntu Pro Client documentation: What does security-status do?
• Ubuntu Pro Client documentation: The pro status output explained
• Ubuntu Pro Client documentation: How to know if a system is affected by a CVE
• Ubuntu CVE tracker: CVE-2014-0160
• Ubuntu CVE tracker: CVE-2014-6271
• Ubuntu CVE tracker: CVE-2014-7169
• Ubuntu security notice USN-2165-1
• Ubuntu security notice USN-2362-1
• Ubuntu security notice USN-2363-1
• Ubuntu security notice USN-2363-2
• 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: Package management
• Ubuntu Desktop documentation: Switch between an LTS and interim release
• Ubuntu 14.04.6 LTS images
• Old Ubuntu releases

Last reviewed: 23 October 2026.