PHP2Shell on AlmaLinux, Rocky Linux and RHEL 8/9/10: Check and Patch

AlmaLinux has fixed PHP2Shell for every PHP stream it ships on AlmaLinux 8, 9 and 10. CVE-2026-109618 and CVE-2026-109619 let one unauthenticated request take over a PHP server, so an AlmaLinux PHP update is urgent: run dnf upgrade 'php*' and restart PHP-FPM. The fixes for the supported streams landed on October 21, 2026, the day of disclosure. Two days later AlmaLinux also patched four streams that Red Hat had already retired (PHP 7.2, 7.3 and 8.0 on AlmaLinux 8, PHP 8.1 on AlmaLinux 9), which RHEL and Rocky Linux do not cover.

Not sure which build you have? Paste your package list into the PHP2Shell checker. It reads distribution backports and gives the fix for every platform.

CVE-2026-109618  RCE via out-of-memory corruption   (GHSA-w8hw-w9fx-j79w)  CVSS v4.0 9.2
CVE-2026-109619  RCE via stale global state         (GHSA-6wmf-4rv5-p3rp)  CVSS v4.0 9.2
Affected:  PHP 5.4 and later, all web SAPIs (PHP-FPM, mod_php, php-cgi)
Fixed upstream:  8.5.12, 8.4.27, 8.3.36, 8.2.35
AlmaLinux 8/9/10:  fixed in every shipped PHP stream (ALSA-2026:87070 to 87151, A011 to A014)

How to fix PHP2Shell on AlmaLinux, Rocky Linux and RHEL

Update PHP from the distribution repositories and restart the service that runs it:

dnf upgrade 'php*'
systemctl restart php-fpm

Running Apache mod_php instead of PHP-FPM? Restart httpd. The module stream you enabled stays the same: dnf moves you to the fixed build of that stream, so PHP 7.4 stays 7.4 and PHP 8.2 stays 8.2.

On AlmaLinux 10 the optional PHP 8.4 packages are named php8.4-*. The 'php*' pattern covers them as well.

Check whether your server is vulnerable

First see which PHP stream is enabled. The [e] marker shows it:

dnf module list php

On AlmaLinux 9 and 8, no [e] means the default AppStream PHP (8.0 on AlmaLinux 9, 7.2 on AlmaLinux 8). AlmaLinux 10 has no PHP modules: the base PHP is 8.3, and 8.4 comes as separate php8.4 packages.

Then ask dnf whether a PHP2Shell fix is still waiting:

dnf updateinfo list --cve CVE-2026-109618

Any line in the output, such as ALSA-2026:87151 Important/Sec. php-cli-8.0.30-8.el9_8.1, is a pending fix: run the upgrade above. No output means nothing is waiting for the installed packages.

Finally, compare the installed release with the table below:

rpm -q php-cli php-fpm

Why the changelog check can come back empty

Where the fix is a backport, the package changelog names the CVEs:

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

That works for the AppStream 8.0 build on AlmaLinux 9 and for the 7.2, 7.3, 7.4, 8.0 and 8.1 streams. The 8.2 and 8.3 streams, and PHP 8.4 on AlmaLinux 10, were rebased to the fixed upstream release instead, and their changelog only says rebase to 8.3.36. An empty grep there does not mean vulnerable: check the version. 8.2.35, 8.3.36 and 8.4.27 or later are fixed.

AlmaLinux PHP2Shell fixed versions, per stream

Each version is the php-cli release we read in the AlmaLinux errata and then installed from the AlmaLinux 8.10, 9.8 and 10.2 repositories.

AlmaLinux	PHP stream	Fixed release	Advisory	RHEL / Rocky Linux
8	php:7.2 (default)	7.2.24-1.module_el8.10.0+4315+7b734bf3.alma.1	ALSA-2026:A011, Oct 23	no fix (retired stream)
8	php:7.3	7.3.20-1.module_el8.10.0+4316+90ea5fe5.alma.1	ALSA-2026:A012, Oct 23	no fix (retired stream)
8	php:7.4	7.4.33-8.module_el8.10.0+4321+cf5fd4bb	ALSA-2026:87080, Oct 21	RHSA-2026:87080
8	php:8.0	8.0.30-1.module_el8.10.0+4319+26f10322.alma.1	ALSA-2026:A013, Oct 23	no fix (retired stream)
8	php:8.2	8.2.35-1.module_el8.10.0+4323+fc907035	ALSA-2026:87073, Oct 21	RHSA-2026:87073
9	AppStream 8.0 (default)	8.0.30-8.el9_8.1	ALSA-2026:87151, Oct 21	RHSA-2026:87151
9	php:8.1	8.1.32-1.module_el9.8.0+326+528679fc.alma.1	ALSA-2026:A014, Oct 23	no fix (retired stream)
9	php:8.2	8.2.35-1.module_el9.8.0+329+e5668d75	ALSA-2026:87072, Oct 21	RHSA-2026:87072
9	php:8.3	8.3.36-1.module_el9.8.0+330+fdc30075	ALSA-2026:87079, Oct 21	RHSA-2026:87079
10	AppStream 8.3	8.3.36-1.el10_2	ALSA-2026:87070, Oct 21	RHSA-2026:87070
10	php8.4 packages	8.4.27-1.el10_2	ALSA-2026:87071, Oct 21	RHSA-2026:87071

The RHEL column comes from Red Hat’s CVE-2026-109618 data, which lists fixes for the RHEL 8 streams 7.4 and 8.2, the RHEL 9 default PHP and streams 8.2 and 8.3, and both PHP builds on RHEL 10. The .alma.1 releases are AlmaLinux’s own patches for streams Red Hat no longer maintains.

