Ubuntu 12.04 LTS Precise Pangolin: Release Facts, Kernel 3.2, ESM

Ubuntu 12.04 LTS "Precise Pangolin" was released on 26 April 2012 with the Ubuntu 3.2.0-23.36 kernel (based on Linux 3.2.14) and the Unity desktop, and it was promised 5 years of support on both desktop and server. Standard support ended on 28 April 2017, and Extended Security Maintenance, which Canonical created for this release, ended in April 2019.

So in October 2026, any machine or container image still on 12.04 has gone more than seven years without an official security update. This post gives the release facts with a citation for each, explains why 12.04 was the first LTS with a 5 year desktop window and the first release with ESM, covers the security relevant defaults and what changed since 10.04 LTS "Lucid Lynx", and ends with how to find 12.04 packages that are still hiding in your estate. Many of the original 12.04 wiki pages now return 404, so several facts come from copies in the Internet Archive's Wayback Machine. We name the original URL each time and say where the copy came from. Where no official page we could reach states a fact, we say so.

Key takeaways

• Released 26 April 2012, codename Precise Pangolin. The release team's end of life notice states the date, and the release announcement was posted to the ubuntu-announce list that day.
• Kernel 3.2: the release shipped the Ubuntu 3.2.0-23.36 kernel, based on upstream stable 3.2.14. The amd64 generic and server kernel flavours were merged into one generic flavour.
• Unity desktop with GNOME components at 3.4.1, the HUD (Heads-Up Display) for searching menus by typing, and LightDM as the login manager carried over from 11.10. The Unity point version is not stated in the official notes we could reach.
• 5 years of support on desktop and server. Both the desktop and server notes list 5 years. The 10.04 LTS desktop had ended after 3 years, on 9 May 2013.
• Standard support ended 28 April 2017. Ubuntu Security Notices stopped covering 12.04 that day and the archive moved to old-releases.ubuntu.com.
• 12.04 was the first ESM release. Canonical announced "Ubuntu 12.04 ESM" on 15 March 2017 for Ubuntu Advantage customers. It covered high and critical CVEs in the most used server packages, on 64-bit x86 only, and ended in April 2019.
• No current coverage. Canonical's current release cycle and ESM pages do not list 12.04 in their support tables at all. There is no Legacy add-on for it.
• Security relevant changes: administrator rights moved from the admin group to the sudo group, the kernel enabled seccomp filters, AppArmor patches were updated, LXC containers gained AppArmor protection, and the Backports repository became enabled by default.
• Upgrade path: 12.04 goes to 14.04 LTS, which is itself only covered by the Legacy add-on now. A rebuild on a supported release is usually the cleaner answer.

What are the Ubuntu 12.04 LTS release facts?

A note on how the record survives. The 12.04 page on documentation.ubuntu.com carries an end of life warning and a short overview for 12.04.5. It points to separate wiki pages for Ubuntu Desktop, Ubuntu Server, Edubuntu, Kubuntu and Ubuntu Studio. Every one of those wiki pages, for example wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop, returned 404 when we checked on 23 October 2026. The Wayback Machine holds copies made in 2012, and the kernel, desktop, toolchain and support facts above come from them. The copies are of Canonical's own wiki, not a third party summary, but they are copies, so we label them every time.

What happened when: the 12.04 timeline

How long was Ubuntu 12.04 LTS supported?

The short answer: 5 years of free support, from 26 April 2012 to 28 April 2017, then 2 years of paid ESM to April 2019. Nothing since.

The archived Ubuntu Desktop release notes end with one line under Support: "5 years (Long Term Support)." The archived Ubuntu Server release notes say the same under Support Terms: "5 years, Long Term Support." The archived release notes overview lists Lubuntu without the "(LTS)" tag that Ubuntu, Server, Core, Edubuntu, Kubuntu, Mythbuntu, Ubuntu Studio and Xubuntu carry, so Lubuntu 12.04 was not an LTS flavour. The flavours' own support periods are not stated on the pages we could reach.

