Ubuntu 18.04 LTS Bionic Beaver: Release Facts, Kernel 4.15, Security

Ubuntu 18.04 LTS "Bionic Beaver" was released on 23 April 2018 with Linux kernel 4.15 and GNOME (apps at 3.28) running on X.org by default, and its standard security maintenance ended on 31 May 2023. Security fixes now come only through Ubuntu Pro: Expanded Security Maintenance (ESM) runs to May 2028 and the Legacy add-on to May 2033.

18.04 brought GNOME to an Ubuntu LTS in place of Unity, introduced the Subiquity server installer and netplan, and shipped with Spectre and Meltdown mitigations in place. This post cites Canonical's own pages for each fact, covers what changed since 16.04 LTS "Xenial Xerus", and ends with a check and upgrade walkthrough using commands from Canonical's documentation.

Key takeaways

• Released 23 April 2018, codename Bionic Beaver, per Canonical's 18.04 page. The release notes themselves do not state the day.
• Kernel 4.15 at release. Desktop installs from 18.04.2 onward ship the Hardware Enablement (HWE) kernel by default; the HWE stack ended on 5.4 with 18.04.5 in July 2020.
• GNOME instead of Unity, with GNOME apps at 3.28 and the Files app held at 3.26. X.org is the default display server; Wayland is a technical preview.
• Support: standard security maintenance ended 31 May 2023 (the release cycle page says May 2023; the release notes say April 2023). ESM to May 2028, Legacy add-on to May 2033, both through Ubuntu Pro.
• Server changes: the Subiquity installer, netplan instead of ifupdown on new installs, and chrony recommended over ntpd.
• Security defaults: PIE with immediate binding by default, Secure Boot verifying kernel modules, encrypted home replaced by full disk encryption, and ufw installed but off.
• Spectre and Meltdown: the release notes say mitigations are in place, and Ubuntu's CVE tracker lists the 18.04 linux package as "Not affected" by Meltdown (CVE-2017-5754).
• Upgrade path: 18.04 goes to 20.04 LTS only. There is no direct upgrade to 22.04 or later, and i386 machines are not offered 20.04 at all.

What are the Ubuntu 18.04 LTS release facts?

For every Ubuntu release on one page, see our Ubuntu release history hub.

What happened when: the 18.04 timeline

The dates for 18.04.2, 18.04.3, 18.04.4 and 18.04.6 are not stated on the release notes, release cycle or kernel lifecycle pages we fetched, so we list those point releases by number only.

How long is Ubuntu 18.04 LTS supported?

Three official pages give the end of standard support three slightly different ways. The 18.04 release notes say the main archive "will be supported for 5 years until April 2023." The release cycle page lists May 2023. Canonical's 18.04 page and the ESM page give the exact day: without ESM, an 18.04 machine "will not receive any security updates after 31 May 2023." We use 31 May 2023 because it is the most specific statement and matches the release cycle month.

After that date, Ubuntu Pro is the only route to security fixes:

The Ubuntu Pro page describes ESM as "10 years of vulnerability fixes for critical, high and selected medium vulnerabilities across the whole Ubuntu archive, as defined by Ubuntu Priority." Pro is free for personal use on up to five machines, or 50 for official Ubuntu Community members.

The 18.04 page names example esm-apps packages for this release: MySQL 5.7, Python 2.7, PostgreSQL 10, Ruby 2.5, Node.js 8.10, PHP 7.2 and ROS Melodic, and says OpenStack Queens is maintained until 2028. Note that the 18.04 page says the security team provides updates "for x86-64 and arm64 architectures," while its kernel table lists the supported Pro kernels as 4.15 (GA) and 5.4 (HWE) on arm64, x86-64 and s390x. If you run 18.04 on armhf, i386 or ppc64el, confirm coverage with Canonical before you rely on ESM.

