In short: On RHEL, AlmaLinux and Rocky Linux, you check the PHP patch against PHP2Shell in three ways: the distribution's security announcements (dnf updateinfo), the package changelog (rpm -q --changelog) and the start time of the PHP processes. Red Hat lists RHEL 7 to 10 as affected and reported when retrieved that some updates are available and others in progress. After the update the rule is: restart completely, do not just reload.
What Red Hat has published on PHP2Shell
Red Hat has issued the security bulletin RHSB-2026-013 on PHP2Shell. We retrieved it on 25 October 2026. The most important points for admins:
- Affected are RHEL 10, 9, 8 and 7 as well as products and containers built on them on the basis of RHEL or UBI images.
- RHEL 7 is, according to Red Hat, affected only by CVE-2026-109619; the code for CVE-2026-109618 is said not to be present there.
- Not affected are systems without PHP or without PHP that processes untrusted HTTP requests.
- Updates: Some were available when retrieved, others in progress. The bulletin gave no specific errata numbers but referred to the errata pages.
Red Hat rates CVE-2026-109618 as "Important" with its own method and points out that default installations from RHEL 8 onward use PHP-FPM rather than mod_php. That is a classification, not an all-clear. The PHP project rates both vulnerabilities at CVSS v4.0 9.2, and the BSI (German Federal Office for Information Security) recommends updating immediately.
AlmaLinux and Rocky Linux: same source, own pace
AlmaLinux and Rocky Linux rebuild their packages from Red Hat's sources. Fixes therefore generally arrive with the same content, but at their own time and under their own security announcements. A reference to a Red Hat erratum does not mean that the package is available on your rebuild on the same day.
What matters is therefore the status on your system. Check it with the package management tools and not on the basis of news or forums.
Also pay attention to whether mirror servers or internal package sources are used on the server. In many companies, servers do not fetch their updates directly from the vendor but via an internal mirror or a management tool. If this mirror is not up to date, dnf finds no new packages even though they were published long ago.
Checking the PHP patch on RHEL and rebuilds
The following commands are purely read-only. Package names apply to the distribution's PHP packages; packages from third-party sources such as Remi are sometimes named differently.
# Which PHP streams does the system know, which one is active? (RHEL 8 and 9)
dnf module list php
# Installed PHP packages with version and origin
rpm -qa 'php*' --qf '%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n' | sort
# Are there security announcements for the CVEs for this system?
dnf updateinfo list --cve CVE-2026-109618
dnf updateinfo list --cve CVE-2026-109619
# Is the fix in the changelog of the installed package?
rpm -q --changelog php-fpm | grep -E "CVE-2026-10961[89]"
dnf updateinfo only shows announcements for updates that are not yet installed; with --installed you also see those already applied. An empty result can therefore mean two things: the update is already in, or it has not yet been published. The changelog comparison settles it. How to record the result as proof is described in the article Proving CVE numbers in the package changelog.
As with other enterprise distributions, the package usually keeps its original PHP version; only the release field changes. An older number in php -v is therefore no indication of a missing fix. General notes on checking the version are under Checking the PHP version and patch level properly.
Recognising the right operating mode
Red Hat names the default operating modes: from RHEL 8 onward PHP runs via PHP-FPM, on RHEL 7 as mod_php in the Apache service httpd. Many servers deviate from this, for example through panels, third-party sources or old configurations.
| System | Default according to Red Hat | Restart after the update |
|---|---|---|
| RHEL 8, 9, 10 and rebuilds | PHP-FPM | systemctl restart php-fpm |
| RHEL 7 | mod_php in httpd | systemctl restart httpd |
| Containers on a RHEL or UBI basis | depends on the image | rebuild the image, replace the container |
For containers, Red Hat recommends rebuilding your own images after updated base images and replacing running containers or pods. An update inside a running container is not a reliable route.
After the update: restart and verification
Red Hat stresses that a reload is not enough. Existing workers can retain the affected state. Restart every service that loads PHP, and check the result:
# Show services with outdated libraries (dnf-utils or dnf-plugins-core)
needs-restarting -s
# Compare the start time of the PHP processes with the time of the update
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
Red Hat has a practical note on configuration: php -i shows the command-line settings, not those of the web server. Anyone who wants to check whether interim values such as session.upload_progress.enabled=0 apply in the web context briefly uses a protected phpinfo page and deletes it afterwards. What else to bear in mind for the restart is under Restarting PHP-FPM and all workers.
Interim measures: Red Hat's notes
Where an update is still missing, Red Hat refers to the same interim measures as php.net and adds some practical notes for RHEL systems. They do not replace the update.
- Really add the line: According to Red Hat, the line for
session.upload_progress.enabledis commented out in the shipped configuration, so the feature is active by default. The value0has to be set explicitly. - Set it so it cannot be overridden: via
php_admin_valuein the PHP-FPM pool, with mod_php in the Apache configuration. Not viaini_set()or.user.ini. - Look for counterplayers: Red Hat recommends checking
.htaccessfiles, VirtualHosts and.user.inifiles for whether they switch the affected settings back on. - Set limits upstream too: In addition to
post_max_sizein PHP, Red Hat advises considering limits on the request size in the web server or proxy as well.
On PHP-FPM systems, the pools are generally located under /etc/php-fpm.d/. After every change the same applies as after the update: restart all workers completely.
If PHP from the Remi repository also runs on the same server, its own packages and services apply. Read the article The Remi repository on this.
How does PHP SOS help?
- On RHEL, AlmaLinux and Rocky Linux, we check all PHP packages, streams and third-party sources and reconcile them with the security announcements.
- We install updates, restart all workers completely and verify the process start times.
- For container environments, we rebuild images and replace running instances in a controlled way.
- We record the status per server in the proof of the PHP patch service.
Frequently asked questions
Is RHEL 7 affected by PHP2Shell?
According to Red Hat, RHEL 7 is affected only by CVE-2026-109619; the vulnerable code for CVE-2026-109618 is not present there. On RHEL 7, mod_php is the default operating mode, which the PHP team rates as particularly risky.
Why does Red Hat rate the vulnerability lower than php.net?
Red Hat uses its own rating under CVSS v3.1 and rates CVE-2026-109618 as Important because exploitation requires precise timing. php.net rates it at CVSS v4.0 9.2. Both consider code execution without login possible; the update is necessary in any case.
Do AlmaLinux and Rocky Linux get the fixes automatically?
Both rebuild their packages from Red Hat's sources and publish their own security announcements. The timing can differ from Red Hat. Check the status on your own system and in your distribution's announcements.
Is systemctl reload php-fpm enough after the update?
No. Red Hat expressly points out that a reload is not enough because existing workers can retain the affected state. Restart all workers; with mod_php, restart the Apache service httpd.