On October 21, 2026, the PHP team shipped four emergency security releases to fix two flaws rated 9.2 out of 10. Nicknamed PHP2Shell, these PHP vulnerabilities let an unauthenticated attacker take over a web server. And PHP runs about 70% of websites worldwide, including every WordPress site.
On paper, the fix is simple: update and move on. In reality, many business leaders are finding out this week that they don't know who is supposed to run that update on their website.
This article covers what happened, what you need to check this week, and why this alert is really a governance question: who actually looks after your website? 👇🏼
The timeline matters, because it shows how fast this moved. Amazon spotted a first exploitation attempt on October 17 in its honeypots, four days before the patches. On October 20, the CVE identifiers (CVE-2026-109618 and CVE-2026-109619) leaked on the Hacker News forum (Y Combinator). That evening, PHP published an advance notice confirming the patches for the next day.
The patches landed on October 21 at 14:00 UTC. That same day, Amazon wrote that the flaw was already "being broadly exploited in the wild". In the UK, the NCSC asks organizations to apply PHP's temporary mitigations until they can update. If those aren't possible or would take too long, it advises considering taking systems offline. In the Netherlands, several public services were shut down as a precaution.
Most flaws live in a plugin or a theme. This one sits in PHP itself, the engine that runs your website. According to the official advisory, every installation serving web requests is at risk, whatever the setup (PHP-FPM, Apache, LiteSpeed and others).
Wiz researchers demonstrated remote takeover of the latest WordPress, Drupal and Joomla images. They also describe a memory leak that can expose passwords, tokens and API keys. Patchstack sums it up: a WordPress site is exposed regardless of its plugins if it runs a vulnerable PHP version.
Affected versions go all the way back to PHP 5.4. Only the 8.2 to 8.5 branches get a proper release. For 7.4, 8.0 and 8.1, PHP only published minimal source patches, and below that there's nothing. Yet according to Mallory data cited by The Hacker News, around 884,000 internet-facing servers report PHP 8.1 or older. That's 59% of those that show their version.
You don't need to be technical to drive these checks. You do need written answers, with a name next to each line.
⚠️ Watch out for shortcuts. PHP says its temporary settings reduce exposure but do not make an installation safe. Cloudflare calls its firewall rules a stopgap, and they only cover traffic routed through Cloudflare. Patchstack also warns against unofficial "fix" plugins.
If your site runs PHP 8.2 or later, a decent host can often update it in minutes. On 8.1 or older, you're looking at a migration. Either way, someone has to own it, and so many sites no longer have anyone on the other end of the line.
The site was delivered five years ago by an agency that no longer supports it. The shared hosting plan sits on the founder's credit card. The freelancer who had the logins has moved on. The result: when a critical alert hits, nobody knows where to look or who to call. Rapid7 recommends updating "on an emergency basis, outside of normal patch cycles". Amazon goes further: for critical internet-facing flaws, patch timelines should be measured in hours, not days.
Here's a typical case we come across: a B2B manufacturer with a WordPress brochure site on PHP 7.4, launched in 2020. Its contact form pushes leads into HubSpot using a private app token stored in a plugin. With PHP2Shell, the site could be defaced, and the bigger risk lies elsewhere: the token could leak and open the door to your CRM, with your contacts, your deals and your full conversation history.
Put simply, your website isn't a project you closed at launch. It's a way into your sales data.
If your company runs PHP anywhere in its stack, here's the audit we recommend running now:
Then comes the bigger decision. If the site needs to stay on PHP, it needs maintenance under contract, with a named person who can react within hours. If the site no longer has an owner, we often recommend moving it to a website built on HubSpot Content Hub. It's a hosted CMS: you don't run any PHP server, and the vendor maintains the infrastructure. That option doesn't suit every project, and we go through the criteria in our comparison of headless CMS vs. HubSpot CMS.
For sites already on HubSpot, the risk moves to integrations: a custom connector hosted on a PHP server is still exposed. Our technical audit checklist and our API and back-end integration work cover exactly that.
At the end of this audit, you have a written inventory of your sites and their PHP versions, a list of the tokens and keys to rotate, and a named owner for each site. Want to run it with us? Book a call with our team.
PHP2Shell is a critical PHP vulnerability, already exploited, that affects almost every version in use. Updating is the only real protection, and anything older than 8.2 means a migration.
The lesson goes beyond this alert. A website without a named owner is a risk for your brand, and also for your CRM and your customer data.
if/else tip: write down today the name of the person who patches each of your sites. If the box stays empty, you've found your priority.
Not sure who looks after your website? Let's talk.