On the morning of October 21, a lot of website owners found out something they’d never thought to ask: which version of PHP their site was running. Within hours, the answer had become urgent. PHP’s maintainers released emergency patches for two critical flaws that let an attacker run commands on a web server without logging in, and security researchers were already seeing attempts to use them.
For most businesses, PHP isn’t something anyone chooses day to day. It sits quietly underneath the website, doing its job, maintained by a hosting provider or an agency. That’s exactly why a flaw in PHP itself is so unsettling. You can’t fix it by updating a plugin or changing a setting in your content management system. And the same week brought a cluster of other serious incidents, enough that some security write-ups started calling it Black October.
In this post we’ll look at what happened, what it shows about how AI is changing vulnerability research, and what to do about it, with a practical checklist you can hand to whoever looks after your site.
What Happened on October 21
Two critical flaws in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619, each scored 9.2 out of 10 on the CVSS v4 scale, and they affect every PHP release going back to version 5.4.
Together they’re known as PHP2Shell. They were discovered by researchers at Calif, OpenAI and Wiz, and they can allow remote code execution on servers that handle web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Wiz’s write-up said the flaws could enable code execution on WordPress, Drupal and Joomla sites, and its headline put the exposure at around 70% of the internet. That figure is an estimate of PHP’s reach, not a count of compromised sites.
PHP’s own security team said it considered the risk highest for mod_php.
The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and earlier are no longer supported upstream, which means there’s no regular fix for them: if your site runs on one of those, the answer is to move to a supported version, not to wait.
How AI Changed the Equation
What makes this episode different is how the flaws were found. Wiz explained that frontier AI models were critical to making the process practical, helping researchers build and adapt working exploits across multiple applications. Another summary of the research notes that these models reduced the barrier that had kept a long-standing weakness from being turned into a working attack.
AI didn’t invent a new kind of hacking here. It made an existing kind faster. The weaknesses were in memory handling, a familiar category of bug, but chaining them into something reliable took expertise and time that AI-assisted researchers could now compress. The same capability is available to attackers, which is why the gap between a flaw being found and being used keeps shrinking.
The Race Between Disclosure and Attack
The timeline shows how little warning there was. Wiz reported the flaws to PHP on August 24, and PHP acknowledged them on September 21. On the night of October 20, details leaked ahead of the planned release. Cloudflare reported early attacks on the morning of October 21, before the patch was published at 14:00 UTC. Amazon’s threat intelligence team said its honeypot network recorded an exploitation attempt on October 17, four days before public disclosure. CISA later added the flaws to its catalogue of known exploited vulnerabilities.
It’s worth being precise about what that means. Attempts to exploit a flaw aren’t the same as successful compromises. On October 27, Wiz said it hadn’t yet seen successful end-to-end exploitation in its own telemetry. That’s reassuring, but it’s a statement about one company’s visibility, not a guarantee, and it doesn’t change the advice: patch.
It Wasn’t Only PHP
The same week brought several other serious incidents, which is what gave the period its nickname.
- Railway, a cloud platform, disclosed on October 21 that an unauthorised party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents. Customers were told to rotate credentials stored before that date.
- Node.js shipped security releases on October 21 fixing ten vulnerabilities, including a high-severity flaw in a bundled decoder that the project said could lead to a crash, memory disclosure or remote code execution.
- GitLab released an emergency patch for a maximum-severity flaw affecting self-managed servers.
One analysis of the month’s incidents noted a common thread: in six of them, attackers ended up with secrets such as API keys, tokens or environment variables. That’s a useful reminder that a website’s real risk often sits in the credentials around it, not just the code running on it.
Why This Matters for Websites Built on PHP
Many business websites run on PHP without anyone thinking of it that way. WordPress does, and so does WooCommerce, which powers online stores such as the one we built for Gutta på Haugen. If your site is managed by an agency or a host, the key question isn’t whether you’ve updated your plugins. It’s whether someone has confirmed, in writing, that the underlying PHP version has been updated.
Updating WordPress, a theme or a plugin won’t patch PHP. The fix has to happen on the server, which is why it often falls between the cracks: the agency assumes the host handles it, and the host assumes the customer asked. This is the kind of ownership gap we address in our web and e-commerce work.
What to Do Now
Confirm your PHP version. Ask your hosting provider or developer which version your site runs and whether it includes the October 21 fix. Get the answer in writing. This will help you identify whether any immediate action is needed.
Move off unsupported versions. If you’re on PHP 8.1 or earlier, plan an upgrade to a supported branch, not a workaround. Make sure the upgrade is tested before it is applied to your live website.
Update everything above PHP too. Keep your content management system, themes and plugins current, and remove anything you no longer use. Abandoned code is an easy target. Regular updates help close security gaps before they can be exploited.
Rotate your secrets. Change passwords, API keys and access tokens, especially any stored with cloud providers affected by the week’s incidents. Review who has access and revoke credentials that are no longer needed.
Add a layer while you patch. A web application firewall can buy time, and multi-factor authentication should be on every admin panel, hosting account, domain registrar and email account. These measures add another layer of protection while updates and fixes are being implemented.
Retire what nobody maintains. Old campaign sites, microsites and legacy portals that nobody updates should be archived and taken offline, not left exposed. Review your existing digital properties to identify anything that is no longer actively managed.
Treat AI agents like new hires. If you’ve added AI agents for customer service, finance or operations, give them only the access they need, require human approval for sensitive actions and keep a log of what they do. Review their permissions regularly as their responsibilities change.
Name an owner. The most valuable step is to make one person responsible for updates and give them a deadline. A clear owner ensures that security tasks are tracked, completed and reviewed rather than left pending.
A PHP2Shell Response Checklist
- Found out which PHP version every site and application runs
- Confirmed with the host or agency, in writing, that the fix is applied (8.5.12, 8.4.27, 8.3.36 or 8.2.35, or an equivalent distribution patch)
- Planned upgrades for any site still on PHP 8.1 or earlier
- Updated CMS core, themes and plugins, and removed unused ones
- Rotated passwords, API keys and tokens, starting with cloud and payment credentials
- Switched on multi-factor authentication for admin, hosting, domain and email accounts
- Checked logs for traffic spikes, new admin users and unexpected files
- Taken unmaintained sites offline or archived them
- Tested that offline backups can actually be restored
- Named a person responsible for security updates, with a review date
Frequently Asked Questions
What is PHP2Shell? PHP2Shell is the name for two critical vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619, that can allow an attacker to execute code on a web server without logging in. PHP released fixes on October 21, 2026.
Which PHP versions fix it? PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and earlier no longer receive regular upstream fixes, so sites on those versions need to upgrade.
Does updating WordPress fix PHP2Shell? No. The flaws are in PHP itself, not in WordPress or its plugins. The update has to be applied on the server, usually by your hosting provider or developer.
Was my site hacked? Not necessarily. Researchers saw exploitation attempts, but an attempt isn’t a successful compromise. Check your logs for unusual traffic, unexpected admin users and unfamiliar files, and rotate your credentials as a precaution.
Will there be more incidents like this? It’s reasonable to expect so. AI-assisted research is finding flaws in older, widely used software faster than before, so patching needs to be a routine habit rather than an emergency response.
Make Patching a Habit
The most useful lesson from the last fortnight isn’t about one language or one week. It’s that the time between a flaw being found and being used keeps shrinking, and AI is part of the reason. Businesses that come through well aren’t the ones with the most sophisticated tools. They’re the ones where someone knows which versions are running, can confirm a fix quickly and has already decided what to do when the next advisory lands.
That’s less dramatic than a headline about an AI-powered threat, and it’s far more useful. We wrote about the same pattern in our look at AI-powered attacks on critical infrastructure, and the answer there was the same: close the exposure before it’s found. If you’d like a clear picture of what your own sites are running, our web and e-commerce team can start with exactly that.