The end of life notice spelled out what end of life meant: "Ubuntu Security Notices will no longer include information or updated packages for Ubuntu 12.04." The confirmation sent on 28 April 2017 added that "No more package updates will be accepted to the 12.04 primary archive," and that the archive would be "copied for archival to old-releases.ubuntu.com in the coming weeks."

Why 12.04 was the first LTS with 5 years on the desktop

Before 12.04, Ubuntu LTS releases gave servers longer than desktops. The archived wiki Releases page lists 10.04.4 LTS with two end dates: "May 9, 2013 (Desktop)" and "April 30, 2015 (Server)". That is 3 years for the desktop and 5 for the server. The 8.04 rows on the same page also split into separate Desktop and Server entries. For 12.04 the same table gives one end date, 28 April 2017, for the whole release, and the desktop notes put "5 years" under Support.

None of the official pages we fetched gives Canonical's reasoning for the change. The practical effect was that 12.04 desktops could stay until 2017, where 10.04 desktops had to move by mid 2013, and every later LTS kept one shared five year window.

How Extended Security Maintenance began with 12.04

ESM started as a 12.04 product. On 15 March 2017, Dustin Kirkland of Canonical posted Ubuntu 12.04 ESM (Extended Security Maintenance) to the ubuntu-announce list. Following the end of life of 12.04, it said, Canonical "is offering Ubuntu 12.04 ESM," which "provides important security fixes for the kernel and the most essential user space packages in Ubuntu 12.04." The updates came from "a secure, private archive exclusively available to Ubuntu Advantage customers." Ubuntu Advantage was the subscription that later became Ubuntu Pro.

The release team's end of life notice, posted less than an hour later the same day, linked to it for "users who can't upgrade immediately."

Canonical's ESM page as archived in March 2019 (original URL https://www.ubuntu.com/esm) filled in the scope:

• The security team provided "fixes on high and critical CVEs" for "the most commonly used server packages in the Ubuntu main archive."
• It described ESM as "the essential continuation of the security updates for 12.04 LTS (Precise Pangolin) and 14.04 LTS (Trusty Tahr)."
• On hardware: "Currently, we are maintaining the Ubuntu Cloud/Server 64-bit AMD/Intel binaries." A 32-bit or ARM 12.04 system was outside ESM. The same archived FAQ said 14.04 and 16.04 would get ESM "for up to three years" after end of life, and 18.04 onward "up to five years." It gave no length for 12.04. The archived wiki Releases page answers that: its "Ubuntu 12.04 ESM" row shows ESM starting 28 April 2017, a duration of "2 years", and an end of "April 2019". That row is the earliest ESM entry in the table, which is why we call 12.04 the first ESM release. The announcement itself does not use the word "first."

What the current Canonical pages say about 12.04

Nothing in their tables. The current release cycle page starts its LTS rows at 14.04, and the current ESM page schedule does too. The only place 12.04 appears on the ESM page is a contact form, which files "12.04 LTS" under "Outdated or non-LTS releases." If a 12.04 host is still receiving packages from somewhere today, that source is not one of the Canonical channels these pages describe, and it is worth finding out what it is.

What kernel does Ubuntu 12.04 LTS use?

At release, Linux 3.2. The archived desktop and server notes both say: "At release we are shipping with the Ubuntu 3.2.0-23.36 kernel which is based on the v3.2.14 upstream stable Linux kernel." They describe the move as going "from the mainline v3.0 series to the mainline v3.2 series," since 11.10 had shipped the 3.0.0-12.20 Ubuntu kernel based on 3.0.4, per the 11.10 release notes.

Kernel changes listed in the 12.04 notes:

• The amd64 -generic and -server kernel flavours "have been merged into a single -generic kernel flavor," to "reduce the overall maintenance burden over the life of this LTS release."
• "An updated AppArmor patch set has been included to better align with what is landing upstream."
• "Applied and enabled the seccomp filters feature which uses the packet filtering machinery (BPF) to restrict access to system calls."
• The desktop installation image dropped support for processors without PAE: "The non-PAE version of the Linux kernel will be dropped completely following the 12.04 release."