Rocky Linux and RHEL

Rocky Linux rebuilt the Red Hat advisories under the same numbers (RLSA-2026:87070, 87072, 87073, 87079, 87080, 87151), so the update commands above work unchanged. RHEL subscribers get the same fixes as the RHSA advisories in the table.

The difference is the retired streams. If a Rocky Linux or RHEL server still runs PHP 7.2, 7.3 or 8.0 on EL8, or PHP 8.1 on EL9, no fixed package is coming from the distribution. Switch to a maintained stream, for example:

dnf module switch-to php:8.2
systemctl restart php-fpm

Test the application on the new branch first. A jump from 7.x to 8.2 changes language behaviour, not just the security fix.

PHP from Remi on AlmaLinux

Many AlmaLinux servers run PHP from the Remi repository rather than AppStream. Remi has published fixed builds as well. The remi-release package enables the remi-modular and remi-safe repositories by default, so the plain upgrade pulls the fix with no extra repository options:

dnf upgrade 'php*'
systemctl restart php-fpm

Check the enabled stream with dnf module list --enabled php (it shows remi-7.4, remi-8.1 and so on). Remi’s EOL branches carry the CVE line in the changelog, so the grep check above works for them. On AlmaLinux 9 we installed and checked php-cli-7.4.33-31.module_php.7.4.el9.remi and php-cli-8.1.34-6.module_php.8.1.el9.remi. Both list CVE-2026-109618 and CVE-2026-109619.

Remi’s software collections (php74-php-*, php81-php-* and so on) live side by side under their own names and their own service:

dnf upgrade 'php74-php*'
systemctl restart php74-php-fpm

Replace php74 with your collection. On AlmaLinux 9 the fixed collections we read include php74-php-cli-7.4.33-31.el9.remi, php81-php-cli-8.1.34-6.el9.remi and php83-php-cli-8.3.36-1.el9.remi.

Stop-gaps while you schedule the restart

Patching is the fix. If a server cannot take the update today, the PHP advisory lists partial mitigations: memory_limit=-1, a low post_max_size and session.upload_progress.enabled=0. None of them closes both CVEs.

Sansec’s PHP2Shell research also suggests an NGINX rule that rejects multipart requests, the request format that triggers the bug, in every server block that passes requests to PHP:

if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

It breaks every file upload, and some shops submit cart or checkout forms as multipart, so test an order after adding it. Remove the rule once PHP is updated. For what else NGINX can and cannot block in front of PHP, see PHP2Shell mitigation in NGINX.

Still on CentOS 7 (migrating to AlmaLinux later)?

A common plan is “we will fix it when we move to AlmaLinux”. PHP2Shell does not wait for the migration. CentOS 7 gets no PHP2Shell fix from Red Hat or Remi: nobody ships a fixed PHP for CentOS 7 except GetPageSpeed.

PHP2Shell on CentOS 7 has drop-in patched builds for every PHP from the stock 5.4 to 8.4, in both Remi package shapes, so you can patch in place now and migrate on your own schedule. Everpatch for CentOS 7 covers the rest of what GetPageSpeed maintains for EL7 while the migration is under way. Still on CentOS 6? See PHP2Shell on CentOS 6.

FAQ

Is AlmaLinux affected by PHP2Shell?

Yes, until you update. Every PHP build AlmaLinux shipped before October 21, 2026 is vulnerable. The fixed releases are in the table above, and dnf upgrade 'php*' installs them.

Is PHP 7.2 on AlmaLinux 8 fixed?

Yes. The default php:7.2 stream is fixed in 7.2.24-1.module_el8.10.0+4315+7b734bf3.alma.1 (ALSA-2026:A011). RHEL 8 and Rocky Linux 8 have no fix for this stream.

Is PHP 8.1 on AlmaLinux 9 fixed?

Yes, in 8.1.32-1.module_el9.8.0+326+528679fc.alma.1 (ALSA-2026:A014). On RHEL 9 and Rocky Linux 9 the 8.1 stream gets no fix: switch to php:8.2 or php:8.3.

rpm -q --changelog shows no CVE. Am I still vulnerable?

Not necessarily. The 8.2 and 8.3 streams and PHP 8.4 were rebased to the fixed upstream release, and their changelog only says rebase to. Check the version with rpm -q php-cli: 8.2.35, 8.3.36 or 8.4.27 or later is fixed.

Do I need to restart anything after the update?

Yes. Running PHP-FPM workers keep the old code in memory until restarted. Restart php-fpm (or phpNN-php-fpm for a Remi collection), or httpd for mod_php.

Is setting session.upload_progress.enabled=0 enough?

No. It blocks one confirmed path for CVE-2026-109619 and does nothing for CVE-2026-109618. Only the package update fixes both.

Conclusion

PHP2Shell on AlmaLinux is a solved problem as long as the update is applied: AlmaLinux fixed every PHP stream on 8, 9 and 10, including four streams Red Hat retired. Run dnf upgrade 'php*', restart PHP-FPM, and confirm with dnf updateinfo list --cve CVE-2026-109618. On Rocky Linux or RHEL with a retired stream, switch streams. On CentOS 7, use the GetPageSpeed CentOS 7 builds until the migration is done.

Watching many servers? GetPageSpeed Amplify monitors NGINX hosts and ranks every one by NGINX CVEs, gixy config findings and PHP CVE exposure, so a server that missed the PHP update stands out.