Flavours had their own clocks. The release notes give 5 years for Ubuntu Desktop, Ubuntu Server and Ubuntu Core, 9 months for Ubuntu Studio, and 3 years for every other flavour. A Kubuntu, Xubuntu, Lubuntu, Ubuntu MATE, Ubuntu Budgie or Ubuntu Kylin 18.04 install lost flavour support in 2021, well before the base system did.

For background on how ESM treats Universe, see does Ubuntu patch Universe packages, and for the general choice between upgrading, extending and isolating, see end of life software: upgrade, extend, isolate or retire.

What kernel does Ubuntu 18.04 use?

18.04 shipped with Linux 4.15. The release cycle page lists 4.15 for 18.04, the kernel lifecycle page lists 18.04.0 and 18.04.1 on 4.15, and the 20.04 release notes refer to "version 4.15 released in 18.04 LTS." The 18.04 release notes on documentation.ubuntu.com do not state the GA kernel version directly, because the published page is the 18.04.6 revision.

18.04 used the HWE model. The kernel lifecycle page says "the 18.04.2 and newer point releases will ship with an updated kernel and X stack by default for the desktop," while "server installations will default to the GA kernel and provide the enablement kernel as optional." The 18.04 HWE stacks followed the rolling update model, so an HWE machine moved through newer kernels until it settled on the next LTS kernel. The release notes record two steps on that path: 18.04.3 shipped "the v5.0 based kernel," and 18.04.4 "ships with a v5.3 based Linux kernel." The kernel lifecycle page then lists 5.4 as the 18.04.5 HWE kernel from July 2020, the same 5.4 that 20.04 LTS shipped as its GA kernel.

Both kernels that remain supported under Ubuntu Pro are named on the 18.04 page: 4.15 (GA) and 5.4 (HWE). If a machine is on any other kernel, it is off the supported path.

To move a 18.04 machine onto the HWE kernel, the kernel lifecycle page gives:

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

What desktop does Ubuntu 18.04 ship?

The 18.04 release notes list these highlights since 16.04 LTS:

• "The Ubuntu Desktop now uses GNOME instead of Unity."
• GNOME apps were updated to 3.28, while the Files app (nautilus) stayed at 3.26.
• "GDM has replaced LightDM as the default display manager," and the login screen moved from virtual terminal 7 to virtual terminal 1.
• X is the default display server. Wayland is "provided as a Technical Preview and is expected to be the default display server in 20.04 LTS," available as "Ubuntu on Wayland" from the login screen.
• 32-bit installer images are no longer provided for Ubuntu Desktop.
• Calculator, Characters, Logs and System Monitor became snaps on new installs, for "better isolation".

GNOME replaces Unity on an LTS: the security relevant parts

The display server decision is the one most people ask about. 17.10 made Wayland the default "on supported systems," with "Ubuntu on Xorg" as the fallback. 18.04 LTS reversed that and made X the default again, keeping Wayland as an opt in session. The release notes do not describe this as a security decision; they frame it around readiness. They do record a Wayland limitation that touches privilege handling: "Some admin utilities will not work with GNOME on Wayland since the apps have not been adapted to use PolicyKit to only use admin privileges for the specific functions needed." Screenshot, screencast and all remote desktop server apps also did not work on GNOME on Wayland at the time.

For an operator: an 18.04 desktop runs the X session unless a user chose otherwise at login, snapped utilities update on their own channels rather than with the 18.04 archive, and X.org logs moved to ~/.local/share/xorg.

What changed for server builds: Subiquity and netplan

The Subiquity installer

Current practice lives in the Ubuntu Server documentation. For 18.04, the release notes call Subiquity "the next generation" server installer, bringing "the comfortable live session and speedy install of Ubuntu Desktop to server users." It was not feature complete at release, and the notes are frank about that:

• If you needed multipath, you had to keep using the alternate installer image from cdimage.ubuntu.com.
• LVM, RAID, VLANs and bonds were added in 18.04.1.
• 18.04.3 added encrypted LVM volume groups and reuse of existing partitions, and made the installer check for a newer version of its own snap at startup.
• A known issue at release: importing SSH keys from GitHub or Launchpad during installation did not work.
• A server known issue fixed in 18.04.2: only the "main" component was enabled after install.