Hardware enablement kernels on 12.04

12.04 was the first LTS where later point releases shipped newer kernels by default. The LTS Enablement Stack wiki page (Wayback copy from January 2016; original URL https://wiki.ubuntu.com/Kernel/LTSEnablementStack) says "The 12.04.2 and newer point releases will ship with an updated kernel and X stack by default," and that the stacks "can be installed manually, or are automatically shipped if installing from 12.04.2/14.04.2 and newer release media."

Its policy section adds detail that matters for inventories:

• "The 14.04 HWE stack will be the last and final HWE stack offered in Precise." The 14.04 release notes give that kernel as Linux 3.13.
• The 12.04.5 CDs and DVDs defaulted to the Trusty HWE stack. Anyone wanting the original 12.04 stack was told to install from 12.04.0 or 12.04.1 media.
• "Anyone running an original Precise stack will NOT be automatically updated to the new Trusty HWE stack."
• The page names Raring (13.04), Saucy (13.10) and Trusty (14.04) HWE stacks in 12.04. The intermediate stacks lost support on 8 August 2014, per the wiki Releases table.

The page names the stacks by release codename, not kernel version, and it does not give a kernel version for each. Apart from 3.2 at release and 3.13 for the final Trusty stack, we do not state the HWE kernel version numbers here.

The page gave these commands to opt into the final HWE stack:

# Desktop
sudo apt-get install --install-recommends linux-generic-lts-trusty xserver-xorg-lts-trusty libgl1-mesa-glx-lts-trusty
# Server
sudo apt-get install --install-recommends linux-generic-lts-trusty

The result is that a 12.04 server can report a 3.2 kernel or a 3.13 kernel, or one of the intermediate HWE kernels if someone installed from 12.04.2 to 12.04.4 media and never moved on. A 3.13 kernel also appears on 14.04 hosts. A kernel version alone does not tell you the userland release.

What desktop does Ubuntu 12.04 LTS ship?

Ubuntu Desktop 12.04 ships Unity. The archived desktop notes describe new System Settings options "to customize Unity's look and behavior," Nautilus quicklists in the Unity launcher, and known issues with the Unity Dash and Launcher. The archived 12.04.5 change summary calls it "Ubuntu with the Unity Desktop Environmanet" (sic). No page we reached gives a Unity version number, so we do not state one.

From the archived desktop release notes:

• The HUD. "There is a new way to quickly search and access menu and indicator actions, called the 'HUD' (Heads-Up Display)." You tap Alt and type, and it searches the menus of the focused application and the indicators. The notes add that "It learns from your previous choices."
• GNOME 3.4.1 components, with undo in the Files application.
• LibreOffice 3.5.2.
• Remmina with FreeRDP "is the new standard remote desktop client, replacing Vinagre and rdesktop."
• NetworkManager uses dnsmasq "for improved DNS reliability and support for split-DNS on VPN links," and IPv6 and IPv4 "are now equally supported."
• Wubi, the Windows installer, became a separate download instead of an option on the desktop media.

LightDM as the login manager is not described in the 12.04 notes because it arrived one release earlier: the 11.10 release notes say "Ubuntu now uses the LightDM login manager with the Unity greeter." The 12.04 notes do not say otherwise, so 12.04 LTS users coming from 10.04, which used GDM per the 10.04 release notes, met LightDM for the first time.

Two items from TOPICS that we could not confirm: the guest session and encrypted home directories. Neither is mentioned in the 12.04 desktop or server notes we reached, so we make no claim about their 12.04 defaults.

What security defaults and changes did Ubuntu 12.04 bring?

The 12.04 notes are not organised around security, but several changes in them are security relevant. Here they are with their sources.

Administrator access moved to the sudo group

Both archived notes say: "Up until Ubuntu 11.10, administrator access using the sudo tool was granted via the 'admin' Unix group. In Ubuntu 12.04, administrator access will be granted via the 'sudo' group." They add that "For compatibility purposes, the 'admin' group will continue to provide sudo/administrator access in 12.04."

That compatibility line is worth checking on any old host or image that started on 10.04. An account in admin kept full sudo rights after the upgrade, which can surprise an auditor who only looks at the sudo group.

Seccomp filters and AppArmor in the kernel

The kernel notes list seccomp BPF filters as "applied and enabled," giving programs a way to restrict which system calls they can make. The notes also list "an updated AppArmor patch set." The 11.04 release notes list "upstream acceptance of AppArmor" among the 2.6.38 kernel highlights.

The notes do not list which AppArmor profiles were enforced by default in 12.04. The current Ubuntu security documentation on AppArmor starts its version table at 14.04, so it does not answer that either. We leave it as not stated.

LXC containers under AppArmor

The archived server notes list among LXC improvements "Apparmor protection to increase security," along with the ability for stock 12.04 images to boot in a container and a template for creating containers from Ubuntu Cloud images.

OpenStack Essex: a default worth knowing

12.04 shipped OpenStack "Essex." The server notes carry a direct security warning: "The default install of Openstack should be used on a protected network, as many components use http (non-SSL) as a transport, and therefore subject to security concerns." They also note that /bin/false became the default shell for the nova user and that "nova uses nova-rootwrap by default, which provides a more fine grained security layer."

Backports enabled by default

"The Ubuntu Backports repository is now enabled by default," the notes say. Backports packages are not installed unless selected, but "once installed, packages from backports will automatically be upgraded to newer versions." When you analyse an old 12.04 image, check whether anything came from the precise-backports pocket, because those versions differ from what the security team patched in precise-updates and precise-security.

Firewall

ufw is not mentioned in the 12.04 notes we reached. The current Ubuntu security documentation on firewalls says ufw is "available in Ubuntu, but disabled by default," but its version table starts at 14.04. We do not have a 12.04 specific statement, so treat any 12.04 host as having whatever its administrator configured, and check.

Compiler hardening

The toolchain was GCC 4.6.3 with Linaro changes, binutils 2.22 and eglibc 2.15. The current Ubuntu documentation on default compiler and linker flags explains features like Fortify Source, RELRO and BIND_NOW, and says PIE became the default on amd64 in 16.10 and on all architectures in 17.10. It does not give 12.04 specific settings. What we can say is that 12.04 predates the PIE by default change, and the same page says PIE was at first used "only for a select number of security-critical packages," so do not assume a 12.04 binary is position independent.

Secure Boot, TPM and full disk encryption

No page we reached describes 12.04 support for UEFI Secure Boot, TPM-backed encryption or installer level full disk encryption. The desktop notes record a known issue that "Some EFI systems fail to boot in EFI mode, BIOS mode is advised." We state nothing further.

A CVE example: Heartbleed on 12.04

12.04 was affected by Heartbleed, while the previous LTS was not. USN-2165-1, published 7 April 2014, says OpenSSL "incorrectly handled memory in the TLS heartbeat extension," which could let an attacker "obtain up to 64k of memory contents from the client or server, possibly leading to the disclosure of private keys." The same notice fixed CVE-2014-0076, a timing side channel in ECDSA.

The Ubuntu CVE tracker for CVE-2014-0160 lists the precise openssl package as "Fixed in 1.0.1-4ubuntu5.12" and 10.04 Lucid as "Not affected," because Lucid shipped an older OpenSSL branch. The USN gives the 12.04 binary package as libssl1.0.0 at 1.0.1-4ubuntu5.12.

Two lessons from the notice still apply to any old image:

1. The USN says "After a standard system update you need to reboot your computer to make all the necessary changes." Long running services keep the old library loaded until they restart.
2. "Since this issue may have resulted in compromised private keys, it is recommended to regenerate them." Patching the package does not undo a key that leaked before the patch.

To confirm a 12.04 image has at least that fix, list the installed package with dpkg, as shown in the Ubuntu Server package management guide, and compare the version with 1.0.1-4ubuntu5.12:

dpkg -l | grep libssl

A version at or above that one has the Heartbleed fix. It does not have any fix released after 12.04 ESM ended in April 2019.

What changed from Ubuntu 10.04 LTS to 12.04 LTS?

Most LTS to LTS users skipped 10.10, 11.04 and 11.10, so they met all of the changes at once. This table brings them together.

The interim steps in between

The ptrace change deserves a note for anyone comparing old hosts. The 10.10 notes say "only child processes can be PTRACEd, due to the default value of '1' in /proc/sys/kernel/ptrace_scope," and point to /etc/sysctl.d/10-ptrace.conf. A 12.04 system inherited this. A 10.04 system did not have it. Debuggers attaching to running processes behaved differently after the upgrade, and some teams turned the setting off. On a surviving 12.04 host, check that file to see whether someone did.

How 10.04 users were told to upgrade

The archived server notes told 10.04 users to "wait until the first point release" and then use do-release-upgrade with Prompt=lts set in /etc/update-manager/release-upgrades. They warned that a server without console access might boot the old 10.04 kernel and hang unless the GRUB default was changed to the 12.04 kernel.

Why 12.04 packages still turn up, and how to find them

12.04 is old enough that few teams run it on purpose. It survives in three places:

• Container images. An image built years ago FROM a 12.04 base keeps that base forever unless someone rebuilds it. Our post on how to check if your base image operating system is end of life covers the general method.
• Appliances and embedded systems. A vendor appliance built on 12.04 may still be working fine on a network that nobody audits.
• Upgraded hosts with 12.04 leftovers. A host taken from 12.04 to 14.04 and onward can keep packages that no later release replaced, still carrying their precise version strings.

Package version strings give 12.04 away. Ubuntu packages built for a release carry the release number in their version, as in the Heartbleed fix above, 1.0.1-4ubuntu5.12, and the CVE tracker and USNs map those exact versions to the precise release. An SBOM that lists OS packages with those versions points straight at 12.04 content.

On a host, lsb_release --description and dpkg -l (both shown in the walkthrough below) give the release and the package list. For an image, an SBOM scan gives the same list without logging in to a running container.

How do you check and upgrade an Ubuntu 12.04 system?

These steps assume you own the machine and are planning to move it off 12.04. Commands come from the official documentation named in each step.

Step 1: Confirm the release

The Ubuntu Desktop documentation uses this to show the current release:

lsb_release --description

A 12.04 machine reports Ubuntu 12.04 with its point release number.

Step 2: Check the kernel and HWE status

The LTS Enablement Stack page (Wayback copy) pointed 12.04 users to a support check, and the current kernel lifecycle page still documents the same tool:

hwe-support-status --verbose

On 12.04 today the answer is academic, since the whole release is out of support. It does tell you which stack is installed, which matters when you plan the upgrade.

Step 3: Check ESM status

ESM for 12.04 ended in April 2019. The archived ESM page showed this command for enabling it at the time:

sudo ubuntu-advantage enable-esm [ENTER TOKEN]

If you find this configured on a 12.04 host, the host has received nothing new since April 2019. The Pro Client documentation describes pro security-status for releases still in the schedule; it does not apply to 12.04.

Step 4: Bring the system fully up to date before upgrading

The Ubuntu Server upgrade guide requires a fully updated system before a release upgrade:

sudo apt update

On 12.04 the archive moved to old-releases.ubuntu.com, per the end of life confirmation, so package sources pointing at the old mirror locations will fail until they are changed. On a host that old, apt-get is the client of the era; the 12.04 server notes use sudo apt-get update and sudo apt-get upgrade.

Step 5: Upgrade one LTS at a time

The upgrade guide is clear that "you cannot skip releases," and the 12.04 end of life notice says "The supported upgrade path from Ubuntu 12.04 is via Ubuntu 14.04." To stay on LTS releases, set Prompt=lts in /etc/update-manager/release-upgrades, as the desktop documentation describes, then run:

sudo do-release-upgrade

Then look at where that leaves you. The release cycle page shows 14.04 past both standard support (April 2019) and ESM (May 2024), with only the Legacy add-on running to May 2029. 16.04 is Legacy only to May 2031. Reaching a release in standard support from 12.04 means several more hops. For most services, building fresh on a supported LTS and moving the data is faster and less risky than a chain of in-place upgrades.

If an appliance cannot be upgraded, the remaining options are network isolation and replacement planning; our post on whether to upgrade, extend, isolate or retire end of life software walks through that decision.

Where to get official 12.04 ISOs, and why not to run them on a network

The old-releases.ubuntu.com/releases/12.04 directory keeps every 12.04 image: desktop, server and alternate ISOs for amd64 and i386 from 12.04.0 through 12.04.5, PowerPC images for the first release, and preinstalled armhf images for OMAP and other boards. It also publishes SHA256SUMS and SHA256SUMS.gpg files so you can verify a download. Download only from there or from other ubuntu.com hosts.

Use these images for forensics, reproducing an old bug, or testing a migration in an isolated lab. Do not connect a fresh 12.04 install to a network you care about. It will have every vulnerability fixed after 2014 for the 12.04.5 media, or after 2012 for the original, and no way to receive updates through the original archive.

Common mistakes

• Treating "12.04 is LTS" as "12.04 is supported." Standard support ended 28 April 2017 and ESM ended April 2019.
• Assuming the Legacy add-on covers 12.04. It does not appear in Canonical's current release cycle or ESM tables.
• Assuming ESM covered everything. It covered high and critical CVEs in the most used server packages in Main, on 64-bit x86. A 12.04 ARM board or 32-bit server was outside it.
• Auditing only the sudo group. Accounts in admin kept sudo rights on 12.04 for compatibility.
• Patching OpenSSL and stopping there. The Heartbleed notice asked for a reboot and for keys to be regenerated.
• Running a downloaded ISO on a live network. old-releases images are for labs and forensics.

FAQ

Is Ubuntu 12.04 still supported?

No. Standard support ended on 28 April 2017, and the paid Extended Security Maintenance for 12.04 ended in April 2019. Canonical's current release cycle and ESM pages do not list 12.04 in their support tables, and there is no Legacy add-on for it.

When did Ubuntu 12.04 reach end of life?

On 28 April 2017. The release team confirmed it that day on the ubuntu-security-announce list, after a warning sent on 15 March 2017.

What kernel does Ubuntu 12.04 use?

Linux 3.2 at release, as the Ubuntu 3.2.0-23.36 kernel based on upstream 3.2.14. From 12.04.2, point releases shipped newer hardware enablement kernels by default, ending with the 14.04 (3.13) stack in 12.04.5.

What desktop does Ubuntu 12.04 use?

Unity, with GNOME components at 3.4.1 and the new HUD for searching application menus by typing. LightDM, introduced in 11.10, is the login manager.

Was Ubuntu 12.04 the first release with ESM?

Yes, by the official record. Canonical announced "Ubuntu 12.04 ESM" on 15 March 2017, and the archived wiki Releases table lists 12.04 ESM as its earliest ESM entry, running from 28 April 2017 for 2 years to April 2019.

Why did Ubuntu 12.04 get 5 years of support on the desktop?

The 12.04 desktop notes state 5 years, where 10.04's desktop had ended after 3 years in May 2013. None of the official pages we fetched explains the reason, only the change.

Can I upgrade Ubuntu 12.04 directly to 16.04 or 24.04?

No. The upgrade path is 12.04 to 14.04, then one LTS at a time. The Ubuntu Server upgrade guide says you cannot skip releases.

Was Ubuntu 12.04 affected by Heartbleed?

Yes. 12.04 shipped OpenSSL 1.0.1. USN-2165-1 fixed it on 7 April 2014 in libssl1.0.0 version 1.0.1-4ubuntu5.12. 10.04 was not affected.

Where can I download Ubuntu 12.04 ISOs?

From old-releases.ubuntu.com/releases/12.04, which keeps all point releases with SHA256SUMS files. Use them only in an isolated environment.

Fix it without waiting for upstream

A 12.04 system has had no official fix for anything since April 2019, and the applications built on it often carry dependencies just as old. The operating system part has to be solved by moving to a supported release. The application dependencies you build and ship are a different story, and you can fix those now.

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. That is how you find every image that still carries a precise OS package, such as a 12.04 build of libssl. Safeguard does not patch a host kernel or bring 12.04 back into support; the operating system still has to move to a supported release.

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 rebuild a service off a 12.04 base, the application's own dependencies are usually just as dated, and this is the flow for bringing them up to fixed versions in the same change.

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 and appliances, 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 which of your projects still contain a component version you are tracking, for example the 12.04 OpenSSL build named in USN-2165-1, 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 how ESM grew from this 12.04 offering into Ubuntu Pro, read Ubuntu Pro and ESM history: what each release gets, and for how the support windows fit together, the Ubuntu release support lifecycle explained. The neighbouring LTS posts are 10.04 LTS Lucid Lynx, 14.04 LTS Trusty Tahr and 16.04 LTS Xenial Xerus, and the interim releases that led to 12.04 are covered in Ubuntu interim releases 10.10 to 17.10: the Unity years.

Quick check

Sources

• Ubuntu release notes: Ubuntu 12.04 LTS
• Ubuntu release notes index
• Ubuntu release notes: Ubuntu 12.10
• Ubuntu release notes: Ubuntu 11.10
• Ubuntu release notes: Ubuntu 11.04
• Ubuntu release notes: Ubuntu 10.10
• Ubuntu release notes: Ubuntu 10.04 LTS
• Ubuntu release notes: Ubuntu 14.04 LTS
• PrecisePangolin/ReleaseNotes/12.04, Ubuntu wiki (Wayback Machine copy of 26 September 2012; original now 404)
• PrecisePangolin/ReleaseNotes/UbuntuDesktop, Ubuntu wiki (Wayback Machine copy of 20 July 2012; original now 404)
• PrecisePangolin/ReleaseNotes/UbuntuServer, Ubuntu wiki (Wayback Machine copy of 13 May 2012; original now 404)
• PrecisePangolin/ReleaseNotes/ChangeSummary/12.04.5, Ubuntu wiki (Wayback Machine copy of 4 July 2017; original now 404)
• Kernel/LTSEnablementStack, Ubuntu wiki (Wayback Machine copy of 1 January 2016)
• Releases, Ubuntu wiki (Wayback Machine copy of 3 June 2019)
• Releases, Ubuntu wiki (current page)
• Ubuntu Extended Security Maintenance, ubuntu.com/esm (Wayback Machine copy of 4 March 2019)
• ubuntu-announce: Ubuntu 12.04 (Precise Pangolin) released, April 2012 archive
• ubuntu-announce: Ubuntu 12.04 ESM (Extended Security Maintenance), 15 March 2017
• ubuntu-announce: Ubuntu 12.04 (Precise Pangolin) reaches End of Life on April 28 2017
• ubuntu-announce: March 2017 archive by date
• ubuntu-security-announce: Ubuntu 12.04 End of Life reached on April 28, 2017
• Ubuntu: Release cycle
• Ubuntu: Expanded Security Maintenance
• Ubuntu: Kernel lifecycle and enablement stack
• Ubuntu security notice USN-2165-1: OpenSSL vulnerabilities
• Ubuntu CVE tracker: CVE-2014-0160
• Ubuntu Security documentation: AppArmor
• Ubuntu Security documentation: Firewall
• Ubuntu Security documentation: Default compiler and linker flags
• 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 Pro Client documentation: What does security-status do?
• Old Ubuntu releases: 12.04

Last reviewed: 23 October 2026.