Amazon Linux Patch Management & CVE Tracking

Amazon Linux spans three very different generations in production AWS accounts today: legacy Amazon Linux 1 (EOL since December 2023), Amazon Linux 2 (yum-based, approaching its June 30, 2026 end-of-support deadline), and Amazon Linux 2023 (dnf-based, with deterministic versioned repositories). Treating all three the same in your automation scripts is one of the fastest ways to leave EC2 instances silently unpatched.

In particular, Amazon Linux 2023 (AL2023) locks every instance to the exact repository snapshot (releasever) that shipped with its AMI. Running a plain dnf upgrade on an AL2023 host that launched four months ago will report “Nothing to do” even when dozens of newer ALAS2023 security advisories have been published in later repository releases.

This guide walks through the exact commands for patching AL2023 and AL2, how deterministic releasever pinning works, kernel live patching on EC2, migrating off AL2 before EOL, and how Amazon Linux fits into a cross-distro Linux patch management workflow alongside Ubuntu and RHEL. For teams planning their AL2 exit, see Amazon Linux 2 EOL: your patching and migration options.

Patching by Amazon Linux generation

Patching Amazon Linux 2023: dnf and Deterministic releasever

Amazon Linux 2023 introduced versioned repositories to prevent unexpected package drift when auto-scaling groups launch new instances or run dnf at different times. Every repository snapshot has a version string such as 2023.5.20240819, stored in /etc/dnf/vars/releasever.

Because dnf only queries the repository version pinned on the host, patching AL2023 requires checking for newer release snapshots and advancing --releasever deliberately:

# 1. Check the currently pinned releasever and whether newer snapshots exist
cat /etc/dnf/vars/releasever
sudo dnf check-release-update

# 2. List security advisories (ALAS2023) available in the latest repository release
sudo dnf updateinfo list --security --releasever=latest

# 3. Apply security updates from the latest repository snapshot
sudo dnf upgrade --security --releasever=latest -y

# 4. Apply all updates and advance the host to a specific releasever (or latest)
sudo dnf upgrade --releasever=latest -y

# 5. Persist the new releasever so subsequent dnf runs use it by default
echo "2023.6.20241010" | sudo tee /etc/dnf/vars/releasever

# 6. Check whether a reboot or service restart is needed
sudo dnf needs-restarting -r
sudo dnf needs-restarting -s

If your team runs sudo dnf upgrade --security -y without --releasever=latest (and without updating /etc/dnf/vars/releasever), dnf checks only the frozen snapshot from the day the AMI was built — meaning zero new ALAS2023 advisories will ever be installed. That design is great for repeatable builds in staging vs. production, provided your patching automation explicitly manages releasever.

Patching Amazon Linux 2 with yum

Amazon Linux 2 (AL2) follows the traditional rolling-repository model derived from RHEL 7. All security advisories (ALAS2-*) are published into the main amzn2-core repository and any enabled amazon-linux-extras topics:

# 1. Refresh metadata and summarize pending ALAS2 advisories
sudo yum clean expire-cache
sudo yum updateinfo summary
sudo yum updateinfo list security

# 2. Apply all security advisories
sudo yum update --security -y

# 3. Apply a single CVE or ALAS advisory
sudo yum update --cve CVE-2026-12345 -y
sudo yum update --advisory ALAS2-2026-2500 -y

# 4. Check whether the kernel or core libraries require a reboot
sudo needs-restarting -r
sudo needs-restarting -s

Keep in mind that packages installed from amazon-linux-extras (such as PostgreSQL, Redis, Docker, or Nginx) live in separate topic repositories (amzn2extra-*). Always verify yum repolist on AL2 hosts to confirm that every active extras topic is enabled when scanning for updates.

Amazon Linux 2 End of Life: What Changes in 2026

AWS extended Amazon Linux 2 standard support to June 30, 2026. As that cutoff approaches:

• No in-place upgrade to AL2023: AWS does not support an in-place yum/dnf upgrade from AL2 to AL2023 because the underlying userland (glibc, OpenSSL 3, Python, systemd, and SELinux policy defaults) changed substantially. Migration means launching AL2023 AMIs or rebuilding golden images in EC2 Image Builder / Packer.
• Kernel and OpenSSL divergence: AL2 runs Linux 4.14 or 5.10 with OpenSSL 1.0.2/1.1.1, while AL2023 runs Linux 6.1+ with OpenSSL 3.0 and crypto-policies enforcing modern TLS and SSH host-key algorithms by default (for example, legacy ssh-rsa SHA-1 signatures are disabled out of the box).
• Cron is not installed by default on AL2023: AL2023 replaces default cronie jobs with systemd timers. Any legacy patching script that drops a file into /etc/cron.daily/ on an AL2023 instance will never execute unless cronie is explicitly installed and enabled.

During the transition period when your account runs both AL2 and AL2023 instances side by side, keeping both generations in a single Linux vulnerability management inventory ensures lingering AL2 nodes do not miss critical ALAS2 patches while the migration is underway.

Kernel Live Patching and Reboot Management on EC2

Both AL2 (on x86_64 with kernel 4.14 or 5.10) and AL2023 support AWS Kernel Live Patching based on kpatch. Live patches fix critical and important CVEs in the running kernel without rebooting the EC2 instance:

# On Amazon Linux 2023
sudo dnf install -y kpatch-dnf kpatch-runtime
sudo dnf kpatch auto
sudo dnf upgrade --security --releasever=latest -y
sudo kpatch list

# On Amazon Linux 2
sudo yum install -y yum-plugin-kernel-livepatch kpatch-runtime
sudo yum kernel-livepatch enable -y
sudo systemctl enable --now kpatch.service
sudo yum update --security -y

Live patches for a specific kernel build are supported for three months after release, giving teams time to schedule a full maintenance window and reboot into the newest kernel package.

AWS Systems Manager Patch Manager vs Cross-Distro Fleet Tools

AWS Systems Manager (SSM) Patch Manager is the native AWS option for EC2 instances. When every server you own runs inside one AWS organization with SSM Agent, IAM roles, and VPC endpoints properly wired, SSM Patch Manager handles baseline scanning and maintenance windows well.

Teams look beyond SSM Patch Manager when:

1. The fleet spans more than EC2: You also run Ubuntu, Debian, RHEL, or Rocky Linux on-premises, in colocation, or on another cloud provider, and do not want two separate patch consoles and two sets of compliance reports.
2. Per-distro patch baselines become unwieldy: Maintaining separate SSM Patch Baselines, Patch Groups, and S3 output logs for Amazon Linux 2023, Amazon Linux 2, Ubuntu 24.04, and Rocky 9 adds significant Terraform/IAM boilerplate.
3. You want direct package-to-CVE visibility: Rather than digging through SSM compliance summaries to find out which hosts still carry a vulnerable openssh or libcurl build, you need an immediate cross-host package and CVE query.

For a broader comparison of cloud-native, open-source, and commercial options, see the 10 best Linux patch management tools in 2026.

How SysWard Manages Amazon Linux Fleets

SysWard treats Amazon Linux 2 and Amazon Linux 2023 as first-class citizens alongside the rest of your Linux estate:

• Live ALAS and NVD CVE matching: The SysWard agent inventories installed RPM packages on every AL2 and AL2023 instance and matches them against distribution security feeds and NVD data so you see exploitable CVEs by host and severity.
• Grouped rollouts across clouds: Group EC2 instances with on-premises or multi-cloud servers (staging, prod-us-east, batch-workers), schedule maintenance windows, and hold specific packages when needed.
• Reboot tracking and audit trails: Dashboard flags show which instances require a reboot (needs-restarting -r), and every patch run logs the user, timestamp, and before/after package versions for SOC 2, PCI DSS, and HIPAA compliance.

Evaluate SysWard on up to 5 servers for free — start free, no credit card required, or deploy the self-hosted appliance inside your VPC.