So a server installed from an earlier Subiquity image could only have got encrypted LVM through the alternate installer.

netplan, systemd-networkd and systemd-resolved

On new installs, "ifupdown has been deprecated in favor of netplan.io and is no longer present." The installer writes a YAML file into /etc/netplan, and netplan renders it into systemd-networkd configuration on servers and NetworkManager on desktops. This only applies to new installations, so a 16.04 server upgraded to 18.04 kept ifupdown. Other consequences listed in the notes:

• ifup and ifdown are not available on new installs; the notes point to ip link set instead.
• networkctl gives a summary of network devices.
• Scripts in /etc/network/ifup.d and /etc/network/ifdown.d stop working; equivalents go under networkd-dispatcher directories.
• "The default DNS resolver is systemd-resolved."

Other server changes that affect security work

• Time sync: chrony "will replace ntpd as the recommended server for the NTP protocol," and ntpd was "demoted from main to universe," which means it "will only receive best-effort security maintenance." That was a security relevant change: on 18.04, ntpd in Universe was outside the free five year commitment.
• LXD 3.0, with clustering.
• QEMU 2.11.1, which includes Meltdown and Spectre related fixes.
• OpenSSL: the default moved from 1.1.0 to the 1.1.1 LTS series, with TLS 1.3 available in select packages, and 1.0.2n remained co-installable.
• Apache 2.4.29 with HTTP/2 enabled, nginx 1.14.0, PHP 7.2.
• ubuntu-advantage-tools gained an enable-fips-updates command.

How did 18.04 handle Spectre and Meltdown?

18.04 was the first Ubuntu release to ship after the Spectre and Meltdown disclosures, and its release notes state plainly: "Mitigations are in place to protect against Spectre and Meltdown." They point to a Security Team knowledge base article on the old wiki. That wiki page, and the ubuntu.com/security/spectre-and-meltdown page, both returned 404 when we checked on 23 October 2026, so we describe the mitigations only from the pages that still resolve.

Ubuntu's CVE tracker entry for CVE-2017-5754, Meltdown, gives the clearest picture. It was published on 3 January 2018, carries an Ubuntu priority of Critical, and is described by the Ubuntu Security Team as a flaw where "a local attacker could use this to expose sensitive information, including kernel memory." For the linux package, the tracker lists:

Older releases needed updated kernels, while the 18.04 kernel is listed as not affected, which fits the release notes' statement that mitigations were in place at release.

Two more items belong here. QEMU 2.11.1 included Meltdown and Spectre fixes, with the note that "fully utilizing these mitigations needs more than just an upgrade," and the notes recommend upgrading guest machine types after a QEMU upgrade. And four years later the speculative execution story continued: on 8 March 2022, Canonical's security team disabled unprivileged eBPF by default on the 4.15 and 5.4 kernels to mitigate Branch Target Injection and Branch History Injection. The announcement says the only known way to perform those attacks was for unprivileged users to load their own code gadgets into the kernel as eBPF. Newer releases (21.10 and later) already had that default.

On an 18.04 host that is still running, the useful check is that the kernel is a current 4.15 or 5.4 build from the security pocket or ESM, which Step 2 of the walkthrough below covers.

Minimal install, data collection and privacy defaults

The 18.04 release notes add a desktop installer option: "a minimal install option for a basic desktop environment with a web browser and core system utilities." Fewer packages means fewer to patch, which matters more now that Universe fixes need Pro.

On data collection: the 18.04 release notes published on documentation.ubuntu.com do not mention a system information report, the ubuntu-report tool, or an opt in data collection step. We could not confirm the details of 18.04's data collection prompt from the official sources in our list, so we do not describe it here.

Privacy and security related defaults that the notes do state:

• Computers suspend after 20 minutes of inactivity on battery power, even if a user is logged in remotely (a listed known issue).
• The encrypted home option using ecryptfs-utils is gone from the installer; full disk encryption is recommended instead.
• bolt and thunderbolt-tools were promoted to main "to provide security controls for Thunderbolt devices," and GNOME Shell supports Thunderbolt 3.

