PHP2Shell: what a small business with a WordPress website should do this week

What happened, in plain English

PHP is the programming language that runs on the web server behind many websites, including every site built on WordPress, Drupal or Joomla. On October 21, 2026, the PHP project released fixes for two flaws it rates as critical, CVE-2026-109618 and CVE-2026-109619. PHP's security advisory on php.net says they can allow unauthenticated remote code execution: a stranger who never logs in could make your web server run their commands.

Wiz Research, the security team that reported the flaws to PHP, calls them PHP2Shell and says AI tools helped it find the first one. Wiz writes that every PHP version released in the last decade is affected by at least one of the flaws, going back to PHP 5.4, and that it demonstrated attacks without a login against WordPress, Drupal and Joomla. PHP's security team rated both flaws 9.2 on the CVSS version 4.0 severity scale, which tops out at 10.

The timing was messy. According to Huntress, a post on the Hacker News forum on October 20 claimed two critical PHP flaws were coming; it was taken down, but screenshots spread. Huntress says the October 21 release came a day ahead of the original disclosure date. PHP's own notice, posted October 20, simply set the release for October 21 and does not mention a leak.

Why it matters even for a small website

It is easy to think nobody would bother with a five-page site for a pest control company. Attacks like this do not start with your business. Automated tools scan the internet for servers that look vulnerable and try every one they find, so a small site on an old server is as reachable as a large one.

The risk is bigger than a defaced home page. Wiz also showed that attackers could read sensitive data from the PHP process's memory. A small business web server may hold contact form messages, a booking plugin's customer list, and the passwords or keys that connect the site to payment, scheduling or email tools. Someone running commands there can reach all of it, and can use your site to send spam or host scam pages under your name.

For a South Florida service business, the website is often where returning seasonal residents find you each fall. A site that is down, flagged as unsafe, or quietly sending visitors elsewhere costs you those calls.

How to tell whether your site runs on PHP

You do not need to be technical to find out. If your site is built on WordPress, Drupal or Joomla, it runs on PHP. If you are not sure what it is built on, ask the person who made it.

If you can log in to WordPress as an administrator, open Tools, then Site Health, then the Info tab, and look under Server for the PHP version. Many hosting dashboards also show the PHP version in their settings. Write the number down, but treat it as a starting point. The PHP project says Linux distributions and long-term support vendors received the fixes in advance and ship their own updated packages, so only your host can confirm the fix is actually running on your server.

If your site is on an all-in-one website builder where you never chose a host, the builder company runs the servers and any fix is theirs to make, so ask them. Do not try to check by running attack code or scanning tools against your site: it can crash a server, and on shared hosting the server is not only yours.

What to ask your web host or designer today

Send one email to whoever looks after your website (your web host, the designer who built it, or your IT provider) and ask for written answers. A good answer names a version number and a date.

PHP's 8.2.35 announcement adds that PHP 8.2 stops getting security fixes after December 31, 2026, so a site on 8.2 should plan its next upgrade now. Wiz notes that some hosting and network providers have added protections for these flaws, but php.net is clear that only the update is a complete fix. Plugin and theme updates do not fix PHP either, but this is a good week to close every other door.

Backups need to live somewhere an attacker cannot reach from your server, for the same reason you keep business records away from the office in hurricane season. Patchstack's alert also flags a separate WordPress attack, not caused by the PHP flaws: someone holding valid UpdraftCentral dashboard keys has been installing backdoors on connected sites, and Patchstack's advice is to delete those keys. Copy these questions into your email:

• Which PHP version is our website running right now, including any staging or test copies of the site?
• Has PHP been updated to a fixed release (8.5.12, 8.4.27, 8.3.36 or 8.2.35) or to your vendor's package with the fix for CVE-2026-109618 and CVE-2026-109619? On what date?
• If we are on PHP 8.1 or older, what is the plan? The PHP project no longer releases updates for those versions.
• Are WordPress (or Drupal or Joomla), our plugins and our theme up to date, and have plugins we no longer use been removed?
• When was our last backup, is it stored somewhere other than the web server, and has anyone tried restoring it?
• Is a web application firewall in front of our site, and has it been given rules for these flaws?
• Is the UpdraftPlus backup plugin installed? If so, have any UpdraftCentral keys been deleted, as Patchstack advises, even if we never used UpdraftCentral?

Signs something is wrong

Wiz points hosts to technical warning signs, such as unusual upload-style requests followed by memory errors, repeated server errors, and PHP processes restarting for no clear reason; Patchstack notes these signs are not proof either way. Your host can check for those. If you notice any of the everyday signs below, call your host or designer the same day and mention PHP2Shell by name.

Huntress advises isolating a server suspected of compromise, preserving its logs and checking it for new files, scheduled jobs and accounts. If warning signs appear, Patchstack says to still update, treat the server as possibly compromised and consider changing the passwords and keys it holds. That work belongs to your provider; your job is to ask for it and get a written answer. Here is what you can watch for:

• Error pages, such as a 500 or internal server error message, that come and go
• Administrator accounts or plugins in WordPress that nobody on your team added
• Customers saying your site sent them to a strange page, or a browser warning that the site is unsafe
• An email from your host about suspicious activity, unusual resource use or a suspended account
• Contact form messages that stop arriving, or customers getting emails from your domain that you never sent

What not to do

Do not panic-install a pile of security plugins. The flaws sit in PHP, underneath WordPress, and PHP's advisory describes a demonstrated attack, on one common server setup, that runs before any application code does. A plugin cannot update PHP. Patchstack specifically warns against unofficial fix plugins and copy-pasted code snippets, which are unverified and can break sites.

Do not ignore emails from your host this week, but log in to your hosting account directly rather than clicking a link in a scary message. Do not test your site, or anyone else's, with exploit code or scanning tools. And do not pay a stranger who calls out of the blue claiming your site is infected; check with the provider you already have.

Finally, do not assume the news is overblown or a disaster; reports differ. Patchstack wrote on October 21 that its own data showed only probing, with no hard evidence of breaches yet, while also reporting exploitation incidents from hosting partners and noting that Cloudflare saw early attacks. Huntress said that as of 4:30 p.m. Eastern on October 21 it had not observed exploitation on its partners' systems. PHP's advisory and Wiz's write-up do not say whether attacks have been seen. The sensible reading is that a fix exists, attackers are looking, and the update should not wait.