CentOS 7 After End of Life: Vault, Migration Paths and What to Patch

CentOS Linux 7 reached end of life on 30 June 2024, and the CentOS Project has published no updates for it since. Its packages were moved to vault.centos.org, an archive that the project says gets no security updates, so pointing yum at the vault lets you install software but never patches it. Your real choices are to rebuild on a supported distribution, upgrade in place, buy a paid extended support stream for a defined package set, or isolate the system under a dated, written exception.

More than two years later, CentOS 7 is still everywhere: in appliances, in the one billing server nobody wants to touch, and above all in container images built FROM centos:7 that still pass through CI every day. This guide explains exactly what happened at end of life, what breaks, which migration tools actually support CentOS 7 (fewer than people assume), what paid extended support does and does not cover, and how to work out what still needs patching. It extends our history of the Fedora, CentOS Stream and RHEL pipeline and our Rocky Linux and AlmaLinux release history one level deeper, into the operational detail.

Key takeaways

• The date is fixed. The CentOS Project's April 2023 announcement set 30 June 2024 as CentOS Linux 7's end of life, the same day Red Hat Enterprise Linux (RHEL) 7 left its Maintenance Support phase. Nothing new has shipped for CentOS 7 since.
• The vault is an archive, not a repository with fixes. The vault's own readme says the project does "not put security updates into the trees on this server." The final updates in the 7.9.2009 tree are dated June 2024.
• The default mirror configuration is dead. The mirrorlist.centos.org host that stock CentOS 7 repo files point to no longer resolves in DNS (we checked on 25 October 2026), so yum fails until you change the repo configuration.
• Most conversion scripts do not touch CentOS 7. The Rocky Linux migrate2rocky script and the almalinux-deploy script both start at Enterprise Linux 8. For CentOS 7, the in place route is a Leapp based upgrade (for example the AlmaLinux ELevate project), and it moves one major version at a time.
• Vulnerabilities kept arriving after end of life. Red Hat's public security data shows RHEL 7 package fixes after June 2024 in its paid extended stream for cups-filters, rsync, glibc, python3 and libblockdev, while other RHEL 7 packages were marked "Out of support scope" or "Will not fix". None of those fixes reach the CentOS vault.
• Containers are the biggest blind spot. Docker Hub marks every tag of the official centos image as end of life, and says the last meaningful update was 16 November 2020, long before the operating system's end of life.
• Isolation is a valid choice only with an end date. A risk acceptance with no expiry is simply a forgotten server.

What happened to CentOS Linux 7 at end of life

When did CentOS 7 reach end of life?

The CentOS Project announced the date on its blog on 11 April 2023 in a post titled "End dates are coming for CentOS Stream 8 and CentOS Linux 7". It gave CentOS Linux 7 an end of life of 30 June 2024, noted that RHEL 7 reaches the end of its Maintenance phase on the same day, and said plainly that after that date "there will be no updates published for CentOS Linux 7." The same post said the packages would be archived on vault.centos.org and told readers not to forget to migrate their containers.

The timing follows from how CentOS Linux 7 was built. It was a rebuild of RHEL 7 source packages, so its life tracked RHEL 7's Maintenance Support phase. Red Hat's life cycle policy describes three production phases (Full Support, Maintenance Support and an Extended Life Phase), and paid extended offerings sit beyond them. When RHEL 7 left Maintenance Support, the free stream of RHEL 7 updates that CentOS rebuilt stopped, and CentOS Linux 7 ended with it.

One detail confuses people who search for the end of life notice. The page at centos.org/centos-linux-eol still describes CentOS Linux 8, which ended on 31 December 2021, not CentOS 7. It is useful anyway, because it describes the process the project follows: content is removed from the mirrors and "moved to vault.centos.org where it will be archived permanently." For CentOS 7 the authoritative date is in the April 2023 blog post.

The final release and the last updates

CentOS Linux 7's last point release was 7.9.2009, built from RHEL 7.9. The vault directory for 7.9.2009 shows its os/ and isos/ trees dated 5 November 2020. The updates/ tree kept growing until the end: in the vault's package listing for 7.9.2009/updates/x86_64/Packages/, the newest files are dated 21 June 2024, nine days before end of life. That is the last fix any CentOS 7 machine will ever receive from the project.

Some of the final versions are worth knowing by heart, because you will see them in scan results for years:

These are backported builds. The upstream version number (1.0.2k, 2.17, 3.10.0) looks ancient, but each build carried many security fixes backported by the distribution while it was supported. That matters for scanners, which we come back to in the section on what to patch.