What are the security defaults in Ubuntu 18.04 LTS?

Compiler hardening: PIE and immediate binding

From the release notes: "gcc is now set to default to compile applications as position independent executables (PIE) as well as with immediate binding, to make more effective use of Address Space Layout Randomization (ASLR). All packages in main have been rebuilt to take advantage of this, with a few exceptions." The Ubuntu Security compiler flags page gives the history: PIE became the default on amd64, ppc64el and s390x in 16.10, and across all architectures from 17.10. BIND_NOW marks ELF programs to resolve all dynamic symbols at start up, which allows the Global Offset Table to be made read only when combined with RELRO. 18.04 is the first LTS where both are on by default.

Secure Boot: kernel modules now verified

The Ubuntu Security Secure Boot page says Secure Boot arrived in 12.04 with an enforcing bootloader but a non-enforcing kernel, and that "starting with Ubuntu 18.04 LTS (Bionic Beaver), Secure Boot verifies all critical components: bootloader, kernel, and kernel modules." The release notes describe the matching change for third party modules: when you install a DKMS package, you are prompted for a password used to enrol a signing key (an X509 certificate) that then signs the new kernel modules, and you confirm the key at the next reboot. On amd64 the shim is signed by Microsoft and GRUB by Canonical; arm64 shim and GRUB signing came later, in 20.04.

AppArmor 2.12

The Ubuntu Security AppArmor page lists AppArmor 2.12 for 18.04, up from 2.10.95 in 16.04 and 14.04. The 18.04 notes mention "further AppArmor and security module improvements" in the kernel. Profile stacking, which lets containers load their own profiles, had arrived in 16.10. For working with profiles day to day, see AppArmor complain or enforce on Ubuntu dev machines.

Firewall: ufw installed, off

The Ubuntu Security firewall page lists ufw 0.36-0ubuntu0.18.04.1, iptables 1.6.1-2ubuntu2.1 and nftables 0.8.2-1 for 18.04, and says ufw "is available in Ubuntu, but disabled by default." That was true on 18.04 and is still true today, so an 18.04 server with no other firewall has no host packet filtering unless someone enabled it. See ufw first steps.

Disk encryption

The installer "no longer offers the encrypted home option using ecryptfs-utils. It is recommended to use full-disk encryption instead for this release." On the server side, Subiquity only gained encrypted LVM in 18.04.3, as covered above. TPM-backed full disk encryption is not mentioned anywhere in the 18.04 notes.

SSH, SMB and cryptography defaults

• OpenSSH "now refuses to use RSA keys smaller than 1024 bits." The notes give ssh-keygen -l -f /path/to/key.pub to report a key's length.
• Since 17.10, mount.cifs negotiates SMB 2.1 or later by default instead of SMB1. Specifying vers=1.0 brings back the less secure dialect; the notes describe it that way.

Updates: unattended-upgrades and Livepatch

The Ubuntu Server automatic updates guide says security updates are applied automatically "via the unattended-upgrades package, which is installed by default," including ESM when it is available, once a day by default. Canonical's 18.04 page describes the release as "introducing improved UEFI Secure Boot, broader Kernel Livepatch coverage." The release notes add a dynamic MOTD for Livepatch status and fix a Livepatch notification ordering bug in 18.04.2. Livepatch patches high and critical kernel vulnerabilities in memory; reboots remain the safest rollback path. See what Livepatch fixes and what still needs a reboot and unattended upgrades: enable and reboot settings.

Python 2 removed from the default install

"Python 2 is no longer installed by default. Python 3 has been updated to 3.6. This is the last LTS release to include Python 2 in main." Python 2.7 is one of the application packages the 18.04 page lists under esm-apps, which tells you where long lived 18.04 workloads still depend on it.

What changed from Ubuntu 16.04 LTS to 18.04 LTS?

The 18.04 release notes cover changes since 16.04 and point to the 16.10, 17.04 and 17.10 notes for the rest.

