AI Found a Hole Under Most of the Web. Is Your Website Exposed? | Edition 354

On Wednesday, the NSA told organizations running PHP to patch now, and if an immediate update isn't possible, to take the system offline until it can be fully fixed. CISA, America's cyber defense agency, went further: if you can't patch, or you're on PHP 8.1 or older, take PHP-based systems offline.

PHP isn't some niche tool. It runs underneath roughly 7 in 10 websites with a detectable server language, including every WordPress site. If you have a website for your business, your church, your practice or your side hustle, there's a good chance it runs on PHP.

The flaw is called PHP2Shell, and an AI found it. Amazon caught someone testing it four days before the public knew it existed. The Wikimedia Foundation, which runs Wikipedia, took a number of systems down as a precaution. Pokémon HOME, Champions and Sleep went into emergency maintenance right as the patches dropped. Overseas, entire government websites went dark.

Here's what happened, how to tell whether you're exposed, and exactly how to fix it on WordPress, Linux and Windows.

What happened, super simplified

Think of PHP as the engine. WordPress, WooCommerce, Drupal, Joomla and Magento are the car bodies bolted on top. PHP2Shell is a defect in the engine. Updating WordPress repaints the car, and the engine stays broken.

The two flaws live in how PHP manages a server's memory while it handles web requests. One lets half-built data get treated as valid after the server runs low on memory. The other lets leftover data from one request leak into the next. Chained together, they let an attacker run their own code on the server with no password and no login.

Once that happens, an attacker can steal customer data, plant malware, or turn your site into a weapon against the people who visit it. PHP rates both flaws 9.2 out of 10, and it says the risk is highest on servers running Apache with mod_php, a very common setup.

PHP shipped the fix on October 21 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Its official advisory is blunt: there are no complete workarounds, and updating is the only safe choice.

The AI twist

According to the Wall Street Journal, a researcher at the security firm Calif found the flaws in August with help from OpenAI's GPT-5.6 Sol, during a code audit OpenAI funded. The weak spot had been flagged decades earlier and written off as too hard to exploit. The AI found a way in. Google's Wiz team then found more exploits on its own.

Wiz says these flaws rank among the most severe ever found in PHP, and arguably in the history of software. The fix was huge: close to 200 files and more than 10,000 lines of code.

The flip side is that the same AI that finds a flaw can read a patch and write an attack. That's why the researchers kept it secret for two months. It leaked anyway, in a Hacker News post two days before the planned release, and PHP rushed the patch out a day early.

The timeline

• Aug 11: Calif reports the first flaw to PHP's security team.
• Oct 17: Amazon's honeypot network logs an exploitation attempt, four days before disclosure.
• Oct 20: Details leak online. PHP warns admins to stand by for an emergency release.
• Oct 21, 10 a.m. ET: Patches ship. Cloudflare says attack attempts jump to tens of thousands in the first 45 minutes.
• Oct 21–22: Hosts race to patch. Sites go into maintenance mode across Europe. Amazon's CJ Moses writes that PHP2Shell is now being broadly exploited in the wild.

Who fixes yours?

This is the question most site owners can't answer, and it decides everything.

Host status is changing by the hour. As of early Thursday, GoDaddy said Managed WordPress and Windows Hosting were patched, regular Web Hosting patches were rolling out, and VPS owners must update PHP themselves. Kinsta and InMotion were still mid-rollout on some plans, and SiteGround had disabled the vulnerable features rather than naming a patched build. Check your host's status page for the latest.

The 5-minute check for WordPress

1. Log in to WordPress and go to Tools → Site Health → Info → Server. Write down the full PHP version, like 8.3.36, not just 8.3.
2. Compare it to the fixed versions: 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or newer on the same branch. If yours is lower, your host may not have patched yet. One catch: some hosts, like Hostinger, patched without changing the version number, so ask your host or look for a PHP build date of October 21, 2026 or later.
3. If you're on 8.1, 8.0, 7.4 or older, there's no patched release you can install. Move to PHP 8.3 or 8.4, after testing on a copy of the site.
4. Email your host (template below) and keep the reply.

