yum upgrades for production use, this is the repository for you.
Active subscription is required.
PHP2Shell on CentOS 7 is an emergency: CVE-2026-109618 and CVE-2026-109619 let an unauthenticated request take over a PHP server, and nobody ships a fixed PHP 5.6, 7.0, 7.3 or 8.0 for CentOS 7 except GetPageSpeed. Install the patched build from the free GetPageSpeed channel for your PHP version and restart PHP-FPM.
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, LiteSpeed, FrankenPHP)
Fixed upstream: 8.5.12, 8.4.27, 8.3.36, 8.2.35 only
CentOS 7 fix: GetPageSpeed channels php56, php70, php73, php80, php84
How to fix PHP2Shell on CentOS 7
Install (or update) the GetPageSpeed release package, then upgrade PHP from the channel that matches your version. For PHP 7.0:
yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum --enablerepo=getpagespeed-extras-php70 upgrade 'php-*'
systemctl restart php-fpm
Replace php70 with php56 or php80 for those versions. The Remi PHP 7.3 software collection uses its own package and service names:
yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum --enablerepo=getpagespeed-extras-php73 upgrade 'php73-php*'
systemctl restart php73-php-fpm
Running Apache mod_php? Restart httpd instead of PHP-FPM. The PHP channels are free and need no subscription.
What PHP2Shell is
The PHP security team published two critical advisories on October 21, 2026, after announcing them a day earlier. Researchers named the pair PHP2Shell.
CVE-2026-109618, remote code execution via out-of-memory corruption. PHP handles an out-of-memory error by jumping out of whatever it was doing. If that happens during request startup, for example while parsing a multipart upload, the request data is only half initialised. The cleanup that follows treats it as valid, and an attacker who controls the request controls that memory.
CVE-2026-109619, remote code execution via stale global state. Some request-owned state survives after its memory has been freed. The next request served by the same worker can use it before normal initialisation resets it. Confirmed paths include session upload progress and INI diagnostics emitted before initialisation.
Both rate CVSS v4.0 9.2 and need no authentication. php.net says every PHP installation serving web requests is at risk, with mod_php the worst case: a demonstrated exploit fires before any application code runs. Tenable reports that PHP2Shell is now broadly exploited in the wild, and Amazon’s honeypots saw an attempt four days before disclosure.
Who is affected by PHP2Shell on CentOS 7
Every CentOS 7 or RHEL 7 server that serves PHP over the web is affected unless it already runs a patched build, whether it uses PHP-FPM, Apache mod_php or php-cgi. The GetPageSpeed channels cover the branches CentOS 7 servers most often still run: PHP 5.6, 7.0 and 8.0 from Remi’s remi-php56, remi-php70 and remi-php80 repositories, PHP 7.3 from Remi’s php73 software collection, and PHP 8.4. If your server runs another EOL branch such as 7.1, 7.2, 7.4 or 8.1, no patched EL7 binary exists for it; the practical fix is to move to the PHP 8.4 stack described below.
Why CentOS 7 servers are stuck
The PHP project fixed only the supported branches: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For 7.4, 8.0 and 8.1 it published minimal source-only backports. For PHP 7.3 and older it published nothing at all.
Most CentOS 7 servers run PHP from the Remi repository, and Remi stopped building for EL7 in June 2024. On release day php.net itself told Remi users that the repository would not have updates that day and to build from source. Hosting providers emailed customers telling them to patch their own servers.
So a CentOS 7 host running Remi PHP 5.6, 7.0, 7.3 or 8.0 had three options: rebuild PHP from source with a hand-ported patch, pay a commercial extended-support vendor whose packages use different names and paths, or stay exposed.
The interim mitigations are partial
The advisory lists stopgaps: memory_limit=-1, a low post_max_size, and session.upload_progress.enabled=0. They are worth applying while you schedule the upgrade, but the PHP team is explicit that only an update is a complete solution. Removing the memory limit still leaves real allocation failures reaching the vulnerable path, and disabling upload progress blocks only the confirmed session path for CVE-2026-109619, not its other variants.
The GetPageSpeed fix for each PHP version
GetPageSpeed rebuilt each Remi EL7 PHP branch with the PHP2Shell fix. Every package keeps the Remi name, ABI and library SONAMEs, so yum upgrade swaps it in place. PECL extensions and ionCube Loader keep working without a rebuild.
| PHP version | Channel | Patched package | Where the fix comes from |
|---|---|---|---|
| 5.6 | getpagespeed-extras-php56 |
php-*-5.6.40-42.el7 |
PHP 5.6 adaptation of the upstream 7.4 fix, audited hunk by hunk, with the executor-shutdown resets other 5.6 ports omit |
| 7.0 | getpagespeed-extras-php70 |
php-*-7.0.33-43.el7 |
port of the official 7.4 fix |
| 7.3 | getpagespeed-extras-php73 |
php73-php-*-7.3.33-23.el7 |
official 7.4 fix, hunk for hunk |
| 8.0 | getpagespeed-extras-php80 |
php-*-8.0.30-22.el7 |
official PHP 8.0 backport, verified line for line |
| 8.4 | getpagespeed-extras-php84 |
php-*-8.4.27-1.el7 |
upstream PHP 8.4.27 |
More than PHP2Shell. Remi kept patching EOL PHP for EL8 and newer after it stopped building for EL7. The GetPageSpeed 5.6, 7.0, 7.3 and 8.0 builds start from those maintained sources, so they also bring the 2024 to 2026 fixes EL7 never received: 11 extra fixes for PHP 5.6, 14 for 7.0, 19 for 7.3, and every 2023 to 2026 fix for 8.0.
How each build was validated. In a clean CentOS 7 container, the test harness installs the exact Remi package the build replaces and proves both PHP2Shell probes reproduce there. It then upgrades in place and proves both probes are fixed. It also checks that:
- the full phpt suite shows no regressions against the Remi baseline, apart from nine tests whose behaviour the fix changes by design;
php -mlists the same modules, including PECL extensions and ionCube;- configuration files are preserved and PHP-FPM keeps serving after an out-of-memory request;
yum downgradeback to the Remi packages works.
The builds went to production on October 22, the day after disclosure, on PrestaShop 1.6, Magento 1 and custom PHP 8.0 servers, with no downtime beyond a PHP-FPM restart.
Check whether your server is vulnerable
List your installed PHP packages:
rpm -qa 'php*-common' --qf '%{NAME}-%{VERSION}-%{RELEASE}\n'
A release ending in .el7.remi is vulnerable: every Remi EL7 build predates the fix. After the upgrade you should see a GetPageSpeed release such as php-common-7.0.33-43.el7. On the PHP 8.4 stack, anything older than 8.4.27 is vulnerable.
PHP 8.4 on CentOS 7
If you would rather leave EOL PHP behind, GetPageSpeed also maintains a full PHP 8.4 stack for CentOS 7, now at 8.4.27 with the PHP2Shell fix. Existing users get it with yum upgrade. New installs:
yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum-config-manager --enable getpagespeed-extras-php84
yum -y install php84-getpagespeed-stack
Details and the rollback procedure are on the CentOS 7 LTS page.
Rollback and caveats
yum downgrade returns you to the Remi packages if you ever need to. For PHP 8.0 the target is Remi’s 8.0.30-6, because the older 8.0.30-3 is no longer on Remi’s mirrors.
One behaviour changes. A request that hits memory_limit now ends its worker immediately: shutdown functions do not run and buffered output is not sent. This is the same trade the PHP security team made in its own EOL backports, because the unsafe unwinding is exactly what PHP2Shell abuses. Code that relied on catching memory exhaustion in a shutdown handler will need attention.
Finally, CentOS 7 itself is still end-of-life. These channels keep the PHP layer patched; they do not make the operating system supported. Plan the migration, but don’t run exposed in the meantime.
FAQ
Is PHP 7.4 on CentOS 7 affected by CVE-2026-109618?
Yes. PHP2Shell affects every branch from 5.4 onwards. The PHP project published only a source backport for 7.4, and Remi no longer builds for EL7, so binary PHP 7.4 packages on CentOS 7 remain vulnerable. The supported path is the GetPageSpeed PHP 8.4 stack, which already includes the fix.
Is there a PHP 5.6 security patch for CentOS 7?
Yes. The getpagespeed-extras-php56 channel ships php-5.6.40-42.el7 with the PHP2Shell fix and 11 later security fixes, as a drop-in replacement for the Remi remi-php56 packages.
Do I need a GetPageSpeed subscription for the PHP2Shell fix?
No. The PHP channels are free. Install the GetPageSpeed release package and upgrade from the channel for your PHP version.
Will my PECL extensions and ionCube Loader still work?
Yes. The fix changes no structure layout or API number, and validation confirms the loaded module list is identical before and after the upgrade.
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. The PHP security team says only an update is a complete fix.
Conclusion
PHP2Shell on CentOS 7 is a critical, unauthenticated remote code execution, and servers on Remi PHP have no upstream or distribution fix. The GetPageSpeed php56, php70, php73, php80 and php84 channels close that gap with in-place, validated, free upgrades.
Patching PHP is only half of a CentOS 7 server. The NGINX in front of it drifts too, one config change at a time. GetPageSpeed Amplify runs scheduled gixy scans across every host and ties findings to live NGINX runtime metrics. Drop-in compatible with the deprecated nginx-amplify-agent (EOL January 2026).
Keeping CentOS 7 alive for a while longer? The GetPageSpeed CentOS 7 LTS repository keeps yum upgrade working and provides current NGINX builds and modules. Subscribe to the GetPageSpeed repository to get them.
