Table of Contents
On October 21, 2026, the PHP project shipped emergency fixes for two critical flaws, CVE-2026-109618 and CVE-2026-109619, now known as PHP2Shell. Both let an attacker run commands on a web server that uses unpatched PHP without logging in. If your small business website runs on WordPress, WooCommerce, or another PHP platform, the fix lives on your server, not in your WordPress dashboard. A WordPress or plugin update will not close it.
Attacks are now working in the wild. SecurityWeek reported on October 26 that honeypots run by researcher Adel Karimi recorded 35 working shells on October 24, all on unpatched PHP 8.4.26 running under Apache. This guide covers how to tell whether your site is exposed, who is responsible for the patch on your kind of hosting, what to ask your host in writing, and what to check if your site sat unpatched for a few days.
What PHP2Shell is, in plain terms
PHP is the language underneath WordPress, WooCommerce, Drupal, Joomla, Magento, and a long list of booking plugins and customer portals. Every time someone loads a page or submits a form, PHP reads the request first and then hands it to your site.
The PHP2Shell bugs sit in that first step. Datadog Security Labs reproduced the main flaw and found that a single unauthenticated POST request could trigger it before any of the site’s own code ran. So strong admin passwords, a security plugin, or a login-page firewall inside WordPress won’t stop it. All of them run after PHP has already handled the malicious request.
Each flaw carries a CVSS v4.0 score of 9.2. CISA’s alert says they affect every PHP installation that serves web requests, including Apache with mod_php (the setup PHP rates as highest risk), PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed. Amazon reported exploitation attempts as early as October 17, four days before the patches came out, after some details leaked.
The fixed PHP versions
The PHP project released these patched versions on October 21:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Anything newer in the same branch also counts. PHP 8.1 and older are past official support. The PHP security team published source backports for 7.4, 8.0, and 8.1, but nobody ships those as ready-made releases, so a site on 8.1 or older depends entirely on its host or Linux vendor. CISA’s advice for systems that can’t be patched right away, or that still run 8.1 or earlier, is to take them offline until they’re fixed.
Plan ahead on 8.2, too. Its security support ends December 31, 2026, so if your host has to touch PHP this week anyway, ask about moving to 8.3 or newer at the same time.
Who owns the patch on your kind of hosting
Most small business owners don’t need to update PHP themselves. They need to know whose job it is and get a written answer. Here is how that usually breaks down.
| How your site is hosted | Who patches PHP | What you do |
|---|---|---|
| Shared hosting (cPanel-style plans) | The host | Confirm the fix in writing and check your PHP version. |
| Managed WordPress hosting | The host | Same. Several managed hosts have already posted public notices. |
| VPS, cloud server, or a box your developer set up | You or your developer | Patch today, restart PHP, and confirm. |
| Hosted builders like Wix, Squarespace, or Shopify | The platform | There’s no PHP of yours to patch. Check any separate WordPress blog, landing page, or booking tool. |
| Headless or “decoupled” sites (a Next.js or other JavaScript front end pulling content from WordPress) | Whoever hosts the WordPress back end | The public site may not run PHP, but the content server behind it does. Patch it. |
Two hosts’ public statements show the range. Hostinger says every plan except VPS got the fix automatically, while VPS customers manage PHP themselves and need to update. Kinsta says it applied the fixes for all WordPress sites, including staging environments, and customers don’t need to change anything. If your host hasn’t said anything at all, don’t read silence as “handled.”
Headless setups are easy to overlook. Plenty of modern business sites put a fast JavaScript front end in front of a WordPress install that only stores the content. Visitors never see the WordPress address, but attackers scan for it anyway. If your developer built your site this way, ask about the content server by name.
How to check your PHP version in WordPress
Log in to WordPress and go to Tools › Site Health, open the Info tab, and expand Server. The PHP version listed there is the one serving your site. On WooCommerce, the same number appears under WooCommerce › Status in the Server Environment section.
Read the full number, not only the first two parts. The independent tracker php2shell.fyi points out that Site Health judges PHP by branch, such as 8.3, and can’t tell a fixed 8.3.36 from an unfixed 8.3.35. A green Site Health screen doesn’t prove anything about PHP2Shell.
The version number can mislead you in the other direction as well. Linux vendors and some hosts backport security fixes into the version they already ship, so a patched server can still report an older-looking number. That’s why the written confirmation from your host matters more than the number you see.
If you manage the server yourself, keep in mind that the PHP your terminal reports isn’t always the PHP your website uses. WP-CLI and php -v show the command-line PHP. After patching, restart PHP-FPM or the web server, rebuild any containers, and check Site Health again.
What to send your host or developer today
Open a ticket through your host’s official dashboard or support page, list every domain you own, and ask for an answer in writing. You can copy this:
Hi, I’m checking on the PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619) for the sites on my account: [list every domain, including staging and old landing pages]. For each site, please confirm:
1. Which PHP version and build serves it right now, and whether that build includes the October 21, 2026 fixes.
2. When the fix was applied, and whether PHP and the web server were restarted afterward.
3. If any site is on PHP 8.1 or older, what you’ve installed and when we can move to 8.3 or newer.
4. Whether you’ve seen signs of exploitation on my account since October 17.Thanks.
A useful reply names a version, a build date, or a changelog entry. A reply that only says “we take security seriously” doesn’t answer the question, so ask again.
Send the same questions to any vendor that runs a PHP-based tool for you: an online booking system, a customer portal, a membership site, or a store on a separate subdomain. Your customers won’t know which piece of your setup got hacked. They’ll only see your name on it.
Don’t forget the sites you stopped thinking about
The domains most likely to stay unpatched are the ones nobody logs into. Old campaign landing pages, a staging copy your last developer left running, a second WordPress install for a blog, a seasonal promo site. Your registrar and hosting invoices are the fastest way to find them, since they list every domain and plan you still pay for.
For each one, either get it patched or take it down. An abandoned site that still sends email from your domain or links to your main site is a liability even when it gets no traffic.
If you can’t patch today
CISA, the NSA, and the FBI all advise taking a vulnerable system offline if it can’t be updated right away. For most small businesses that means a few hours in maintenance mode, which costs far less than cleaning up a hijacked server.
A web application firewall in front of the site can buy time. Cloudflare added rules for PHP2Shell, including for free-plan customers, according to the U.S. Chamber’s CO— guide. Datadog notes that controls at a reverse proxy can block bad requests before they reach PHP. Treat both as a stopgap. Only the patch fixes the bugs.
Some posts recommend turning off session.upload_progress as a workaround. Datadog’s research found that this and other community mitigations don’t fully protect against PHP2Shell. The setting does matter for a separate, much narrower bug: on October 23 the PHP team disclosed CVE-2026-115560, which only applies to an unusual configuration, and suggested disabling session upload progress in php.ini or the PHP-FPM pool until the next regular release. That change belongs in the server configuration. A plugin or a .user.ini file applies too late to count.
Signs your site may already be compromised
Because attempts started around October 17, look at everything that changed on your site since then. You don’t need log files to spot the common problems:
- Administrator or editor accounts you don’t recognize under Users.
- Plugins, themes, or files you didn’t install, especially in the uploads folder.
- Pages or posts you didn’t create, often spam or pharmacy content that only shows in search results.
- Contact forms that now send leads to an email address you don’t own.
- A site that crashes, slows down, or restarts for no clear reason.
If you or your developer can read server logs, the honeypot reports describe a pattern of large multipart form submissions, memory-exhaustion errors, and a PHP or Apache process starting a shell. Karimi cautions that a memory error or a worker crash alone doesn’t prove a break-in. An unexpected shell process does.
If anything looks wrong, stop editing the site and call your host or developer before you try to clean it up. Deleting files by hand can destroy the evidence they need and leave a back door in place. WordPress.org’s guide for hacked sites covers the cleanup itself, and you can report an incident to CISA or the FBI’s Internet Crime Complaint Center.
Change passwords and keys after the patch
Researchers showed that the flaws can leak data from server memory, including passwords, login tokens, and API keys. So once PHP is patched, assume anything the site knew might have been exposed. Rotate in this order:
- Your hosting account and WordPress admin passwords, with two-factor sign-in turned on for both.
- Your domain registrar and business email, since those let someone take over the rest.
- Keys the site uses to talk to other services: Stripe or other payment gateways, WooCommerce REST API keys, email marketing, CRM, and booking integrations. Your developer can regenerate these in each service’s dashboard.
Do this only after the patch is confirmed. A new password on an unpatched server can leak the same way the old one did.
This is also a good moment to confirm you have a recent backup stored somewhere other than the server itself, and that someone knows how to restore it. Our owner checklist for the WordPress 7.1.3 security release walks through backups, user audits, and post-update testing for your homepage, forms, and checkout, so you can reuse it after your host restarts PHP.
Watch out for fake fixes
Big security news brings out scammers. Don’t install a plugin or paste a code snippet that claims to fix PHP2Shell. Patchstack has warned against unofficial fixes, and the U.S. Chamber’s guide notes that some may contain malware. Be wary of unexpected emails or calls from someone offering to patch your site. Reach your host through the support link in your account dashboard or the phone number on its official website, not through a link in an email.
What to change after this week
For most small businesses, PHP2Shell takes one conversation with a host to fix. The slower part is that many owners don’t know who maintains their website, what version of anything it runs, or which old sites are still live under their name. Write down the answers you collect this week: host, PHP version, who has admin access, where backups go, and every domain you pay for. The next emergency patch will take five minutes instead of a day of guessing.
If you’d rather not track this yourself, it helps when one team builds, hosts, and maintains the site, because then one email answers every question above. IntuiCo Digital offers managed small business website plans with hosting and maintenance included, and we’re happy to look at your current setup and tell you where it stands.
Sources
- CISA: Critical Vulnerabilities in PHP Require Immediate Patching (updated October 23, 2026)
- Datadog Security Labs: PHP2Shell detection, analysis, and remediation
- SecurityWeek: PHP2Shell exploitation moves from probes to working shells
- BleepingComputer: PHP2Shell flaws now exploited in the wild
- PHP.net news archive, including the October 23 session upload progress advisory
- WordPress.org: Critical PHP Security Release
- php2shell.fyi: PHP2Shell on WordPress and WooCommerce
- U.S. Chamber of Commerce CO—: What small business owners need to do
- Hostinger: Protections against PHP2Shell
- Kinsta: How Kinsta protected WordPress sites
This post is general guidance for website owners, not legal or incident-response advice. If you think your site was breached, work with your host or a security professional.