What happened to the mirrors and to vault.centos.org

The vault is the CentOS Project's long term archive. Its readme is blunt. It is "NOT an updated tree for installing CentOS Linux", it exists "for reference and to provide access to older archived versions", and "we do not put security updates into the trees on this server." It also lists external vault mirrors that the CentOS infrastructure team does not monitor, including archive.kernel.org in the USA and mirror.nsc.liu.se in Europe.

The vault structure you need for CentOS 7 looks like this (all paths returned HTTP 200 when we checked on 25 October 2026):

• https://vault.centos.org/7.9.2009/os/x86_64/ for the base release, including the RPM-GPG-KEY-CentOS-7 signing key.
• https://vault.centos.org/7.9.2009/updates/x86_64/ for every update shipped up to June 2024.
• https://vault.centos.org/7.9.2009/extras/x86_64/ for the extras repository.
• https://vault.centos.org/altarch/7.9.2009/ for the alternative architectures (aarch64, ppc64le and others).

Two practical consequences follow. First, the stock repo files on a CentOS 7 machine use a mirrorlist= line pointing at mirrorlist.centos.org, and that hostname now returns NXDOMAIN, so yum fails with mirror errors until you edit the configuration. Second, the vault is a single, project run service. Building a fleet's provisioning around it adds load to a volunteer funded archive and a single point of failure to your pipeline. If you must keep installing CentOS 7 packages, mirror the vault content you need into your own artifact store once and pin to it.

What still runs CentOS 7, and how do you find it?

CentOS 7 had a ten year life and was the default "free RHEL" for most of that decade, so it shows up in more places than most inventories record.

Where it hides

• Physical and virtual servers built between 2014 and 2021, especially the ones that host a single legacy application: an old ERP connector, a licence server, a reporting box.
• Appliances and vendor images. Many commercial appliances, virtual machine images and on premises software bundles shipped a CentOS 7 base. You may not have a shell on them. The vendor is responsible for the base, but you are responsible for knowing it is there.
• Container images. Images built FROM centos:7, and images built from internal base images that were themselves built from centos:7. Two layers of inheritance are enough to hide it from a Dockerfile grep.
• Build and CI runners. Older build agents were often CentOS 7 because that was what produced binaries with the oldest glibc, and so the widest compatibility. The same reasoning still keeps some manylinux2014 style build images alive.
• Cloud images launched from marketplace or community images years ago and never rebuilt.
• Developer tools such as Vagrant boxes and lab virtual machines that later quietly became production.

Signals that identify CentOS 7

A container on a modern host will report the host kernel in uname -r, so never use the kernel to identify a container's base. Use /etc/os-release and the RPM database inside the image.

What breaks after end of life?

Nothing breaks on 1 July 2024 in the sense of a machine stopping. What happens is slower, and for that reason more dangerous.

yum stops working until you change the repo files

The first visible failure is yum. With the default repo files, yum install or yum update fails because the mirror list host is gone. Teams fix this by switching to the vault, which makes installs work again and creates the most common misunderstanding of all: that the system is patched. It is not. A yum update against the vault after June 2024 can only bring a machine up to the state of 21 June 2024.

No new security errata, while vulnerabilities keep arriving