The three interim releases in between

• 16.10 Yakkety Yak (supported until July 2017): kernel 4.8, systemd for user sessions, AppArmor profile stacking so LXD containers can load their own profiles, and PIE by default on amd64 and ppc64el.
• 17.04 Zesty Zapus (supported until January 2018): kernel 4.10, swap files instead of swap partitions on new installs, driverless printing, GNOME apps at 3.24, Unity 8 as an alternative session, and the 32-bit PowerPC port dropped.
• 17.10 Artful Aardvark (supported until July 2018): kernel 4.13, GNOME instead of Unity, Wayland as the default display server on supported systems, GDM instead of LightDM, netplan replacing ifupdown on new installs, no 32-bit desktop images, and the Ubuntu GNOME flavour discontinued. 17.10 also shipped with a kernel bug that could leave some laptops unable to change BIOS settings; the release notes warned users with affected systems not to boot the 17.10 installer until it was fixed.

Most of what 16.04 users noticed in 18.04 arrived first in 17.10; the display server default is the one reversal.

Which architectures does 18.04 support?

The release cycle page lists amd64, i386, armhf, arm64, s390x and ppc64el (POWER8) for 18.04. The release notes say "the powerpc port is not included in the 18.04 release" while ppc64el continues. i386 remained as an architecture, but without 32-bit desktop installer images. The 20.04 release notes add the consequence: "Users of the i386 architecture will not be presented with an upgrade to Ubuntu 20.04 LTS," because i386 as a host architecture was dropped in 19.10. An i386 18.04 machine has no in place upgrade path at all.

On Raspberry Pi, the Pi 4B became supported in 18.04.4 and the 8GB Pi 4 in 18.04.5.

How do you check and upgrade an Ubuntu 18.04 system?

These steps use only commands from Canonical's documentation. Steps 1 to 5 read state and change nothing.

Step 1: Confirm the release

The Ubuntu Desktop docs use this command to show the installed release:

lsb_release --description

On an 18.04 machine the description names Ubuntu 18.04 and the point release level the machine has reached through updates. In a container image, the same information is in /etc/os-release, which is what most SBOM tools read; our guide to checking whether a base image OS is end of life covers that case.

Step 2: Check the kernel and HWE status

The 18.04 release notes use uname -r to verify the running kernel version. The kernel lifecycle page gives the HWE support check:

uname -r
hwe-support-status --verbose

A 4.15 kernel means the GA stack; 5.4 means the final HWE stack. Anything else on 18.04 is not one of the two kernels Ubuntu Pro supports for this release.

Step 3: Check Ubuntu Pro and ESM coverage

The Pro Client docs explain pro security-status, and the status columns explainer covers pro status:

sudo apt-get update
pro status
pro status --all
pro security-status

On an 18.04 machine without Pro, the docs show the message you should expect: "This machine is NOT receiving security patches because the LTS period has ended and esm-infra is not enabled." To attach a machine, the attach guide uses:

sudo pro attach

Look at the "packages from third parties" and "no longer available for download" counts in pro security-status. Ubuntu will not patch those for you on any release.

Step 4: Check the unprivileged eBPF default

From the Ubuntu Security Discourse announcement:

sysctl kernel.unprivileged_bpf_disabled

A value of 1 or 2 means unprivileged eBPF is disabled. A value of 0 means either the kernel predates the March 2022 updates or someone re-enabled it.

Step 5: Check network configuration and legacy settings

From the 18.04 release notes:

networkctl status
ssh-keygen -l -f /path/to/key.pub

networkctl status shows whether systemd-networkd manages the interfaces (new 18.04 installs) or not (servers upgraded from 16.04 keep ifupdown). ssh-keygen -l reports key lengths, so you can find RSA keys OpenSSH will reject.

Step 6: Bring the system fully up to date

The Ubuntu Server upgrade guide says the release upgrade "requires that the current system has all the latest updates installed":

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

