On Tuesday, October 21, the PHP project released emergency fixes for two critical security flaws, CVE-2026-109618 and CVE-2026-109619, now known collectively as “PHP2Shell.” PHP is the programming language that runs WordPress, and by extension about seven out of every ten websites on the internet. Both flaws let an attacker with no login run their own code on a web server just by sending it a specially crafted request. GillyTech servers were protected at three separate layers, with the first in place before PHP even published its fix, and the PHP packages themselves installed within minutes of reaching our provider’s update channel. Every client website and every GillyTech system is covered. Then we wrote this.
What the Flaws Actually Are
Both issues live deep inside PHP itself, not in WordPress, not in a plugin, and not in a theme. That matters, because it means every PHP website in the world was exposed at the same time regardless of how well it was built or maintained. Both carry a severity score of 9.2 out of 10 on the CVSS scale, the industry’s standard rating for how bad a vulnerability is. Anything above 9 is reserved for the worst of the worst.
CVE-2026-109618 is a flaw in how PHP cleans up when it runs out of memory. If an attacker sends a request that pushes the server past its memory limit at exactly the right moment, PHP’s cleanup routine ends up working with half-built data, and the attacker can steer that into running their own code.
CVE-2026-109619 is what security researchers call a “use after free.” A web server reuses the same PHP worker process for request after request to save time. This flaw let leftover information from one request linger into the next one, pointing at memory that had already been released. An attacker who understood the pattern could use a later request to read, and in some cases write, memory they should never have been able to touch. PHP’s own advisory confirms memory disclosure as a real-world impact.
The plain-language version: a stranger on the internet could send your website a few carefully shaped requests and, if they got it right, take over the server account your site runs under. From there they can install malware, steal data, send spam, or use your site to attack others. No password required. No plugin vulnerability required.
Why This One Was Messier Than Usual
Normally a security fix is coordinated: the vendor quietly prepares patches, operating system maintainers get them in advance, and everything goes public at once. This time the CVE identifiers leaked on October 20, a day before PHP intended to publish. PHP moved its release up to October 21 at 14:00 UTC (10:00 AM Eastern) to close the gap. Amazon’s threat intelligence team later reported it had seen exploitation attempts against its honeypots as early as October 17, four days before anyone outside the research community knew what to look for. By the evening of October 21, public proof-of-concept exploit code was circulating, Cloudflare was reporting early attacks, and multiple vendors were calling exploitation “broad.”
In other words, this was not a drill, and the window between “fix available” and “attackers actively trying it” was measured in hours.
Affected and Fixed Versions
- PHP 8.5 before 8.5.12 (fixed in 8.5.12)
- PHP 8.4 before 8.4.27 (fixed in 8.4.27)
- PHP 8.3 before 8.3.36 (fixed in 8.3.36)
- PHP 8.2 before 8.2.35 (fixed in 8.2.35)
- PHP 7.4 through 8.1: no official release, but PHP published source patches and vendors like CloudLinux and cPanel built backports
- PHP 7.3 and older: end of life, no fix from the PHP project. The vulnerable code goes back to PHP 5.4, released in 2012.
Every way of running PHP on a web server is affected: PHP-FPM, Apache’s mod_php, php-cgi, FrankenPHP, and LiteSpeed. Researchers at Calif confirmed working pre-login remote code execution against current versions of WordPress, Drupal, Joomla, and Magento.
Three Layers, Three Timestamps
Every GillyTech and HyperPress server runs the same stack: cPanel as the control panel, CloudLinux as the operating system, and Imunify360 as the security layer, all on top of LiteSpeed Web Server Enterprise. For this event, each of those vendors shipped its own piece of the defense, and each piece landed on our servers as soon as it existed.
Layer 1: Imunify360 blocked the attacks before the fix existed
Imunify360 is a web application firewall, a filter that inspects every request before it reaches the website and drops anything that looks like an attack. CloudLinux, the company behind it, had early access to the research and pushed its first PHP2Shell ruleset (8.83) at 09:08 UTC on October 21, almost five hours before PHP’s public release. Two more rulesets followed the same day: 8.84 at 13:07 UTC, which added the rule that actively blocks on LiteSpeed servers like ours and stops the public exploit tool by its signature, and 8.85 at 17:17 UTC, covering further variants. Rulesets arrive on our servers automatically, so this layer was live with no action on our part. Attackers caught scanning for these flaws also get flagged by Imunify360’s IP reputation system and challenged before they can touch anything else.
To be clear about what a firewall rule can and cannot do: it is a virtual patch. It stops the attack patterns it knows about. CloudLinux itself states that as of October 22 no rule covers the out-of-memory path in CVE-2026-109618. That is why the firewall alone was never going to be enough, and why the next two layers matter.
Layer 2: CloudLinux shipped patched PHP packages
CloudLinux builds its own PHP packages for cPanel servers (the ea-php series) and for its per-site PHP Selector (the alt-php series). Rather than wait for a version bump, CloudLinux backported the fix into the existing versions and pushed them to its stable update channel on the evening of October 21 UTC, with the full set for CloudLinux 7, 8, and 9 completed by 00:07 UTC on October 22. We installed the moment they appeared. The patch reference is EA4D-1101.
This is also why a few clients noticed their site still reports PHP 8.5.11 rather than 8.5.12. The fixed CloudLinux build is 8.5.11-2: same version number, patched code. The proof is in the package changelog, not the version string, and we verified it on every server. We will move to the plain 8.5.12 release once it comes through as a standard update, but there is no security difference between the two.
CloudLinux also gives us CageFS, which walls each hosting account off from every other account on the server. Even in a worst case where one site were compromised through a flaw like this, CageFS keeps the attacker inside that single account rather than handing them the whole machine.
Layer 3: cPanel’s own PHP and service restarts
cPanel published the fix through its EasyApache 4 package system (change log 25.91) on October 21 and separately patched the internal copy of PHP that powers the cPanel interface itself. Both went in. The step most people skip is the one that actually makes the patch take effect: PHP worker processes keep the old code in memory until they are restarted. We restarted LiteSpeed and PHP-FPM on every server immediately after the packages installed, and then confirmed the running version matched the installed one.
What This Means for Our Clients
Nothing to do. Every website hosted with GillyTech and every HyperPress site is running patched PHP behind an updated firewall, and every internal GillyTech system (our monitoring, automation, invoicing, and analytics platforms) was patched on the same timeline. If you received a vulnerability notice from a scanner or a security newsletter, you can note the CloudLinux patch reference EA4D-1101 and re-run your check. The version number may still read 8.5.11 for the reason explained above.
If You Run Your Own Server
On a cPanel server with CloudLinux, the update is a regular package update, not a security-only one, because the security metadata had not been published at the time of writing:
yum clean all
yum update "ea-php*" "alt-php*"
/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpmThen confirm the fix is really in the package. The version number will not tell you; the changelog will:
rpm -q --changelog ea-php85-php-cli | grep -E 'CVE-2026-(109618|109619)'Empty output means you are still vulnerable. Repeat for each PHP version your sites use. If you run Imunify360, check that your ruleset is 8.85 or newer. If you cannot patch right away, PHP’s interim advice is to set session.upload_progress.enabled=0 in your server-level PHP configuration (not in a .user.ini file, which loads too late) and restart all workers. That reduces exposure to the second flaw only. Updating is the only complete fix.
The Question Worth Asking Your Host
Not “are you patched,” because everyone will say yes eventually. The question is “when.” PHP’s fix went public at 10:00 AM Eastern on a Tuesday. Attackers were already probing for it. A host that patches on its next scheduled maintenance window, days or weeks later, left every site it runs exposed through the most dangerous stretch. A host with no firewall in front of PHP had no protection at all until the packages were installed. If your host cannot tell you the hour its servers were updated, or does not know what Imunify360 ruleset it is on, that is your answer.
Want your hosting handled by people who patch first and post second? Schedule a call and we will talk about moving your site to HyperPress managed WordPress hosting.
Company News
Every Layer Under a Website Got More Expensive This Year. Our Hosting Prices Did Not.
Oct 12, 2026
