PHP2Shell: two critical PHP flaws, and when our servers got the fix

Almost every website we host runs on PHP, the programming language behind WordPress and most other website software and online shops. On 21 October the PHP project fixed two critical flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619. The researchers who found them call the attack PHP2Shell.

What the flaws do#

In the attacks published so far, a specially built request, of the kind a web form sends when you attach a file, makes PHP give up partway through, for example by running out of memory. PHP is left holding half-built data, and what it does with that data next can be steered into running the attacker's own code on the server. Another way to use the flaws reads data out of PHP's memory instead, which can include passwords and keys. No login is needed, and both flaws are rated 9.2 out of 10.

They are in every PHP version the PHP project still supports, 8.2 to 8.5, and in older ones too. The researchers showed it working against WordPress, Drupal, Laravel and phpMyAdmin, among others, and against the two programs behind our own client area and webmail, WHMCS and Roundcube.

The fixes were due on 22 October. News of the flaws leaked on 20 October, so the PHP project released them a day early, at about 14:00 UTC on 21 October. Amazon's security team saw a first attempt to use the flaws on 17 October, and more in the early hours of 21 October, before the fix was out; it isn't known whether any of them would have worked. The PHP project's own advice: "There are no complete mitigations, updating is the only safe choice."

When each part of our service got the fix#

All times are UTC.

• Our client area, our website and cPanel itself, including phpMyAdmin: between 14:40 and 14:42 on 21 October, less than an hour after the release.
• Your websites. The PHP on our hosting servers comes from CloudLinux, the company behind their operating system, which builds its own fixed versions. It published the ones our servers use during the evening of 21 October, the last of them just after midnight. Our servers' nightly update installed them at 02:57 on 22 October, and from 02:59 every website we host was running on the fixed PHP, about 13 hours after the PHP release.
• Webmail at webmail.maxinodes.com runs on a server of its own. Its nightly update installed the fixed PHP at 03:49 on 22 October. From the time news of the flaws leaked on 20 October until then, not one form submission reached it.
• JetBackup and WP Toolkit, two cPanel add-ons with their own copy of PHP (JetBackup runs our backups): at 01:14 and 05:52 on 22 October.

Before the fix reached your websites, the web application firewall on our hosting servers, which checks every request before it reaches a site we host, was already blocking the requests the published attack tool sends, from 13:13 on 21 October. That is a second layer, not a fix: it covers only some of the ways the flaws can be reached.

What we found in the logs#

We went through the logs of each of these servers from 17 October, the day of the earliest attempt reported, up to the moment each was fixed. We looked for the signs the researchers describe: PHP running out of memory or crashing while handling an upload, server errors on uploads, and PHP files nobody put there. We found none. The firewall's rules for this attack never fired, and the malware scanner on our hosting servers hasn't flagged a single file since 17 October, including in a full scan of every hosting account that finished after the fix. The one request we did find from a tool built to look for these flaws came at 08:42 on 21 October. It was sent to our hosting server's IP address rather than to any website, and the server's security software turned it away before it reached PHP. Logs can't prove that nothing happened, but none of the signs we looked for are there.

Your PHP version number didn't change#

CloudLinux puts the fix into the PHP version you already have, without changing its number. So on our hosting servers PHP 8.2 still reports 8.2.34 rather than 8.2.35, 8.3 reports 8.3.35, 8.4 reports 8.4.26 and 8.5 reports 8.5.11, all with the fix inside. If a security plugin or an online scanner warns that your site's PHP version has these flaws, that is why. Ask us and we'll confirm the fix is in place for your site.

What you need to do#

Nothing on your hosting with us. Moving a site to us from another host? Check that your current host has installed the fix too: your old site stays online until you sign off the move.

Most websites we host run PHP 8.2, whose support from the PHP project ends on 31 December. Here's how to move to a newer version before then.

The featured image includes the PHP logo by Colin Viebrock, used unmodified under CC BY-SA 4.0.