Then reboot if the file /run/reboot-required exists. Make sure there is enough free disk space, back up your data, and expect third party repositories and PPAs to be disabled during the upgrade.

Step 7: Upgrade to 20.04 LTS

The 18.04 release notes and the 20.04 release notes give the server procedure: install update-manager-core if needed, set the Prompt line in /etc/update-manager/release-upgrades to lts, then run:

sudo do-release-upgrade

The server upgrade runs inside GNU screen and re-attaches if the connection drops. There are no offline upgrade options. On a desktop, the notes use the "Software & Updates" setting to choose "For long-term support versions" and then run update-manager -c.

Before you start, check the points that matter specifically for 18.04:

• One hop at a time. The server guide says "you cannot skip releases." Canonical's 18.04 page says "there is no direct upgrade path from 18.04 LTS to Ubuntu 22.04 LTS." Getting to 24.04 or 26.04 in place means 18.04 to 20.04 to 22.04 to 24.04, and on to 26.04 if needed.
• The first hop lands on another ESM release. 20.04's standard support ended in May 2025, so a machine upgraded only to 20.04 still needs Pro. See is Ubuntu 20.04 end of life.
• i386 cannot upgrade. Reinstall on a 64-bit release.
• Python. On upgraded systems /usr/bin/python keeps pointing to Python 2 for compatibility, and the legacy python packages may be replaced by python2 packages, per the 20.04 notes.
• libvirt and QEMU. The 20.04 notes list separate upgrade sections "from 18.04" for QEMU and libvirt, including upgrading machine types.
• Configuration prompts. The upgrader asks about every configuration file you changed. The default keeps your version; read the diff first.

For many 18.04 servers, a fresh install on a current LTS is simpler than three or four in place upgrades; the 18.04 page offers redeploying onto a fresh install as one of its two options.

Who should stay on 18.04 with Pro, and who should move?

Stay on 18.04 under Ubuntu Pro only when a workload is tied to something you cannot change quickly, such as a vendor driver built for 4.15 or 5.4, an OpenStack Queens deployment, or an application stuck on Python 2.7 or PHP 7.2. Use the time to plan the move: ESM ends in May 2028.

Move now if the machine is internet facing, runs Universe packages you have not checked against esm-apps, uses a flavour (whose support ended in 2021), or is i386. Container images built on an 18.04 base should be rebuilt on a supported base regardless; the base layer is the easy part of the change. Our base image support dates side by side and Docker Ubuntu image posts cover the container view.

How to spot 18.04 in an SBOM

In a container SBOM, the clues are an OS release file reporting 18.04 and bionic, package versions with an 18.04 suffix (the firewall page shows the pattern with ufw 0.36-0ubuntu0.18.04.1), and archive runtimes such as Python 3.6 or PHP 7.2. Our explainers on Ubuntu CVE statuses in a container scan and checking a distro backported fix cover how to read what a scanner reports.

Common mistakes

• Assuming 18.04 is "still LTS, so still patched." Standard maintenance ended on 31 May 2023. Without Pro, the machine gets no security updates at all.
• Enabling esm-infra and forgetting esm-apps. esm-infra covers Main. Universe packages, including many language runtimes and libraries, need esm-apps.
• Running a flavour and reading the base dates. Kubuntu, Xubuntu, Lubuntu, Ubuntu MATE, Ubuntu Budgie and Ubuntu Kylin 18.04 had 3 years; Ubuntu Studio had 9 months.
• Trying to jump straight to 22.04 or 24.04. There is no direct path. Go through 20.04, or reinstall.
• Leaving ntpd in place after the upgrade from 16.04. On 18.04 it lives in Universe with best effort security maintenance; chrony or systemd-timesyncd is the recommended path.
• Assuming the firewall is on. ufw is installed but disabled by default.
• Running a kernel that is neither 4.15 nor 5.4. Pro supports only those two kernels for 18.04.
• Forgetting the containers. Patching hosts does nothing for 18.04 based images already running in production. Rebuild them.

FAQ

Is Ubuntu 18.04 still supported?

