PHP2Shell: Two Critical PHP Bugs That Let Hackers Take Over Web Servers

If you have a website or a server running PHP, stop reading for a second and go update it. Seriously.

On October 21 the PHP team released emergency updates for two critical bugs, nicknamed PHP2Shell. With them, an attacker can run their own code on your web server just by sending it a specially crafted request. No password, no account, no clicking anything. Just one request and the server is theirs.

And PHP is everywhere: WordPress, Drupal, Joomla, tons of hosting control panels… so this one is big.

What happened

The bugs were found by the researchers at Wiz, who reported them to PHP on August 24. Both are memory bugs called use-after-free: PHP throws away a piece of memory but then keeps using it. It’s like throwing a page of a book in the bin and then trying to keep reading it, except an attacker can secretly write on that page first. That’s how they take control.

• CVE-2026-109618 is in how PHP handles running out of memory and file upload progress. Wiz also used it to leak memory from the server.
• CVE-2026-109619 is in things PHP keeps between requests, like fatal error handling and OPcache.

Wiz showed working attacks against WordPress, Drupal and Joomla sites without logging in. And here’s the crazy part: they say AI models helped them turn these old, hard-to-exploit bugs into working attacks. That’s great for the good guys finding bugs faster… but the bad guys have the same AI tools.

How bad is it compared to other famous bugs?

To put it in perspective, here’s how it compares to two of the most famous internet bugs ever:

In my opinion it’s not quite as bad as Log4Shell. That one was hidden inside thousands of Java programs and a lot of people didn’t even know they were using Log4j. Here at least you know if you run PHP. But PHP powers a huge part of the web, so the number of servers exposed is massive, and a lot of small sites never update.

Am I affected?

If your server uses PHP to answer web requests, assume yes. It doesn’t matter how it’s set up: Apache with mod_php (the most at risk), PHP-FPM (Nginx and most hosting), php-cgi, LiteSpeed or FrankenPHP. And the bugs go back years, so old versions are affected too.

On 8.1, 8.0 or 7.4 you can only get the fix from your Linux distro or your hosting provider. On 7.3 or older there’s no fix at all, so it’s time to upgrade.

Are hackers already using it?

Depends who you ask. The security company watchTowr says it’s seen attacks against its honeypots (fake servers made to catch hackers) since October 21, the same day the patches came out. The US agency CISA said in its alert that it hadn’t seen successful attacks yet. Either way, the details are public now, so it’s only a matter of time. Treat it as urgent.

What you should do

1. Check your PHP version. On the server run php -v. To see the version your website really uses, check your hosting panel, or make a page with <?php phpinfo(); ?> (and delete it right after!).
2. Update. On Debian or Ubuntu: sudo apt update && sudo apt upgrade, then restart your web server or PHP-FPM. On shared hosting, check that your provider already updated, or pick a fixed version in the panel.
3. Can’t update yet? Take the site offline or limit who can reach it. A web firewall (Cloudflare and others already have rules for this) helps for now, but it’s not a real fix. PHP itself says no setting fully protects you.
4. Watch for signs of an attack: lots of 500 errors, “memory limit” errors, weird or huge PHPSESSID cookies, PHP processes crashing and restarting, or PHP launching shells and downloading files.

Timeline

• Aug 19, 2026Wiz finds the first bug
• Aug 20–21Remote code execution confirmed on Drupal and WordPress
• Aug 24Bugs reported to the PHP security team
• Sep 21PHP confirms and starts working on a fix
• Oct 21Patches released and details made public. watchTowr reports the first attacks
• Oct 23CISA updates its alert with detection rules