Remediation Guides

CentOS 7 End of Life: How to Fix the CentOS SEoL (7.x) Finding

26 September 2026 8 min read

CentOS SEoL (7.x) is a Nessus finding that means the host runs CentOS Linux 7, which reached end of life on June 30, 2024 and gets no more security updates. The fix is to leave CentOS 7: upgrade in place to AlmaLinux with ELevate, convert to RHEL with Convert2RHEL and Leapp, or rebuild on a supported distribution.

What the scanner is actually detecting

This is not a single vulnerability and it carries no CVE. Nessus reads the operating system version and reports that the release is past its security end of life (SEoL). Tenable publishes one SEoL plugin per CentOS major release:

Nessus plugin Finding title Risk factor listed by Tenable
201425 CentOS SEoL (7.x) Low (no CVSS score)
201354 CentOS SEoL (8.x) Critical (CVSS 10.0)
201343 CentOS SEoL (6.x) Critical (CVSS 10.0)

All three are in the General family, were published on July 3, 2024, and run in both Nessus and Nessus Agent. Plugin 201425 records an SEoL date of 2024-06-30 and depends on Nessus OS identification (os_fingerprint.nasl) and SSH information gathering (ssh_get_info2.nasl). Tenable’s solution text simply says to move to a supported CentOS version, which in practice means leaving CentOS Linux entirely, because every CentOS Linux release is now end of life.

Do not read the Low rating as “safe to defer”. Tenable has said that new SEoL plugins default to Low severity to limit disruption. The rating describes the plugin, not the unpatched vulnerabilities accumulating underneath it.

Real-world risk

The CentOS Project stated that no updates would be published for CentOS Linux 7 after June 30, 2024, and that packages would be archived on vault.centos.org. The vault is a frozen archive: nothing in it will ever receive a security fix. In practice that means:

  • Any flaw disclosed after that date in the kernel, glibc, OpenSSL, OpenSSH or any other base package stays open on a stock CentOS 7 host.
  • A quiet scan report is not evidence of safety. CentOS no longer publishes advisories, so advisory-based local checks have little new to compare against.
  • Routine maintenance degrades. The stock mirrors are offline, so yum fails against the default repository files, and third-party vendors are dropping EL7 builds.

The finding is not directly exploitable. Prioritize by exposure: internet-facing servers, multi-user systems and hosts running network services come first, while an isolated internal box with no inbound access is lower urgency but still needs a dated plan.

How to confirm it on the host

cat /etc/centos-release
cat /etc/os-release
rpm -q centos-release
uname -r

A CentOS 7 host shows a release string such as CentOS Linux release 7.9.2009 (Core), ID="centos" with VERSION_ID="7", and a kernel ending in .el7.x86_64. Then check where the host gets packages from:

yum repolist all
grep -rE '^(mirrorlist|baseurl)' /etc/yum.repos.d/

This tells you whether the host points at dead mirrors, the frozen vault, or a paid extended-support repository. Also check whether the box is a vendor appliance built on CentOS 7. If it is, the finding is accurate but the fix is the vendor’s supported release, not your own upgrade.

How to fix it

Before any of the options below, take a full backup or VM snapshot, list the applications and third-party repositories on the host, and rehearse on a clone. In-place upgrades are one major version at a time, so CentOS 7 to an EL9 system is two upgrades.

Option 1: upgrade in place to AlmaLinux with ELevate

ELevate is the AlmaLinux-led project that packages Leapp with upgrade data for RHEL-based distributions. The path is CentOS 7 to AlmaLinux 8, then AlmaLinux 8 to 9. Because the CentOS 7 mirrors are offline, the AlmaLinux guide first points yum at its CentOS 7 mirror:

sudo curl -o /etc/yum.repos.d/CentOS-Base.repo https://el7.repo.almalinux.org/centos/CentOS-Base.repo
sudo yum upgrade -y
sudo reboot

sudo yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm
sudo yum install -y leapp-upgrade leapp-data-almalinux
sudo leapp preupgrade

The first preupgrade run is expected to fail. Read /var/log/leapp/leapp-report.txt and clear every inhibitor. The common ones on CentOS 7 are:

  • pata_acpi loaded: sudo rmmod pata_acpi
  • PermitRootLogin not set: EL8 changes the default to prohibit-password. The AlmaLinux guide appends PermitRootLogin yes, but the Leapp hint accepts any explicit value, so add PermitRootLogin prohibit-password (or no) to /etc/ssh/sshd_config, outside any Match block.
  • pam_pkcs11 removal: if you do not use smart card login, confirm it with sudo leapp answer --section remove_pam_pkcs11_module_check.confirm=True
sudo leapp upgrade
sudo reboot

The host boots into a GRUB entry named ELevate-Upgrade-Initramfs and performs the upgrade there, so have console access. For the second hop, the AlmaLinux guide says to remove leftover el7 packages, delete the exclude= entries that mention leapp or elevate in /etc/yum.conf and /etc/dnf/dnf.conf, then repeat the same install, preupgrade and upgrade steps on AlmaLinux 8.

Two cautions. ELevate dropped Rocky Linux as a target in its 2025-11-03 update, so older guides using leapp-data-rocky are out of date; if your standard is Rocky, use Option 3. ELevate also still lists CentOS Stream 8 as a target, but CentOS Stream 8 builds ended on May 31, 2024, so it only swaps one end-of-life release for another.