Only through Ubuntu Pro. Standard security maintenance ended on 31 May 2023. With Pro, ESM continues to May 2028 and the Legacy add-on to May 2033, per the release cycle page.

When was Ubuntu 18.04 released?

On 23 April 2018, according to Canonical's 18.04 page. The release cycle page lists "Apr 2018."

What kernel does Ubuntu 18.04 use?

Linux 4.15 at release. Desktop installs from 18.04.2 track the HWE kernel, which went through 5.0 and 5.3 and ended on 5.4 with 18.04.5 in July 2020. Ubuntu Pro supports 4.15 (GA) and 5.4 (HWE).

What desktop does Ubuntu 18.04 use?

GNOME, with apps at 3.28 and GDM as the display manager, on X.org by default. Wayland was a technical preview. 18.04 is the first LTS to use GNOME instead of Unity.

Can I upgrade Ubuntu 18.04 directly to 22.04 or 24.04?

No. The server upgrade guide says you can only move to the next sequential LTS, and Canonical's 18.04 page says there is no direct upgrade path to 22.04. Upgrade to 20.04 first, or install the newer release fresh.

Was Ubuntu 18.04 affected by Meltdown?

Ubuntu's CVE tracker lists the 18.04 linux package as "Not affected" by CVE-2017-5754, and the release notes say Spectre and Meltdown mitigations are in place. Older releases needed updated kernels.

Does Ubuntu 18.04 use netplan?

Yes, on new installs. ifupdown is no longer installed by default, and netplan renders configuration for systemd-networkd on servers and NetworkManager on desktops. Systems upgraded from 16.04 keep ifupdown.

Does Ubuntu 18.04 have a firewall enabled by default?

No. ufw 0.36 is installed but disabled by default, per the Ubuntu Security firewall documentation.

Fix it without waiting for upstream

On 18.04 the gap is concrete. Without Ubuntu Pro, nothing on the machine has received a security update since 31 May 2023, and even with Pro the application runtimes and libraries you bundle into your own builds (a Node.js app's npm tree, a Python service's wheels, a Java service's jars) are yours to keep patched, whatever the base OS does.

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 an image still built on an 18.04 base shows which OS packages and versions it carries next to your 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 that still starts from bionic. Safeguard does not patch the host kernel or the Ubuntu archive for you; on 18.04 that stays with Canonical's ESM and Livepatch.

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 an 18.04 base usually means bumping its own dependencies too, and this is that flow.

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. Running it on a build host lets you scan the images in your registry that still use an 18.04 base without sending them off your network. 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 given package version, for example an OpenSSL 1.1.1 or Python 3.6 build from the bionic archive, 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.

Quick check

Sources

• Ubuntu release notes: Ubuntu 18.04 LTS
• Ubuntu release notes: Ubuntu 17.10
• Ubuntu release notes: Ubuntu 17.04
• Ubuntu release notes: Ubuntu 16.10
• Ubuntu release notes: Ubuntu 16.04 LTS
• Ubuntu release notes: Ubuntu 20.04 LTS
• Ubuntu: Release cycle
• Ubuntu: Ubuntu 18.04 LTS (Bionic Beaver)
• Ubuntu: Expanded Security Maintenance
• Ubuntu: Ubuntu Pro
• Ubuntu: Kernel lifecycle and enablement stack
• Ubuntu: Livepatch
• Ubuntu CVE tracker: CVE-2017-5754
• Ubuntu Discourse: Unprivileged eBPF disabled by default for Ubuntu 20.04 LTS, 18.04 LTS, 16.04 ESM
• Ubuntu Server documentation
• Ubuntu Server documentation: How to upgrade your Ubuntu release
• Ubuntu Server documentation: Automatic updates
• Ubuntu Security documentation: Default compiler and linker flags
• Ubuntu Security documentation: UEFI Secure Boot
• Ubuntu Security documentation: AppArmor
• Ubuntu Security documentation: Firewall
• 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 Client documentation: How to attach a machine

Last reviewed: 23 October 2026.