EPEL 7 is archived: checking PHP2Shell fixes on CentOS 7

A working EPEL 7 mirror means that you can download archived packages. It does not mean that those packages receive new security fixes. EPEL 7 and CentOS 7 reached end of life in June 2024; changing a repository's baseurl can restore downloads, but cannot backport a PHP vulnerability disclosed in October 2026.

That distinction matters for PHP2Shell, the PHP remote code execution vulnerabilities CVE-2026-109618 and CVE-2026-109619. A successful yum update only tells you that its transaction completed using the enabled repositories. It does not establish that your PHP runtime is patched.

This recipe identifies the installed PHP packages and directs you to the matching update path. It does not change your server's repositories or PHP configuration.

Prerequisites

• A CentOS 7 x86_64 server with PHP installed from RPM packages.
• Shell access. The inventory commands below do not need root.
• PHP installed from source, a control panel, or a container image needs its own provider's update procedure; the system RPM inventory may not describe it.

Identify the host and package releases

cat /etc/centos-release
uname -m
rpm -qa 'php*-common' --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' | sort

Our October 26, 2026 test installed both GetPageSpeed PHP 7.4 layouts in a clean CentOS 7 x86_64 container. The inventory returned:

php-common-7.4.33-38.el7.x86_64
php74-php-common-7.4.33-38.el7.x86_64

This is a captured example, not a minimum fixed-version list. Compare your own complete package release with the provider's advisory.

The package name distinguishes two common installations:

Package name	Layout	Update source to check
php-common	Base-name PHP, normally under /usr	The channel for the existing PHP branch
php74-php-common	PHP 7.4 software collection, normally under /opt/remi/php74	The collection's package provider

Other collections use their own version prefix, such as php56-php-common or php83-php-common. An empty inventory is not a clean bill of health: check where the PHP process serving your application actually comes from.

If both PHP 7.4 layouts are installed, the following identifies which RPM owns each CLI binary:

rpm -qf /usr/bin/php /opt/remi/php74/root/usr/bin/php

Run it only for paths that exist on your host. The web server may use a different PHP binary from the shell, so inventory every active runtime.

Why the archive check is not a patch check

The archived EPEL 7 repository is still readable through our archive mirror:

curl --fail --silent --show-error --location --max-time 45 \
  --output /tmp/epel7-repomd.xml \
  https://archive.epel.cloud/pub/archive/epel/7/x86_64/repodata/repomd.xml
grep -m 1 '<repomd' /tmp/epel7-repomd.xml

Seeing a repomd XML element proves that repository metadata was fetched. It says nothing about whether a PHP build contains either PHP2Shell fix. epel.cloud passes archived packages through; it does not modify or maintain Fedora's EPEL 7 packages.

PHP packages installed from Remi are a separate source from EPEL. Restoring EPEL downloads does not add new builds to a frozen Remi EL7 channel.

Choose the update path for your package shape

For CentOS 7 base-name PHP or Remi-compatible software collections, the GetPageSpeed PHP2Shell guide lists known patched releases, branch-specific install commands, service restarts and rollback caveats. Choose the commands for the package shape you identified above; enabling a base-name channel for another PHP branch can change the runtime your application uses.

GetPageSpeed publishes these backports separately from the EPEL mirror. The packages are free to install for personal, development and evaluation use; commercial production use requires GetPageSpeed Ultra under the repository terms.

If you are also responsible for older Debian or Ubuntu servers, use the separate Ubuntu 20.04/18.04 and Debian 10 package guide. Those are DEB packages, not packages supplied by this EPEL mirror.

Verify

After following your provider's update instructions, repeat the package inventory command and compare the complete version and release with its advisory. Vendor backports can keep an old upstream version number, so php -v alone is insufficient.

For a base-name install, the RPM changelog is another useful piece of evidence:

rpm -q --changelog php-common | grep -E 'CVE-2026-10961[89]'

For a collection, replace php-common with its actual package name. A missing changelog entry is not proof that a package is vulnerable; consult the vendor's release advisory. You can also paste the inventory into the PHP2Shell package checker, which checks vendor package releases in your browser.

Finally, restart the PHP services that your applications use, following the update guide. Updating an RPM does not replace PHP code already loaded in running workers. Patching PHP also does not restore support for the rest of CentOS 7; keep the operating-system migration on your maintenance plan.