If you run a small business website, you’ve probably heard the same advice for years: keep WordPress updated, keep your plugins current, and you’ll be fine. This month, that advice stopped being enough.
On October 21, 2026, the PHP project shipped emergency fixes for two critical flaws in PHP itself, the programming language that sits underneath WordPress, Drupal, Joomla, Magento and a huge share of the custom web applications small businesses rely on. Researchers have nicknamed the pair “PHP2Shell,” and it is already being used in real attacks. The uncomfortable part is this: a website can be fully up to date at the application level and still be exposed.
What PHP2Shell Actually Is
PHP2Shell is the name for two vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, that live in the core PHP engine. According to Varonis Threat Labs, an attacker with no account and no password can send a specially crafted request that lets them read a PHP worker’s memory, which can include passwords, tokens and API keys, and in some cases run their own code on the server.
The reach is enormous. PHP runs roughly 70 percent of the world’s websites, and every PHP version going back to 5.4 is affected. Researchers demonstrated remote code execution against the latest WordPress, Drupal and Joomla container images, and noted that even a basic “Hello World” PHP app can be vulnerable. The flaws affect the most common ways PHP is run, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed.
Real-world risk does vary by setup. Varonis notes that Apache mod_php carries the greatest risk, and Mandiant’s chief technology officer reported that the working exploits his team validated succeeded against default mod_php deployments but not PHP-FPM (The Register). That’s useful context for deciding what to fix first, but it isn’t a reason to wait. Every affected configuration should be patched.
Why Your Patched Website Isn’t Protected
Think of your website like a building. WordPress, your theme and your plugins are the rooms, furniture and locks on the doors. PHP is the foundation underneath all of it. For years, most website security advice has focused on the rooms: update the plugins, remove the abandoned theme, use a strong admin password. All of that still matters.
PHP2Shell is a crack in the foundation. The vulnerable code runs before any application code executes, so it doesn’t matter how carefully your site was built or how recently your plugins were updated. Varonis points out that this also means application-level logging may capture little or nothing about an attack. A security plugin inside WordPress can’t see a problem that happens before WordPress even starts.
That’s why the fix has to happen at the server level, by updating PHP itself, rather than inside your website’s admin dashboard.
How Fast This Moved
The timeline is a good illustration of how quickly vulnerabilities turn into attacks now. Researchers first found the bugs in early August and reported them to the PHP project, which began working on fixes. Details then leaked ahead of the coordinated announcement. Amazon’s threat intelligence team saw exploitation attempts as early as October 17, four days before the bugs were publicly disclosed, according to The Register.
Patched versions arrived on October 21: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. On October 26, the Cybersecurity and Infrastructure Security Agency added both flaws to its Known Exploited Vulnerabilities catalog, which it does only when there is evidence of real-world attacks. By then, one researcher had recorded 35 successful shell executions on honeypots, decoy servers built to attract exactly this kind of activity, running PHP under Apache mod_php. He cautioned that the decoys used a configuration favorable to attackers, and CISA’s listing confirms active exploitation without saying how many real business systems have been breached. Several early reports of successful attacks were later walked back. Even so, the trend is clearly moving in the wrong direction.
A Third, Less Likely Flaw
On October 23, the PHP Foundation reserved a third identifier, CVE-2026-115560, for another remote code execution flaw related to PHP2Shell. The Foundation says it requires a very unlikely combination of server configuration and application code, so it will be fixed in the next regular PHP release rather than through an emergency update. Until then, PHP’s advisory recommends setting session.upload_progress.enabled=0 to fully block it. Your developer or hosting provider can make that change in minutes.
The Versions That Won’t Get a Fix
Here’s where many small businesses will get caught. Official fixes were released only for currently supported PHP branches. PHP 8.1 and older have no official patched release.
That matters because plenty of small business websites run on older PHP versions without anyone realizing it. The hosting account was set up years ago, the site worked, and nobody revisited the server configuration. An older theme or plugin may even have been the reason the PHP version was never upgraded, because moving to a newer version could break something.
If your site runs on PHP 8.1 or earlier, there are really only a few paths forward: upgrade to a supported, patched PHP version and test the site carefully, confirm whether your hosting provider is supplying its own security backport, or move the site to a modern platform. Waiting is not one of the options. If a system can’t be secured right away, taking it offline until it can be is the safer choice.
Where PHP Hides in a Small Business
Most owners think of PHP as “the website.” In reality it often shows up in more places:
- The public marketing website and blog
- Online booking, quote request or contact forms
- Ecommerce stores built on WooCommerce, Magento or similar platforms
- Client portals and document upload pages
- Internal tools and intranets someone built years ago
- Software and network appliances that bundle PHP for their management pages
Who is responsible for patching depends on how each one is hosted. On basic shared hosting, the provider usually manages PHP but may leave the version choice to you. On managed WordPress hosting, the host typically handles it. On a self-managed cloud server or virtual private server, it’s entirely your responsibility, or your IT provider’s. Many businesses aren’t sure which situation they’re in until they ask.
What To Do This Week
- Inventory every place PHP runs. Start with the website, then check portals, forms, stores and internal tools.
- Confirm the PHP version for each one. Your host’s control panel or your web developer can tell you in minutes.
- Patch internet-facing systems first. Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, depending on your branch.
- Rotate secrets on exposed servers. Because PHP2Shell can expose memory, change database passwords, API keys and payment gateway credentials stored on any server that was vulnerable.
- Look for warning signs. Bursts of server errors, unusual file upload requests, or PHP processes launching system commands all deserve a closer look.
- Plan your exit from unsupported PHP. If any system is on 8.1 or older, schedule the upgrade now.
Questions to Ask Your Web Host or Developer
- Which PHP version is each of our sites and applications running today?
- Has that version been updated to a patched release since October 21?
- Who is responsible for PHP updates on our hosting plan: you or us?
- If we’re on PHP 8.1 or older, what’s the plan and timeline to upgrade?
- Have the server’s logs been reviewed for signs of exploitation?
If nobody can answer these questions confidently, that’s useful information in itself.
PHP2Shell Questions
Does PHP2Shell affect WordPress sites?
Yes. The flaws are in PHP itself, which WordPress runs on, so a WordPress site is exposed until the PHP version underneath it is updated, even if WordPress and every plugin are current.
Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released October 21, 2026. PHP 8.1 and older did not receive an official fix.
Is updating PHP enough?
Updating closes the vulnerability, but it doesn’t undo anything an attacker did beforehand. If a server was exposed, rotating stored passwords and keys and reviewing logs are important follow-up steps.
The Takeaway
PHP2Shell is a reminder that a website is only as secure as the software underneath it. Keeping WordPress and plugins updated still matters, but it doesn’t protect you from a flaw in the language your site is built on. The single most useful question you can ask this week is simple: what PHP version are we running, and has it been patched? If the answer is “I don’t know” or “8.1 or older,” treat it as urgent.
Cloud9 Tech Solutions helps businesses stay ahead of vulnerabilities like this through proactive network and server management and a security stack built to catch what application-level tools miss.
Not sure what’s running under your website, or who’s responsible for patching it? That’s exactly the kind of gap worth closing before an attacker finds it. Schedule a free security assessment with Cloud9.