PHP2Shell: what this week's PHP flaw is and what to do if your site runs on PHP
· 6 min read
On Wednesday, October 21, the PHP team released emergency updates for two critical security flaws, nicknamed PHP2Shell (CVE-2026-109618 and CVE-2026-109619). Both let someone on the internet, with no username or password, run code on the server with the web process's privileges. In practice, that means taking over the application and everything it can read: the database, uploaded files, the keys to its integrations.
PHP powers most websites whose server-side language is known: W3Techs puts it at 69.3%. That includes WordPress, WooCommerce, Drupal, Joomla, Magento and a large share of custom systems built with Laravel or Symfony. If your business has a website, there's a good chance this affects you.
What happened, plainly
These are two separate bugs in PHP itself, not in a plugin or a framework. The first (CVE-2026-109618) shows up when a request runs out of memory at a delicate moment: PHP stops halfway and, while cleaning up, treats data it never finished preparing as valid. The second (CVE-2026-109619) is a leftover from a previous request that keeps pointing at memory already freed, which the next request handled by the same process can take advantage of. Both score 9.2 out of 10 on CVSS 4.0; the scores of 10 that circulated early on were a mistake, according to the PHP Foundation.
What makes them serious is their reach. They affect every common way of serving PHP —PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed— and the oldest vulnerable code found dates back to PHP 5.4, from 2012. The PHP team itself flags Apache with mod_php as the highest-risk setup, because the demonstrated attack happens before a single line of the application runs: it doesn't matter how well your WordPress or your system is written.
Attacks have already started
Disclosure was planned for October 22 and moved up a day because the flaw identifiers leaked on the 20th. But attacks began earlier: Amazon detected a first attempt on its honeypot network on October 17, four days before the announcement, and on the 21st saw more attempts suggesting several different attackers. Cloudflare and watchTowr also report exploitation attempts.
There are nuances, and it's worth not overstating them. As of October 22, Rapid7 reviewed the public proofs of concept and found each one works only against a specific combination of operating system, PHP version and web server; none is a general, reliable attack. That's not a reason to wait: it's the window to update before someone closes it. And a practical warning: code claiming to exploit these flaws is circulating unverified, and it may carry malware.
Updating is the only complete fix. Everything else reduces the risk, but doesn't remove it.
Which versions are fixed
The safe versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35 or later, each on its own branch. Any earlier version on those branches is vulnerable. Linux distributions and extended-support vendors received the patches in advance, so if PHP comes from your system packages, the right move is to apply your vendor's update.
The trouble is with old versions. For PHP 7.4, 8.0 and 8.1 —no longer supported— the PHP team only published source-code patches, with no ready-to-install releases. For anything older than 7.4 there's no fix at all. If your site runs on one of those versions, this flaw isn't solved with a patch: it's solved by moving to a supported version, which needed doing anyway.
What to do today, depending on how your site is hosted
If you're on shared or managed hosting (the usual setup for a WordPress site on Hostinger, SiteGround, GoDaddy and the like), you don't control the server's PHP version: your provider does. Write to them today and ask something specific: whether they've applied the PHP2Shell patches and which version your site is on now. Many control panels show the PHP version; if yours is 8.1 or older, ask to move to a supported one and test the site afterwards.
If you have your own server (a VPS, a container, a machine in the office), it's on you or whoever manages it: update PHP to the fixed version for its branch and restart every PHP process, because the ones still running keep the old code in memory. Check your Docker images too: an image built last week ships the vulnerable version even if the server itself is up to date.
If you can't update today, there are measures that reduce exposure in the meantime. The ones published by the PHP team are setting memory_limit=-1 in a way the application can't override, disabling session.upload_progress.enabled and, on PHP 8.5, disabling fatal_error_backtraces, always from the server configuration and restarting the processes afterwards. Cloudflare enabled firewall rules for the known attacks, even on the free plan, but they only protect traffic that goes through Cloudflare. None of these replaces the update: they change memory and upload limits, so they're best applied by someone who knows what they're changing. Especially the first one: with no memory limit, a single heavy request can exhaust the whole server's RAM and take the database down with it; on a small server, that's a risk in itself.
And after updating, look back. Amazon recommends reviewing activity from October 17 onward. A patch closes the door, but it doesn't tell you whether someone got in before: new or modified files on the server, admin users nobody created, unknown scheduled tasks or odd outbound traffic are all signs worth investigating. Nothing in the logs doesn't prove nothing happened.
What this week leaves behind
One detail of this case deserves attention: the teams that found the flaws say they used AI models in their research. Code that had been in production for over a decade, reviewed by thousands of people, surfaced now. It's reasonable to expect this to happen again, and for those hunting flaws to attack to use the same tools.
The practical takeaway isn't panic, it's maintenance. The sites that get through a week like this best are the ones already running a supported version, with someone who has the access and the judgment to update the same day, and a client who knew whom to call. The ones that struggle are the ones nobody has touched since they were delivered, on a PHP 7 nobody dared to migrate, with a provider who no longer answers. That's why we insist that accounts and access belong to the client: when you need to act fast, you can't depend on finding whoever holds the key.
If you don't know which PHP version your site runs on, or who's responsible for updating it, that's the first problem to solve, before this flaw and before the next one.