Threat Intelligence
PHP2Shell: Is Your Business Website at Risk?
An emergency PHP patch landed on October 21. The harder question for most business owners is who holds the hosting login, and what counts as proof the fix is in place.
On October 21 the team behind PHP released emergency fixes for two critical security flaws, now called PHP2Shell. PHP runs WordPress, Drupal, Joomla and Magento, plus most shared hosting platforms. On October 26 the federal Cybersecurity and Infrastructure Security Agency added both to its list of vulnerabilities known to be exploited in the wild, the government's short list of problems to fix now. If your website runs on any of those platforms, it almost certainly runs on PHP, and it may be exposed until your web provider confirms the fix is in place.
Who runs your website's server? For many practices and firms, the answer is not immediately obvious. The fix is routine for whoever holds the hosting login. The harder part is working out who that is.
Why PHP is your problem even if you have never heard of it
Think of your website as a restaurant. The pages customers see are the dining room. PHP is the kitchen: the engine that builds each page, processes your forms and talks to your database.
If an agency, a freelancer or a web designer built your site in the last decade, there is a strong chance PHP is underneath it, and if you are not sure, it is worth checking. Palo Alto Networks (Unit 42) reported more than 22.6 million internet-exposed instances that are potentially vulnerable. Attackers do not pick firms out of a crowd; they scan for any site not yet fixed.
The four dates that matter
October 17. Amazon's threat team later traced an exploitation attempt back to this date. Someone was already trying these flaws.
October 20. Details leaked publicly, according to Huntress, a day before the fix existed.
October 21. PHP released the emergency fixes.
October 26. CISA listed both as actively exploited.
Timing made this one worse. The attempt came first, the details came second, the fix came third. Attackers had a head start. That is why "we will get to it in the next maintenance window" is the wrong posture. The assumption behind it is that nobody is looking yet.
What an unpatched site gives away
Both flaws are rated 9.2 out of 10 for severity, and both let an attacker run code on your web server without logging in, according to University of Washington IT. A stranger can take control of the machine your site lives on.
A defaced or hijacked website. Your homepage replaced, or quietly redirecting visitors to scam or malware sites.
Stolen form submissions. Contact, quote, intake and appointment forms often collect names, phone numbers, sometimes health or financial details.
A foothold into the rest of the business. Passwords, API keys and email settings on that server can be reused against your other systems.
Lost rankings and lost trust. Google flags compromised sites, and customers who see a warning page rarely return.
Compliance exposure. For healthcare, legal and financial firms, a compromised intake form can become a reportable incident.
Why "we updated WordPress" is not an answer
It is usually said in good faith, and it is wrong. The flaw lives in PHP itself, not in WordPress, your theme or your plugins. Automattic, the company behind WordPress.com, said plainly that updating WordPress, a theme or a plugin does not fix the underlying PHP problem, as reported by Newsweek.
WordPress, its themes and its plugins are the dining room, the part your marketing person can change from a browser. PHP is the kitchen, replaced at the server level, usually by the hosting provider or whoever manages it. Updates run from the admin screen will not reach it, but that screen will show which version is running, which is the basis of the request you are about to make.
The versions that contain the fix are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, per CISA, or a vendor build that includes the fix. Confirm rather than assume, because the confirmation is the part you keep.
Older sites are harder. PHP 8.1 and earlier no longer receive official releases, so there is no simple patch, as Elementor has noted, and 35.1% of WordPress sites run a version the PHP project no longer supports, according to CybelAngel. Ask about your oldest site by name: the fix there is an upgrade, your developer may need to test it first, and the right answer is a date, not a same-day fix.
Who actually holds the login
In most small businesses the people who control your website are not in IT: the marketing team, the agency, a freelance web designer, or the company that hosts the site. They hold the hosting logins, which makes this fix theirs to own.
Ask about every site you own: landing pages, client portals, booking and intake sites, and any older site still online but forgotten. Those are often the ones still running unsupported PHP. If nobody can say who manages one, that is a finding in itself; someone should own that answer before the next PHP release, not during it.
The message to send today
Keep it short and specific:
"PHP released emergency fixes on October 21 for two critical vulnerabilities called PHP2Shell (CVE-2026-109618 and CVE-2026-109619). CISA lists them as actively exploited. Please confirm our website's server is running a patched PHP version (8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a vendor build that includes the fix), and send us proof by end of week."
Some hosts ship their own build of PHP; if that is the answer, ask them to state in writing that it includes the PHP2Shell fix.
If you have a WordPress login, you need not wait: Tools, then Site Health, then Info, then Server shows the PHP version.
What counts as proof
Ask for something you can file:
Strong: a screenshot of that Site Health screen. The exact PHP version, down to the patch number, the one detail that answers the question.
Strong: a screenshot of the PHP version in the hosting control panel. The same fact, from the hosting side.
Strong: written notice from the hosting provider that PHP2Shell is patched on your server. The provider has taken responsibility for the fix.
Moderate: a link to the host's status page or blog post. It says the host patched its platform, not that your account was included.
Weak: a verbal or casual "it's handled." Nothing you can verify or show anyone later.
If what comes back is a WordPress version number, a plugin name or "everything is up to date," the question has not been answered. And if your marketing team has already said the site is patched because they ran the dashboard updates, you still do not know.
Worth asking in the same thread, against the same deadline:
1. What PHP version is each of our sites running today? Site by site, not a reassurance about "the hosting".
2. Is that version still supported? If it is 8.1 or older, you want an upgrade plan with a date.
3. Who applies future PHP security updates? And how you will be told when they happen.
4. Were there signs of unusual activity between October 17 and the date the site was patched? That window is where the head start lived.
File what does come back with your other security records; in a regulated industry it is the kind of evidence an auditor or insurer may ask to see.
The wider point
Your website is often the most public part of your business, and PHP2Shell turns an unpatched one into an open door. The patching is not your job. Making sure somebody has done it, and keeping proof that they did, is.
PHP2Shell will not be the last PHP security release. The durable version of this week's work is knowing who owns your website's server, what version it runs, and how you will hear about the next urgent update before someone forwards you a headline.
If you cannot name the person who would answer that email for every site your business owns, that is the kind of gap a SecureStart assessment maps out in a week.