Don't install a "PHP2Shell fix" plugin or a code snippet from a forum. The flaw sits below WordPress, so no plugin can fix it, and unofficial fixes are a classic way to sneak malware onto a site.

If you run your own Linux server

Linux distributions got the patches ahead of time, so for most servers this is a normal package update plus a restart.

• Ubuntu and Debian: run your normal package update for PHP, then restart PHP-FPM and Apache. Ubuntu has fixes for every supported release, including older ones under extended support.
• Red Hat, Alma and Rocky: update the PHP packages from your distribution, then restart. Patched packages are out, but some advisory listings were incomplete as of Thursday, so confirm the installed version afterward. If you use the volunteer-run Remi repository, PHP's advice was to switch to distribution packages or build from source, because Remi wasn't ready on day one.
• cPanel and Plesk: update through the panel. Plesk has fixed builds, including rebuilt older branches.
• Docker: rebuild your images from patched base images. Patching a running container leaves the image itself exposed.

The step everyone forgets: restart every PHP process. Running workers keep the old, vulnerable code in memory until they restart. And check the version your website uses, not just the command-line version. They can be different installs.

If you run Windows Server with IIS

Windows isn't the main target, but it's in scope. IIS runs PHP through FastCGI as php-cgi.exe, so every PHP site on IIS is exposed until it's updated.

1. Download the Non Thread Safe build of PHP 8.4.27 or 8.5.12 from windows.php.net.
2. Stop the sites that use PHP, or stop IIS.
3. Replace the PHP folder IIS points to, keeping your php.ini.
4. Restart IIS or recycle the application pools. This step matters: old php-cgi.exe workers keep serving requests with the vulnerable code until they're restarted.
5. Confirm the new version with a real page load.

Also hunt for forgotten copies. Vendor software often bundles its own php.exe or php-cgi.exe without saying so, and those need updating too.

How to test whether you're exposed

• WordPress: the Site Health check above is the fastest test for most people.
• For IT pros only: Searchlight Cyber's team released a free, open-source php2shell-scanner. It's a command-line tool that stress-tests the server and can knock PHP workers over, so run it only on servers you own, ideally off-hours. Everyone else: stick to the version check and your host's word.
• Quick look from outside: some servers announce their PHP version in a response header called X-Powered-By. Many hide it, so a missing header doesn't mean you're safe.

Can't patch today?

• Put Cloudflare in front of your site. Cloudflare says customers using its free or paid firewall are protected by default. Its own CTO calls this a stopgap, so patch anyway.
• If you take the site down, do it right. Google's John Mueller advises returning an HTTP 503 status instead of letting pages time out or return errors, so your search rankings survive.
• Temporary config changes buy time, not safety. PHP's advisory lists stopgap settings for server admins, such as turning off session upload progress, but says they reduce exposure without making a server safe. The security firm watchTowr goes further and calls config-file changes ineffective.

Did someone already get in?

Amazon's security team advises checking for suspicious activity going back to October 17, not just since the patch. Warning signs include:

• Admin accounts you don't recognize
• Files you didn't change, especially new .php files in upload folders
• PHP processes launching command shells or download tools
• Strange outbound traffic or sudden spikes in server load

If you see any of these, treat the server as compromised. Rotate every password and API key it holds, and bring in help.

How worried should you be?

Experts disagree, and that's worth knowing. The security firm Sansec now says mass exploitation is less likely than it first feared, because an attack needs specific conditions on the target server, and the public exploits don't work on a default install. Calif, which found the flaws, says they are exploitable on default setups. Amazon says the attacks are already widespread, and Cloudflare's CEO says attempts reached the millions. An attempt isn't a break-in, but enough attempts across enough unpatched servers will find the ones that are exposed.

You don't need to settle that argument. Checking your PHP version takes five minutes, and the email to your host takes two.

The bottom line

PHP2Shell is a preview of how security works now that AI is doing the hunting. The new normal is that bugs get found faster, patches get reverse-engineered faster, and the gap between "fixed" and "attacked" shrinks to hours. Knowing who patches your website, and how fast they do it, is now part of running a business.

Key links: PHP security advisory · PHP downloads · Wiz technical write-up · Amazon threat report