Option 2: convert to RHEL with Convert2RHEL, then upgrade with Leapp

Red Hat supports converting CentOS Linux 7.9 to RHEL 7.9 with a Red Hat subscription. Fully update and reboot the host first, and disable any custom repositories that provide RHEL packages.

sudo curl -o /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release https://security.access.redhat.com/data/fd431d51.txt
sudo curl -o /etc/yum.repos.d/convert2rhel.repo https://cdn-public.redhat.com/content/public/repofiles/convert2rhel-for-rhel-7-x86_64.repo
sudo yum -y install convert2rhel
sudo convert2rhel analyze
sudo convert2rhel --org <organization_ID> --activationkey <activation_key>
sudo reboot

If you will stay on RHEL 7 for a while, Red Hat says to buy the Extended Life Cycle Support (ELS) add-on and pass --els to both commands. If you upgrade to RHEL 8 immediately, ELS is not required. The upgrade from RHEL 7.9 to RHEL 8.10, per the Red Hat upgrade guide:

sudo subscription-manager repos --enable rhel-7-server-extras-rpms
sudo yum install leapp-upgrade
sudo leapp preupgrade --target 8.10
sudo leapp upgrade --target 8.10
sudo reboot

Option 3: rebuild and redeploy

For hosts with many third-party packages, custom kernel modules or two major versions to cross, a clean build is often the lower-risk path. Install a supported release (AlmaLinux, Rocky Linux or RHEL 9 or later, or another supported distribution), rebuild the configuration, migrate data, cut over, then decommission the old host. The CentOS 7 machine stays intact until cutover, which doubles as your rollback.

If you cannot migrate yet

Paid extended support, such as RHEL 7 ELS after conversion, keeps fixes flowing but only buys time. Restrict network exposure, record an owner and an expiry date, and handle the host through a formal vulnerability risk acceptance process rather than leaving the finding open indefinitely.

How to verify the fix and rescan

cat /etc/redhat-release
cat /etc/os-release
uname -r
rpm -qa | grep el7
sudo dnf check-update
  1. The release files should show AlmaLinux or Red Hat Enterprise Linux 8 or 9, and the kernel should end in el8 or el9.
  2. rpm -qa | grep el7 should return nothing, or only leftovers you plan to remove. Review /var/log/leapp/leapp-report.txt and /var/log/leapp/leapp-upgrade.log.
  3. dnf check-update should reach live repositories without errors.
  4. Rerun a credentialed Nessus scan. Plugin 201425 should no longer report, and Nessus Scan Information should show credentialed checks as successful.

Expect new findings on the migrated host: advisory-based checks for the new OS now have something to compare against. Some may be version comparisons that ignore backported fixes; see why backported patches trigger false positives. If you stopped at EL8, plan the hop to EL9, since EL8 has a shorter remaining lifecycle.

What can break and how to roll back

A Leapp in-place upgrade has no undo command. Rollback means restoring the backup or snapshot, and Red Hat warns that LVM snapshots are not full backups and may not recover every failure. Convert2RHEL can roll back its own changes only until its point of no return. Write the restore procedure down before you start; our patch rollback plan guide covers the structure.

Common breakage after moving from EL7:

  • Python 2 scripts: EL8 has no unversioned python command by default.
  • Time sync: ntpd is gone; EL8 uses chrony.
  • Networking: legacy network-scripts are deprecated in EL8, and the EL9 upgrade flags ifcfg files for device types NetworkManager does not support.
  • Third-party software: repositories, agents and kernel modules without EL8 or EL9 builds.
  • Remote access: the SSH root login default and stricter system-wide crypto policies can lock out old clients or scripts.

Common false positive reasons

  • Stale results: the report predates the migration, or the rescan ran without working credentials.
  • OS guessed, not read: the plugin relies on Nessus OS identification. If SSH login failed, check the OS Identification output for how the OS was determined, then confirm with /etc/os-release.
  • Reused IP address: the address now belongs to a rebuilt host, but the asset record still carries old results.

Some findings look false but are not. A host on paid extended support is still CentOS 7, so it is still reported. A vendor appliance built on CentOS 7 is accurately reported too. Both are risk exceptions to document, not false positives.

FAQ

Is CentOS 7 still getting security updates?

Not from the CentOS Project. Nothing has been published since June 30, 2024, and the vault archive is frozen. Only paid extended-support offerings still ship fixes.

Can I upgrade CentOS 7 straight to AlmaLinux 9?

No. Leapp performs one major version per run, so the path is CentOS 7 to AlmaLinux 8, then AlmaLinux 8 to 9.

Why does Nessus rate this finding Low?

Tenable sets new SEoL plugins to Low by default. The 6.x and 8.x plugins are currently listed as Critical. Prioritize by exposure, not by the plugin rating.

Can I still use ELevate to move to Rocky Linux?

No. The ELevate project stopped supporting Rocky Linux targets in its 2025-11-03 update.

Tracking this finding across many hosts

End of life is usually a fleet problem that takes months of staged migrations. SITEY, a self-hosted vulnerability management platform, can import Nessus results from an uploaded .nessus export, so you can see which hosts still report CentOS SEoL (7.x) as migrations land. Per-finding retest is supported for Nessus, which lets you recheck each migrated host and confirm the finding has closed.

Sources

SITEY closes the loop, not just the report.Discover, validate, fix and verify in your own infrastructure.

See pricing
← All articles