PHP2Shell on CentOS 6 has no distribution or upstream fix: CVE-2026-109618 and CVE-2026-109619 let an unauthenticated request take over a PHP server, and CentOS 6 reached end of life in 2020. GetPageSpeed ships patched builds for three PHP lines on CentOS 6: the stock PHP 5.3, plus PHP 7.0 and 7.1 in Remi’s package names. Each one updates in place with yum.
Running CentOS 7 instead? See PHP2Shell on CentOS 7. Not sure whether your build is patched? Paste your package list into the PHP2Shell checker.
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 per the advisory, all web SAPIs (PHP-FPM, mod_php, php-cgi)
Fixed upstream: 8.5.12, 8.4.27, 8.3.36, 8.2.35 only
CentOS 6 fix: GetPageSpeed php-5.3.3 (main repository), php70 and php71 channels, x86_64
How to patch PHP2Shell on CentOS 6
First check which PHP you run:
rpm -qa 'php*-common' --qf '%{NAME}-%{VERSION}-%{RELEASE}\n'
If yum can’t reach any repository, fix that first: the CentOS 6 mirrors were retired, and How to fix yum after CentOS 6 went EOL points them at the vault.
Stock CentOS 6 PHP 5.3 (php-common-5.3.3-50.el6_10 and older) updates from the main GetPageSpeed repository, so there is no channel to enable:
yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum update 'php*'
service httpd restart # or: service php-fpm restart
Remi PHP 7.0 or 7.1 (php-common-7.1.33-10.el6.remi and the like, from remi-php70 or remi-php71) updates from the channel for your version:
yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum --enablerepo=getpagespeed-extras-php71 update 'php*' libicu-last libwebp
service php-fpm restart # or: service httpd restart
Replace php71 with php70 if that is your version. Enable the channel only for the transaction, as shown. It carries base-name php, so leaving it on would offer that version to any later yum update.
Starting from a fresh CentOS 6 host? Swap update 'php*' libicu-last libwebp for install php-cli php-fpm plus the extensions you need. No EPEL is required: the libraries these builds need beyond CentOS 6 itself come from the GetPageSpeed repository.
What PHP2Shell is
The PHP security team published two critical advisories on October 21, 2026: GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp. 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, and the next request served by the same worker can use it before normal initialisation resets it.
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.
Why CentOS 6 servers are stuck
CentOS 6 reached end of life on November 30, 2020, so its stock PHP 5.3.3 will never get another package. The PHP project fixed only its supported branches and published source backports for 7.4, 8.0 and 8.1. It published nothing for PHP 7.3 and older. Remi’s CentOS 6 repositories are archived, with nothing new arriving in them.
That left a CentOS 6 host with four options: port the patch and rebuild PHP by hand, pay a commercial extended-support vendor, migrate the whole server this week, or stay exposed.
Is PHP 5.3 affected?
The advisory’s published range starts at PHP 5.4, and nobody at the PHP project assessed 5.3: it left support in 2014. So treat “5.3 is not listed” as “not checked”, not as “safe”.
The underlying pattern is older than 5.4. On stock CentOS 6 PHP 5.3.3 the out-of-memory path unwinds in the same way that CVE-2026-109618 abuses, and the probe below reproduces that behaviour. It proves the unsafe unwind, not a working exploit against 5.3. The stale-state code that the fix resets is there too, apart from session upload progress, which only arrived in 5.4.
GetPageSpeed patched 5.3 anyway: an unassessed branch serving the public internet is not a risk worth carrying. The PHP2Shell checker marks stock 5.3 as vulnerable on the same reasoning.
The GetPageSpeed fix for each PHP version
| PHP | Replaces | Install from | Current build | First with the fix |
|---|---|---|---|---|
| 5.3 | stock php-5.3.3 |
main repository | 5.3.3-54.el6 |
5.3.3-51.el6 |
| 7.0 | Remi remi-php70 |
getpagespeed-extras-php70 |
7.0.33-52.el6 |
7.0.33-49.el6 |
| 7.1 | Remi remi-php71 |
getpagespeed-extras-php71 |
7.1.33-42.el6 |
7.1.33-40.el6 |
The 7.0 and 7.1 builds carry a port of the official PHP 7.4 fix. The 5.3 build adapts the same fix from our 5.4 port, and adds the string overflow checks that 5.3 never had. Each version’s page lists every security fix it carries, because these builds cover much more than PHP2Shell.
Package names match what you run today, so the update is in place. Configuration files stay where they are, and the PECL extensions already on the server keep loading because the PHP API and ABI do not change. CentOS 6 builds are base-name php-* only, with no software collections, and x86_64 only.
Oracle (oci8). The 7.0 and 7.1 channels ship php-oci8, built against Oracle Instant Client 18.5, the newest client Oracle published for Enterprise Linux 6. Install it from Oracle first, since GetPageSpeed does not redistribute Oracle’s libraries.
How the builds were validated. In a clean CentOS 6.10 container, the test harness installs the exact package each build replaces (stock 5.3.3-49, Remi 7.0.33-23 and 7.1.33-10) and proves the out-of-memory probe shows the vulnerable behaviour there. It then upgrades from the published repository and checks that:
- the probe is fixed;
- no PHP module was lost;
- pages still serve through Apache mod_php;
- a fresh install works as well, with no EPEL.
All six scenarios passed on November 2, 2026.
Check whether your CentOS 6 server is vulnerable
rpm -qa 'php*-common' --qf '%{NAME}-%{VERSION}-%{RELEASE}\n'
A release ending in .el6.remi, or a stock el6_10 build, is vulnerable. After the update you should see a GetPageSpeed release from the table above, such as php-common-7.1.33-42.el6.
You can also test the out-of-memory fix directly. It only exhausts a 4 MB limit in one CLI process:
php -n -d memory_limit=4M -r 'str_repeat("x", 64 << 20);'; echo "exit code: $?"
Exit code 255 means the vulnerable unwinding is still there. Exit code 1 means the fix is in place.
Rollback and caveats
Take a snapshot before updating. We test upgrades on CentOS 6, not downgrades, and Remi’s CentOS 6 repositories are archived, so a snapshot is the rollback you can rely on.
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.
Finally, on CentOS 6 these packages cover PHP only. The kernel, OpenSSL, glibc and the rest of the base OS stay as CentOS 6 left them, so plan the migration. Everpatch for CentOS 6 has the full scope. Moving to CentOS 7 first? Everpatch for CentOS 7 also covers a current LTS kernel and maintained base packages.
FAQ
Is PHP 7.1 on CentOS 6 affected by CVE-2026-109618?
Yes. PHP2Shell affects every branch from 5.4 onwards, and Remi’s last CentOS 6 build of PHP 7.1, 7.1.33-10.el6.remi, predates the fix. Run yum --enablerepo=getpagespeed-extras-php71 update 'php*' libicu-last libwebp.
What about PHP 5.4, 5.6, 7.2 or newer on CentOS 6?
GetPageSpeed builds 5.3, 7.0 and 7.1 for CentOS 6 today. If you run another branch, tell us which one.
Which PHP2Shell patch version do I need on CentOS 6?
At least 5.3.3-51.el6, 7.0.33-49.el6 or 7.1.33-40.el6, and preferably the current build from the table above. The PHP version number does not change with the patch, so compare the package release with rpm -q php-cli rather than trusting php -v.
Is there a PHP 5.3 security patch for CentOS 6?
Yes. php-5.3.3-54.el6 in the main GetPageSpeed repository is a drop-in update for the stock CentOS 6 packages, with the PHP2Shell fix and a long list of older security fixes. After installing the release package, run yum update 'php*'.
When did CentOS 6 reach end of life, and does it still get updates?
CentOS 6 reached end of life on November 30, 2020. The CentOS project publishes nothing new for it, and the vault only keeps the old packages available. GetPageSpeed keeps the PHP layer patched, not the rest of the operating system.
Will updating WordPress or its plugins fix PHP2Shell?
No. PHP2Shell is a flaw in PHP itself, and a demonstrated exploit fires before any application code runs. Only updating PHP fixes it.
Do I need a GetPageSpeed subscription for the PHP2Shell fix?
Not for personal, development or evaluation use: the packages install from the public GetPageSpeed repository with no signup. Commercial production use requires GetPageSpeed Ultra ($500/year, up to 10 servers running your own services) under the repository terms. Administering servers for clients, or more than 10? GetPageSpeed Fleet starts at $800/year.
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. On PHP 5.3 the setting does not exist at all.
Will a WAF or NGINX in front of PHP stop it?
Only partly. For what NGINX can and cannot block while you schedule the update, see PHP2Shell mitigation in NGINX.
Conclusion
PHP2Shell on CentOS 6 is a critical, unauthenticated remote code execution with no distribution or upstream fix. The GetPageSpeed builds for PHP 5.3, 7.0 and 7.1 close that gap in place, validated, and free to install.
Running these servers for a business? Commercial production use requires GetPageSpeed Ultra ($500/year, up to 10 servers). Every new PHP CVE has to be ported again to branches upstream abandoned years ago. Ultra funds that work and keeps up to 10 servers patched for the next one.