In short: The Remi PHP repository supplies current PHP versions for Fedora and the RHEL family, either as a module stream that replaces the system PHP or as a software collection that installs several versions in parallel. The PHP2Shell fixes 8.2.35, 8.3.36, 8.4.27 and 8.5.12 were announced there on 22 October 2026. Check every installed version individually and restart every associated service.
Why so many RHEL servers get PHP from Remi
Enterprise distributions such as RHEL, AlmaLinux and Rocky Linux rely on long-term stability. They ship few PHP branches and keep them for years. Many applications, however, demand newer versions than the distribution offers. This is where the repository of Remi Collet steps in, a longtime package maintainer for PHP in the Fedora and RHEL world.
Remi builds the PHP versions shortly after the official releases. On PHP2Shell, a post appeared on the repository's blog on 22 October 2026 about versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12. It names the two critical vulnerabilities CVE-2026-109618 and CVE-2026-109619 and urgently recommends the update. Red Hat's security announcements do not apply to these packages; what Red Hat reports for its own packages is in the article RHEL, AlmaLinux and Rocky Linux: checking the PHP patch.
Two routes: module stream or software collection
According to the Remi blog, the builds for Enterprise Linux from version 8 onward are available in two ways. Which one is used on your server determines how you check and restart.
| Route | Repository | Effect | Typical service |
|---|---|---|---|
Module stream, such as php:remi-8.3 |
remi-modular | replaces the system PHP, one default version | php-fpm |
Software collection, such as php83 |
remi-safe | additional version in parallel in its own path | own service per version, such as php83-php-fpm |
| Test packages and release candidates | remi-modular-test, remi-test | pre-release versions | not for production |
Software collections are typically located under /opt/remi/phpXY, their configuration under /etc/opt/remi/phpXY. That is practical for running old and new applications on one server. But it is also the most common reason why a version is overlooked during an update.
A note on the command line: software collections are not automatically available under the command php. Depending on the setup, cron jobs and scripts call them via a command of their own or a full path. Therefore also check crontabs and deployment scripts if you want to know which collection is in use for what.
Checking the Remi PHP repository after PHP2Shell
The following commands are purely read-only and show which Remi packages are installed and at what version.
# Active package sources: is remi-modular or remi-safe enabled?
dnf repolist
# Active module stream for PHP
dnf module list --enabled php
# Base packages and software collections installed in parallel
rpm -qa 'php-*' 'php[0-9][0-9]-php-*' --qf '%{NAME}-%{VERSION}-%{RELEASE}\n' | sort
# Version of each installed collection
for b in /opt/remi/php*/root/usr/bin/php; do echo "$b"; "$b" -v | head -1; done
For the supported branches, the situation is clear: if 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or newer is shown there, the fix is included. With Remi, the version number generally corresponds to the upstream version, unlike the distribution packages, which often keep their old number.
For older collections such as php81, php80 or php74 there is no official target version. Remi lists PHP 8.1 as end of life. Whether an installed package contains a fix against PHP2Shell, you clarify in the changelog, for example with rpm -q --changelog php81-php-fpm | grep -E "CVE-2026-10961[89]". Without a hit, treat the package as unresolved. How to document such hits cleanly is described in the article Proving CVE numbers in the package changelog.
Do not enable test repositories such as remi-test or remi-modular-test permanently on production servers. They supply release candidates that are intended for testing.
Update and restart of every version
The update itself is usually unspectacular with Remi: dnf upgrade fetches new packages for the stream and collections. The critical part follows afterwards. Every collection has its own FPM service, and each one has to be restarted.
# List all PHP-FPM services, including those of the collections
systemctl list-units --type=service --all | grep -E "php.*fpm"
# Check the start times of all PHP processes
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
Start times before the update mean: this service is still working with old code. Why a reload is not enough is explained on the page Restarting PHP-FPM and all workers.
Remi and the distribution: who is responsible?
Anyone who switches to Remi via a module stream changes the supplier for PHP. The security announcements from Red Hat, AlmaLinux or Rocky Linux then no longer relate to the installed PHP packages. Conversely, Remi does not report problems in other packages of the system. So you have to keep an eye on both sources.
Where an installed package comes from is shown by the package database, for example with rpm -qi php-fpm in the fields for vendor and packager. Because there are no errata in Red Hat's sense for Remi packages, the repository's blog is suitable as a notification route; it can be subscribed to by RSS feed. With PHP2Shell, the notice appeared there one day after the official releases.
For companies, this split is no obstacle, but it must be documented. Record which servers get PHP from Remi, who reads the announcements and who restarts the services after an update. Otherwise everyone relies on someone else.
Keeping order: fewer versions, less risk
Software collections invite you to simply leave old versions lying around. After PHP2Shell is a good time to tidy up:
- For each collection, clarify which website or cron job uses it.
- Deactivate unused collections and remove them after an observation period.
- Move applications on old collections to a supported branch.
- Document the remaining versions with purpose and person responsible.
How to keep track of many parallel versions is described in the article Several PHP versions on one server.
How does PHP SOS help?
- We record all Remi streams and collections on your servers and assign them to websites and cron jobs.
- We check the PHP2Shell status per version via package version and changelog.
- We install updates, restart every service and document this with process start times as part of the PHP patch service.
- We remove collections that are no longer needed in a controlled way, after coordination.
Frequently asked questions
Has Remi provided the PHP2Shell versions?
Yes. On 22 October 2026, the repository's blog announced versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12, with a reference to two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, and an urgent recommendation to update.
What is the difference between module stream and SCL at Remi?
With a module stream, you replace the system PHP with a Remi version, so there is one PHP version as the default. Software collections install further versions in parallel in their own paths, each with its own service.
Does PHP 8.1 from Remi still get updates?
Remi lists PHP 8.1 as end of life, and the PHP project no longer maintains the branch. Whether a particular 8.1 package contains a fix against PHP2Shell, you check in the changelog of the installed package. Without an entry, the status counts as unresolved.
Do I have to restart every PHP version after a Remi update?
Yes. Every version installed in parallel has its own FPM service. If only the main version's service is restarted, the others keep running with old code.