New vulnerabilities did not stop at end of life. Red Hat publishes machine readable security data for every CVE, including a per product "fix state" for RHEL 7, and it is the most direct primary evidence of what CentOS 7 users are now missing. Here is a sample of what that data shows for CVEs published after 30 June 2024 (all dates from Red Hat's security data API):

Three lessons sit in that table.

1. Fixes exist that CentOS 7 users cannot get. A rebuilt glibc, rsync or python3 for RHEL 7 shipped after end of life through the upstream vendor's paid extended stream. Those packages are not in the CentOS vault, and there is no free rebuild of them from the CentOS Project.
2. Even the paid stream does not fix everything. "Out of support scope" and "Will not fix" are real states. Extended support is a narrower promise than full support, which we return to below.
3. Not every headline CVE affects CentOS 7. The OpenSSH issue published one day after end of life (CVE-2024-6387) is marked "Not affected" for RHEL 7, and so is the sudo issue CVE-2025-32463, which CISA added to its Known Exploited Vulnerabilities (KEV) catalog on 29 September 2025. Old code is sometimes too old to contain a newer bug. You only know by checking a distribution tracker, never by assuming.

Expiring software: certificates, TLS and language runtimes

The other failures come from the outside world moving on.

• OpenSSL 1.0.2. The OpenSSL project lists 1.0.2 among versions that are "no longer supported" (paid extended support for it exists from the project). CentOS 7's 1.0.2k build supports TLS 1.2 but not TLS 1.3, so connections to services that require TLS 1.3 will fail, and anything you compile against the system OpenSSL inherits the limitation.
• Python 2. The Python project sunset Python 2 on 1 January 2020 and states it will not improve it "even if someone finds a security problem in it." On CentOS 7, yum itself runs on the system Python 2.7, so it cannot simply be removed. Applications that still use /usr/bin/python are on an interpreter with no upstream and, per the table above, packages that even the paid stream may leave out of scope.
• Trust stores. The ca-certificates package froze with the last update. As certificate authorities rotate roots and distrust old ones, TLS clients on a frozen trust store start failing to validate new chains, or keep trusting roots the rest of the world has removed.
• Toolchains. The system compiler is GCC 4.8. Modern language toolchains and many libraries no longer build or run on glibc 2.17, which pushes teams into unofficial binaries, old Software Collections or hand built runtimes, each of them another unpatched component.
• Third party repositories. Add on repositories that targeted EL7 have been archived or frozen as well. Treat every .repo file on the machine as something to review, not only the CentOS ones.

Scanners and audits

Scanner behaviour changes after end of life in a way that misleads people. A distribution aware scanner matches installed packages against the distribution's own advisories. When no new CentOS 7 advisories are published, new vulnerabilities may simply not show up against .el7 packages, so the report looks cleaner over time while the real exposure grows. We cover that trap in end of life software and scan results: no advisory is not safe. Auditors increasingly ask the opposite question directly: is any unsupported operating system in scope, and if so, where is the documented exception?

What migration paths exist for CentOS 7?

There are four realistic paths, plus the decision to isolate and accept. The tools differ more than the marketing around them suggests, so here is what each project's own documentation says.

Path 1: rebuild on a supported distribution

Build new machines or new images on a supported Enterprise Linux 8, 9 or 10 compatible distribution (RHEL itself, AlmaLinux, Rocky Linux, CentOS Stream, or another), or on a different distribution entirely, and move the application across. This is the cleanest outcome: no leftover .el7 packages, no in place upgrade risk, and a chance to put the configuration into code. It costs the most engineering time per application, because you have to rediscover how the old box was set up.

For containers this is nearly always the right path. You do not upgrade a container in place; you change its FROM line and rebuild.

Path 2: upgrade in place with Leapp

Leapp is the in place upgrade framework Red Hat uses for major version upgrades of RHEL, with its upgrade logic ("actors") developed in the open in the oamg/leapp-repository project. The official upgrade path from RHEL 7 is to RHEL 8.

For CentOS 7, the community route is the AlmaLinux ELevate project, which packages Leapp with upgrade data for other targets. Its documentation is precise about what it does:

• It performs one step upgrades. To go from CentOS 7 to AlmaLinux 10 you upgrade CentOS 7 to AlmaLinux 8, then 8 to 9, then 9 to 10, three separate runs.
• Its upgrade data packages include leapp-data-almalinux and leapp-data-centos (for upgrades to CentOS Stream).
• Because the CentOS 7 repositories are offline, the guide tells you to switch to the CentOS vault or to an EL7 mirror the AlmaLinux project hosts for use with ELevate before starting.
• A fully updated system is required, the leapp preupgrade check is expected to fail on a default install until you resolve the reported inhibitors, and the guide strongly recommends backups or snapshots and a trial run in a sandbox first.
• Upgrades to AlmaLinux 10 on x86_64_v2 hardware need the newer "ELevate NG" tooling, and older CPUs can be an inhibitor for later hops.

In place upgrades keep the host's identity, IP address, disks and local data, which is why people want them. They also carry over everything you did not know was on the machine, and the report at /var/log/leapp/leapp-report.txt is the first honest inventory many of these servers have ever had.

Path 3: convert, then upgrade

Conversion swaps a system's packages for those of another compatible distribution at the same major version. The CentOS Project's 2023 announcement mentions converting CentOS 7 to RHEL 7 and buying extended support as an option for systems that cannot migrate in time. Red Hat's conversion documentation exists for that tool, but it blocks scripted clients, so we could not fetch it for this post; check the vendor's current documentation for which source releases it still supports before planning around it.

The community conversion scripts do not cover CentOS 7:

• The Rocky Linux migrate2rocky README says it converts Enterprise Linux 8 systems to Rocky Linux 8 (and migrate2rocky9 handles Enterprise Linux 9), and that "Upgrades are not supported."
• The almalinux-deploy README lists supported sources starting at CentOS Linux 8.4 and EL8, and requires "at least CentOS 8.4 or equivalent EL8/9/10 version."

So the sequence for a CentOS 7 host that should end up on one of those rebuilds is upgrade first (Leapp or ELevate to EL8), then convert if needed, then keep upgrading. In practice that is several maintenance windows per host, which is one reason rebuilding often wins.

Path 4: paid extended support

Several organisations sell extended lifecycle support for CentOS 7 or for RHEL 7: the upstream enterprise vendor (after converting to its distribution) and a number of independent support companies that publish their own rebuilt packages. We describe the category, not the sellers. What these offerings typically provide:

• Backported security fixes for a defined package list, usually prioritised by severity, delivered through a private repository you point yum at.
• A fixed duration, often a few years past end of life, sold annually.
• Some compliance artefacts, such as advisories you can show an auditor and, from some providers, statements about cryptographic module validation status. Ask specifically whether the FIPS validated cryptographic modules on your systems keep their validation status under the offering, and get the answer in writing.

What they typically do not provide, and what you should ask about in writing:

• Every package. Red Hat's own data for RHEL 7 shows "Out of support scope" entries for expat, Firefox, Thunderbird, OpenSSH and the Python 2 package on specific CVEs, and a "Will not fix" for a glibc issue. Independent offerings define their own scope. Get the package list and the severity threshold before you sign.
• New features or newer runtimes. You still have OpenSSL 1.0.2, Python 2.7 and GCC 4.8. Extended support keeps an old platform patched; it does not modernise it.
• Third party repositories and your application. EPEL style add ons, vendor RPMs and everything you installed from source or from language package managers are outside scope.
• Container base images, unless the offering explicitly ships rebuilt images.

Extended support buys time. It does not remove the migration; it moves its deadline.

Path 5: isolate and accept

Sometimes none of the above is possible within the year: an appliance whose vendor no longer exists, a medical or industrial controller certified as a unit, a process control system that must not change. Then the honest answer is to reduce exposure and write it down. Remove inbound internet access, restrict management to a jump host, remove unused services and accounts, monitor the box closely, and record a risk acceptance with an owner, a review date and a planned end. Our guide to upgrade, extend, isolate or retire covers the general decision framework.

Comparison: which path fits which system

A useful rule of thumb: containers get rebuilt, cattle servers get rebuilt, pets with local state get upgraded in place after a rehearsal on a clone, appliances get isolation plus pressure on the vendor, and paid extended support covers the few systems whose migration genuinely cannot finish within the year.

What about container images built FROM centos:7?

Containers deserve their own section because they outlive hosts. Docker Hub's official centos repository carries a deprecation notice: all tags of the image are end of life, citing the 30 June 2024 date, "although the last meaningful update was November 16, 2020, long before the EOL date." The repository lists "No supported tags" and "No supported architectures." The centos:7 and centos:7.9.2009 tags were last pushed on 9 December 2022, according to the Docker Hub API.

That timeline is worse than the operating system's. A host running CentOS 7 that ran yum update regularly was patched until June 2024. An image built FROM centos:7 without a yum update layer started from a November 2020 package set, and nothing in the base image changed after that. Every application image built on it inherited those packages, and any image pulled from a registry today still contains them.

Inside those images there is usually a second layer of problems:

• Pinned libraries. A Dockerfile that ran yum install openssl-devel python-devel and then compiled a native extension or a language runtime against them bakes OpenSSL 1.0.2 and glibc 2.17 into the build. Moving the FROM line means rebuilding those native pieces too.
• Language packages. pip, npm, Maven or Go dependencies installed in the image are a separate inventory with their own vulnerabilities, unrelated to the OS being end of life, and they keep receiving fixes you can actually apply.
• Copied binaries. Images that COPY prebuilt binaries in may silently depend on glibc 2.17 symbols and break on a newer base, or the reverse.

The fix for containers is to change the base and rebuild, with tests. Our guides to checking whether a container base image is end of life and scanning a Rocky Linux container go into the image side in more detail.

What should you patch, and what can you patch?

"What to patch" on an end of life system splits into three layers that behave differently.

1. The operating system packages. On a CentOS 7 machine without a paid stream, you cannot patch these from any official source. You can bring the machine up to the final June 2024 state from the vault, which is worth doing on anything that is behind, and you can remove packages you do not need, which shrinks the attack surface. Beyond that, the operating system layer only gets fixed by migration or by buying extended support.

2. The software you put on top. Your application, its language dependencies and its bundled runtimes are a different story. If you run a Java service on a vendor supplied JDK tarball, or a Node.js application with its own node_modules, those components have their own upstreams and their own fixed versions. Patch them on the normal cycle. An end of life OS is not a reason to stop updating the application layer, and in practice that layer often carries more known, exploitable vulnerabilities than the base.

3. The exposure. When a vulnerable package cannot be updated, reduce who can reach it. Disable the service if you can (for example cups on a server that never prints), restrict the port, and remove setuid binaries you do not use.

To prioritise, combine three inputs:

• Is the vulnerability known to be exploited? CISA's KEV catalog (version 2026.10.23 listed 1,756 entries when we fetched it) is the most widely used signal. Base OS components appear in it regularly; historic examples include bash (CVE-2014-6271, added 28 January 2022), the Linux kernel (CVE-2016-5195, added 3 March 2022), sudo (CVE-2021-3156, added 6 April 2022) and polkit (CVE-2021-4034, added 27 June 2022). Map each entry to your actual package build using a distribution tracker, because, as the sudo example above shows, a KEV listing does not mean your version is affected.
• Is the package actually affected in your build? Distribution trackers such as Red Hat's security data and CVE pages record backport status per product. Upstream version numbers alone produce both false positives and false negatives on backported builds.
• Is the vulnerable code reachable? A vulnerable library that the network facing process loads matters more than a tool nobody runs.

For U.S. federal systems, remediation timelines for KEV entries now follow CISA's BOD 26-04 (10 June 2026), which superseded BOD 22-01 and sets risk based timelines; the fixed deadlines of 22-01 are history.

Step by step: inventory, contain and plan the migration

This walkthrough assumes a mixed estate: some hosts you can SSH to, some container images in a registry, and source repositories with Dockerfiles. Adapt the commands to your tooling.

Step 1: find CentOS 7 hosts

If you have an inventory tool, query its OS facts first. If you only have SSH, a short loop works:

# hosts.txt: one hostname per line
while read -r h; do
  printf '%s\t' "$h"
  ssh -o BatchMode=yes -o ConnectTimeout=5 "$h" \
    'source /etc/os-release 2>/dev/null; echo "${ID:-unknown} ${VERSION_ID:-?} $(uname -r)"' \
    || echo "unreachable"
done < hosts.txt | awk '$2=="centos" && $3=="7"'

With Ansible, the gathered facts already contain the distribution:

ansible all -m setup -a 'filter=ansible_distribution*' -o \
  | grep '"ansible_distribution": "CentOS"' \
  | grep '"ansible_distribution_major_version": "7"'

Record for each host: owner, application, whether it is internet facing, and whether it holds local state. That last field decides between rebuild and in place upgrade later.

Step 2: find CentOS 7 in Dockerfiles and images

Search source code first, because it tells you who owns the image:

grep -rEn --include='Dockerfile*' --include='*.dockerfile' \
  '^\s*FROM\s+(docker\.io/)?(library/)?centos:(7|centos7|7\.[0-9.]+)' .

Then check what is actually built, which catches inherited internal bases:

for img in $(docker image ls --format '{{.Repository}}:{{.Tag}}' | grep -v '<none>'); do
  os=$(docker run --rm --entrypoint sh "$img" -c \
    '. /etc/os-release 2>/dev/null && echo "$ID $VERSION_ID"' 2>/dev/null)
  [ "$os" = "centos 7" ] && echo "$img"
done

For images in a registry you do not want to run, generate an SBOM and look for the operating system component and .el7 package releases. Our guide on finding end of life components in your SBOM shows the queries.

Step 3: bring each host to the final state, from the vault, for retrieval only

On a CentOS 7 host that must keep running for now, make yum work and bring it to the last published state. Back up the existing repo files first so you can restore them:

sudo mkdir -p /root/repo-backup-$(date +%F)
sudo cp -a /etc/yum.repos.d/*.repo /root/repo-backup-$(date +%F)/

Then write a single vault repo file. Keep GPG checking on and point at the key in the vault:

# /etc/yum.repos.d/CentOS-Vault-7.9.2009.repo
# ARCHIVE ONLY. These trees receive no security updates after 30 June 2024.
[c7-vault-base]
name=CentOS 7.9.2009 base (vault, archived)
baseurl=https://vault.centos.org/7.9.2009/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
enabled=1

[c7-vault-updates]
name=CentOS 7.9.2009 updates (vault, archived)
baseurl=https://vault.centos.org/7.9.2009/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
enabled=1

[c7-vault-extras]
name=CentOS 7.9.2009 extras (vault, archived)
baseurl=https://vault.centos.org/7.9.2009/extras/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
enabled=1

Disable the original CentOS repo files rather than deleting them, then refresh:

sudo yum-config-manager --disable base updates extras centosplus
sudo yum clean all
sudo yum makecache
sudo yum check-update

Apply the final updates only after a snapshot or backup, and reboot if a kernel or glibc update landed. Note that the $basearch variable resolves to x86_64 on Intel and AMD machines; other architectures live under the altarch tree in the vault, so their baseurl differs.

If many machines need packages, mirror the vault trees you need into an internal repository once and point hosts there instead. That protects you from vault outages and keeps an exact record of what you install.

Step 4: record what the vault does not give you

Run a vulnerability scan against each host or image and keep the output. Then write the risk acceptance as a file next to your infrastructure code, so it is reviewed like code and has an expiry date that a pipeline can check:

# risk-acceptances/centos7-billing-01.yaml
system: billing-01.internal
os: CentOS Linux 7.9.2009 (end of life 2024-06-30)
owner: payments-platform team
reason: Vendor billing module certified only on EL7; vendor EL9 build due Q1 2027
compensating_controls:
  - No inbound internet; reachable only from app-tier subnet and bastion
  - cups, avahi and rpcbind disabled; unused setuid binaries removed
  - Host monitored by central logging; alerts reviewed daily
known_unpatched:
  - Any CVE published after 2024-06-30 affecting installed .el7 packages
target_path: rebuild on supported EL9 compatible distribution
approved_by: CISO delegate
approved_on: 2026-10-25
expires_on: 2027-03-31

An exception without expires_on is the most common way a temporary CentOS 7 server becomes permanent.

Step 5: check application dependencies on the old platform

Before you choose between rebuild and upgrade, find what the application actually depends on. These checks are read only:

# Who uses the system OpenSSL and glibc?
rpm -q --whatrequires openssl-libs
rpm -q --whatrequires 'libc.so.6()(64bit)' | head

# Which running processes have libssl loaded?
sudo grep -l 'libssl.so.10' /proc/*/maps 2>/dev/null | cut -d/ -f3 | sort -u \
  | xargs -r -I{} ps -o pid=,comm= -p {}

# Does anything still call Python 2 outside yum?
rpm -q --whatrequires python | grep -v '^yum'
grep -rlE '^#!.*python(2(\.7)?)?\s*$' /opt /usr/local /srv 2>/dev/null

# Non-RPM software that will not be handled by any upgrade tool
find /opt /usr/local /srv -maxdepth 2 -type d 2>/dev/null

# Third party repositories that need an EL8 or EL9 equivalent
grep -h '^baseurl\|^mirrorlist\|^metalink' /etc/yum.repos.d/*.repo | sort -u

For every binary you did not install from RPM, check its minimum glibc requirement:

objdump -T /opt/app/bin/server | grep -o 'GLIBC_[0-9.]*' | sort -uV | tail -1
ldd /opt/app/bin/server

The output tells you whether the binary will run on a newer base (it will almost always run on a newer glibc) and which shared libraries you must provide there. The reverse direction is where breakage comes from: OpenSSL 1.0.2 libraries do not exist on EL8 and later, so anything linked against libssl.so.10 must be rebuilt or shipped with a compatibility package.

Step 6: rehearse an in place upgrade on a clone

Warning: an in place major version upgrade rewrites the bootloader entries, kernel and most installed packages. Run it first on a clone or snapshot, never directly on the only copy of a production system, and confirm that you can roll back.

Before any upgrade command, confirm you are on the clone and that a snapshot exists:

hostnamectl --static        # must be the clone's name, not production
cat /etc/centos-release     # must say CentOS Linux release 7.9.2009
lsblk -f                    # confirm disks match the clone you snapshotted

Then follow the ELevate guide's order: bring the system fully up to date and reboot, install the elevate-release package from the AlmaLinux ELevate repository, install leapp-upgrade and the upgrade data package for your target, and run the pre upgrade check:

sudo yum update -y && sudo reboot
# after reboot, following the ELevate quickstart:
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
less /var/log/leapp/leapp-report.txt

The pre upgrade report lists inhibitors (blocking problems) and recommendations. The ELevate guide lists common CentOS 7 fixes, such as unloading the pata_acpi module and answering a question in /var/log/leapp/answerfile about the pam_pkcs11 module. Read each one rather than pasting them all; some, such as the guide's suggestion to permit root SSH login during the upgrade, change your security posture and should be reverted immediately afterwards. Only when the report is clean do you run sudo leapp upgrade and reboot into the upgrade environment.

After the upgrade, check what is left behind:

cat /etc/os-release
rpm -qa | grep '\.el7' | sort

Every remaining .el7 package is either something the upgrade could not map (often from a third party repository) or a leftover to remove. Then plan the next hop, because EL8 compatible releases have their own end of life dates too.

Step 7: rebuild containers and pin the new base

For each image found in Step 2, change the base, rebuild native pieces, and run the image's tests:

# Before
FROM centos:7
RUN yum install -y openssl-devel python-devel gcc && yum clean all

# After: a supported EL9 compatible base, pinned by digest in CI
FROM <your-approved-el9-base>@sha256:<digest>
RUN dnf install -y openssl-devel python3-devel gcc && dnf clean all

Add a CI check that fails the build if a Dockerfile reintroduces centos:7, so the fix does not quietly revert:

# .github/workflows/no-centos7.yml
name: block-centos7-base
on: [pull_request]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Fail on CentOS 7 base images
        run: |
          if grep -rEn --include='Dockerfile*' '^\s*FROM\s+(docker\.io/)?(library/)?centos:(7|centos7|7\.)' .; then
            echo "CentOS 7 is end of life (30 June 2024). Use the approved base image."; exit 1
          fi

Step 8: track the plan to zero

Keep one list: every CentOS 7 host and image, its chosen path, its owner, its target date and its status. Review it monthly. Measure progress by count of systems remaining, and treat every risk acceptance whose expires_on has passed as an incident in its own right.

Common mistakes

• Switching to vault repos and calling the system patched. The vault makes yum work again. It contains no fix published after June 2024 and never will. A clean yum check-update against the vault means "up to date with an archive", nothing more.
• Forgetting containers. Host inventories miss images, and the official centos image's last meaningful update was in November 2020. Search Dockerfiles, base image chains and registries, not just servers.
• Disabling GPG checks to make the vault work. Some online snippets set gpgcheck=0 to get past errors. The key is in the vault tree and on every CentOS 7 machine; keep signature checking on.
• Assuming a conversion script will handle CentOS 7. The Rocky Linux and AlmaLinux conversion scripts start at EL8. On CentOS 7 you upgrade first.
• Upgrading without testing glibc and OpenSSL dependent applications. Binaries linked to libssl.so.10, software built against Python 2 and anything from /opt will not be handled by Leapp. Test on a clone.
• Leaving the upgrade's temporary changes in place. Root SSH logins enabled for the upgrade, removed PAM modules and relaxed firewall settings should be reviewed and reverted.
• Trusting a quiet scanner. If your scanner relies on CentOS advisories, no new advisories means no new findings. Use data that tracks the RHEL 7 package state, or treat the OS as end of life in policy regardless of findings.
• Buying extended support without reading the scope. Ask which packages, which severities, which architectures, how long, and whether FIPS validation status is maintained. Out of scope packages are your problem.
• No end date for the exception. Every risk acceptance needs an owner and an expiry, checked automatically.
• Ignoring the application layer. The OS may be frozen, but the language dependencies inside your app still get fixes. Keep updating them while you migrate.

FAQ

Is CentOS 7 still supported in 2026?

No. CentOS Linux 7 reached end of life on 30 June 2024, and the CentOS Project has published no updates since. The only ongoing fixes for this platform come from paid extended support offerings, which cover a defined package set, or from migrating to a supported distribution.

Does vault.centos.org get security updates?

No. The vault's own readme says the project does "not put security updates into the trees on this server." The CentOS 7.9.2009 updates tree in the vault stops at packages dated 21 June 2024. Using the vault makes yum work again; it does not patch anything published after that date.

Why does yum fail on CentOS 7 with mirror errors?

The stock repository files use a mirrorlist= line that points at mirrorlist.centos.org, and that hostname no longer resolves. Point the repositories at the vault, or at your own internal mirror of the vault, with GPG checking left on.

Can I upgrade CentOS 7 to CentOS 8 or Stream in place?

The ELevate project supports in place upgrades from CentOS 7 using Leapp, with upgrade data for AlmaLinux and for CentOS Stream. It upgrades one major version at a time, so reaching an EL9 or EL10 release takes several runs. Rehearse on a clone and expect to resolve inhibitors from the pre upgrade report.

Can I use migrate2rocky or almalinux-deploy on CentOS 7?

Not directly. The migrate2rocky README covers Enterprise Linux 8 and 9 and says upgrades are not supported. The almalinux-deploy README requires at least CentOS 8.4 or an EL8, 9 or 10 system. On CentOS 7, upgrade to EL8 first, then convert if you still need to.

What does paid extended support for CentOS 7 actually cover?

Typically backported security fixes for a defined list of packages, at defined severities, for a fixed number of years, delivered through a private repository. It usually does not cover every package, third party repositories, your application, or newer runtimes. Red Hat's own RHEL 7 data shows "Out of support scope" and "Will not fix" states even in the upstream vendor's paid stream, so read the scope document carefully.

Is the centos:7 Docker image safe to use?

No. Docker Hub marks every tag of the official centos image as end of life, and says its last meaningful update was 16 November 2020. Rebuild images on a supported base, rebuild native components against the new libraries, and add a CI check so FROM centos:7 cannot come back.

Is CentOS 7 affected by regreSSHion?

Red Hat's security data marks RHEL 7's openssh package as "Not affected" by CVE-2024-6387, which was published on 1 July 2024. That does not make CentOS 7 safe; other OpenSSH CVEs since then are marked "Out of support scope" for RHEL 7. Check each CVE against a distribution tracker.

How long can I keep running CentOS 7?

Technically as long as the hardware lasts. In risk terms, every month adds unpatched vulnerabilities, and auditors increasingly expect a documented exception for unsupported operating systems. Set a written end date per system and fund the migration against it.

What is the difference between CentOS Linux 7 and CentOS Stream?

CentOS Linux 7 was a rebuild of RHEL 7 that followed RHEL's releases. CentOS Stream sits just ahead of RHEL in the development pipeline. Our Fedora, CentOS Stream and RHEL pipeline post explains the change, and the Rocky Linux and AlmaLinux history covers the RHEL compatible rebuilds that many CentOS users moved to. Teams comparing with Ubuntu's model can read our Ubuntu Pro and ESM history.

Where Safeguard fits, and where it does not

Safeguard does not patch CentOS 7 hosts, sell extended support for them or run in place upgrades. What it does help with is the inventory and the application layer. The CLI scans repositories, container images and SBOM files (safeguard scan --dir ., safeguard scan --image <name>, safeguard scan --sbom <file>, with JSON results under ./output), and the platform shows which projects contain a given component and version, so you can ask which images still carry openssl-1.0.2k or the CentOS 7 release package. Vulnerability matching and reachability analysis then rank the findings in your own code and dependencies, and autonomous remediation (off by default) can open the pull requests that move those dependencies while the OS migration runs on its own schedule.

CentOS 7 itself will never get another upstream fix, so the part of the stack you can still patch is the software you build and ship on it. The application dependencies and container images that sit on top of an end of life base keep receiving fixes, and that is where the steps below apply.

Fix it without waiting for upstream

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

You can download Safeguard and follow the CLI docs to try these yourself.

This is a real CLI session: install, open the interactive terminal and ask it to fix a lodash CVE. The assistant reads the finding and advisory, asks before any command that changes something, edits package.json, runs npm install and npm test with approval, and pushes nothing. The same flow applies to the application dependencies inside an image you are moving off a CentOS 7 base: fix the code layer while the OS layer is rebuilt.

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 and then scans from the terminal. For a CentOS 7 migration, that is how you would scan images and source trees that never leave your network, before and after you change the base image.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• CentOS Project blog: End dates are coming for CentOS Stream 8 and CentOS Linux 7 (11 April 2023)
• CentOS Project: CentOS Linux EOL
• CentOS Vault
• CentOS Vault readme
• CentOS Vault: 7.9.2009 tree
• CentOS Vault: 7.9.2009 updates packages (x86_64)
• Red Hat Enterprise Linux life cycle
• Red Hat security data: CVE-2024-6387
• Red Hat security data: CVE-2024-47176
• Red Hat security data: CVE-2024-12085
• Red Hat security data: CVE-2024-6232
• Red Hat security data: CVE-2025-4802
• Red Hat security data: CVE-2025-6019
• Red Hat security data: CVE-2024-45490
• Red Hat security data: CVE-2025-26465
• Red Hat security data: CVE-2025-0395
• Red Hat security data: CVE-2025-32463
• CISA Known Exploited Vulnerabilities catalog (JSON feed)
• AlmaLinux wiki: ELevate project
• AlmaLinux wiki: ELevate quickstart guide
• AlmaLinux wiki: ELevating CentOS 7 to AlmaLinux 10
• Leapp repository (oamg/leapp-repository) README
• Rocky Linux rocky-tools: migrate2rocky README
• Rocky Linux documentation: migrate2rocky guide
• AlmaLinux almalinux-deploy README
• Docker Hub: centos official image
• Python Software Foundation: Sunsetting Python 2
• OpenSSL Library: release strategy

Last reviewed: 25 October 2026.