PHP maintainers shipped emergency fixes for two critical security flaws on October 21, 2026, and the U.S. Chamber of Commerce has since published a guide for small business owners on what to do about the problem. The pair of bugs goes by the name PHP2Shell. Both score 9.2 out of 10 on the CVSS v4.0 severity scale, and both may let an attacker run commands on a vulnerable server without a password or an account.
This is not a niche developer problem. PHP sits underneath a huge share of the public web, including every WordPress site, and WordPress alone powers about 40% of all websites, according to The Independent. If your company has a brochure site, an online shop, a booking form or a customer portal, there is a real chance PHP runs it. The PHP2Shell security flaw is therefore a business continuity question first and a technical question second.
We covered the first wave of this story when government sites went offline. This piece takes a different angle. It lays out what small business owners can verify today, which questions to put to a web host, and how to judge whether a site has already been touched. Where the public record is thin, we say so plainly rather than fill the gap with guesses.
Don't miss new tech stories on Google
Add Shattered once in the Google app and our stories show up in your news suggestions.
What PHP2Shell Is and Why Small Businesses Should Care #
PHP is a programming language that runs on the server side. When a visitor loads a page, PHP code on your web host assembles the page, talks to the database and sends the result back. Millions of websites use it. Most owners never see it, which is exactly why a flaw in PHP catches so many small firms off guard. There is no app on your laptop to update. The weak point lives on a machine you rent from a hosting company.
PHP2Shell is the collective name given to two critical vulnerabilities. Reports describe them as capable of enabling unauthenticated remote code execution. In plain terms, a stranger on the internet could tell your server to run commands without logging in. Once an attacker can do that, the usual consequences follow: stolen customer data, defaced pages, hidden spam links, malware served to your visitors, or a site that stays offline until someone rebuilds it.
Cloudflare reported that nearly 70% of all websites were impacted, according to The Independent. That figure describes websites in the potential blast radius, not confirmed break-ins. The distinction matters. A site can run PHP and still be safe if its host has applied the fix. The job for a small business owner is to find out which of those two groups they belong to.
The Confirmed Facts at a Glance #
Fast-moving security stories attract rumor. Before we get into advice, here is what the named outlets have established and what they have not. The table below separates the two, because a decision based on a rumor can waste a weekend or, worse, give you false comfort.
| Item | Status | Detail |
|---|---|---|
| Affected technology | Confirmed | PHP, a language used by millions of websites |
| Number of flaws | Confirmed | Two critical vulnerabilities, collectively called PHP2Shell |
| Emergency fix date | Confirmed | October 21, 2026 |
| Severity | Confirmed | 9.2 out of 10 on CVSS v4.0 |
| Attack type | Confirmed | May enable unauthenticated remote code execution |
| UK NCSC position | Confirmed | Scale described as unprecedented, no sign of breaches at that point |
| Exact affected PHP versions | Unconfirmed | Not established in the sources we checked |
| Exact count of affected sites | Unconfirmed | Cloudflare’s figure is “nearly 70%” of websites impacted, not an exact count |
| Any specific small business breached | Unconfirmed | No named victim in the reporting we reviewed |
Three gaps stand out. The sources we reviewed do not pin down which PHP versions are exposed, do not list the official identifiers for the two bugs, and do not give the exact numbers of the fixed releases. That is why the advice in this article avoids naming a version. Your host or developer can read the official release notes and tell you which build your branch should run. Do not accept a number from a forum post or a social media thread without checking it against the PHP project itself.
Why Unauthenticated Remote Code Execution Is the Worst Case #
Security teams rank bugs by how much work an attacker must do first. Many flaws need a stolen password, a logged-in user or a tricked employee. Unauthenticated remote code execution needs none of that. The attacker sends a crafted request over the internet, and the server obeys. No phishing email, no guessed password, no insider.
A 9.2 score on CVSS v4.0 reflects that. The scale tops out at 10, so a 9.2 sits in the critical band with very little headroom. For a small business, the score translates into a simple rule: treat this like a burst pipe, not a leaky tap. You do not schedule it for next month’s maintenance window.
What an attacker can do with a foothold
Running commands on a web server opens several doors. An attacker can read configuration files that hold database passwords. They can plant a hidden administrator account. They can upload a backdoor that survives a later patch, which is why patching alone does not clean a site that was already compromised. They can also use your server as a launch pad against other targets, which can get your hosting account suspended.
None of this means every site was hit. The UK National Cyber Security Centre said the scale was “unprecedented” but reported no sign of breaches at that point, as BBC News relayed in its live coverage. Quiet logs on day one do not guarantee quiet logs on day five, though. The window between a fix going public and a site being patched is the period attackers watch most closely.
How Fast Exploitation Attempts Escalated #
The best evidence for urgency comes from Cloudflare CEO Matthew Prince, who wrote that exploitation attempts climbed in steep stages. Before public disclosure, Cloudflare saw “thousands” of attempts. Within 45 minutes of disclosure, that became “tens of thousands.” Within two hours, it reached “hundreds of thousands.” Afterward, Prince wrote, the attempts ran into the “millions.”
Those numbers describe attempts, not successful break-ins. Even so, the curve tells a small business owner what to expect. Automated scanners find new vulnerabilities within minutes and probe every reachable site, regardless of size. Nobody picks your shop out of a crowd. A scanner simply tries every address it can find. We tracked an earlier sign of this behavior in our report on attacks that began before disclosure.
| Metric | Figure | Source |
|---|---|---|
| CVSS v4.0 severity | 9.2 out of 10 | Reported across coverage |
| Number of critical flaws | 2 | Reported across coverage |
| WordPress share of all websites | About 40% | The Independent |
| Websites impacted, per Cloudflare | Nearly 70% | The Independent |
| Exploitation attempts before disclosure | Thousands | Matthew Prince, Cloudflare |
| Attempts within 45 minutes | Tens of thousands | Matthew Prince, Cloudflare |
| Attempts within two hours | Hundreds of thousands | Matthew Prince, Cloudflare |
| Attempts afterward | Millions | Matthew Prince, Cloudflare |
Read the bottom half of that table as a countdown. Every hour a vulnerable site stays unpatched, it faces more probes than it did the hour before. A fix applied on day one beats a perfect fix applied on day ten.
Is Your Small Business Website Affected? #
Start with the question the BBC reported as the first piece of advice: contact whoever manages your website. That might be a freelance developer, a web agency, a hosting company’s support desk or an employee who set the site up years ago. Ask three things. Does the site use PHP? If so, is it affected? And has the fix been applied?
You can often answer the first question yourself. If your site runs on WordPress, it uses PHP. Many other content management systems and online store platforms also run on PHP, as do plenty of custom-built business sites. Sites built on hosted website builders that you log into and drag blocks around in are usually managed by the vendor, so the vendor carries the patching burden. Even then, ask for written confirmation.
Who is responsible for the fix?
Responsibility depends on how you buy hosting. On managed hosting, the provider usually updates PHP for you. On shared hosting, the provider controls the server-wide PHP build, though you may have to choose a version in your control panel. On a virtual private server you rent and administer yourself, the patch is your job or your developer’s job. Many owners do not know which of these three they have. Finding out is step one, and it takes one email or one support chat.
The UK NCSC advised organizations using any PHP version to update to the latest fixed version. That wording matters. It does not say “only if you are on a new release.” It says any version, because the safe state is the fixed build for your branch.
Seven Steps to Take Today #
The sequence below follows the guidance published by the named outlets and the NCSC, with a few practical additions drawn from standard incident response habits. Work through it in order. It should take an hour or two of your time, plus whatever your host or developer needs.
Before you change anything
- Identify who runs your site. Write down the name and contact details of your host, your developer and any agency. If nobody owns the site, assign someone today.
- Confirm PHP use. Ask whether the site, shop or any plugin runs on PHP. Request a yes or no in writing.
- Back up and test the restore. BBC News reported that operators were advised to back up their websites and verify that the backups can be restored. A backup you have never restored is a hope, not a plan.
While the patch goes in
- Ask for the fixed PHP build. Request confirmation that the server now runs the latest fixed version for your PHP branch, and ask for the exact version string.
- Test the site afterward. Load the home page, run a test order, submit a contact form and log into the admin area. An upgrade can break old plugins, so check before customers do.
After the patch
- Check for signs of intrusion. Look for unfamiliar administrator accounts, files you did not upload, odd outbound traffic and sudden changes to your pages.
- Write it down. Record the date, the version, who applied the fix and what you tested. If an insurer or regulator asks later, you will have an answer.
One caution: do not skip step three because you are in a hurry. Emergency upgrades are exactly when things go wrong, and a clean backup turns a bad afternoon into a minor delay.
Questions to Ask Your Web Host or Developer #
Most owners lack the vocabulary to pressure a vendor, and vendors know it. The table below turns the BBC and NCSC advice into short questions you can paste into an email. Good vendors answer them in a sentence. Evasive answers tell you something too.
| Question to ask | What a solid answer sounds like | Red flag |
|---|---|---|
| Does my site use PHP? | A direct yes or no, plus the version in use | “We are looking into it” with no date |
| Is my site affected by the two flaws? | A clear statement tied to the fixed release for your branch | Vague reassurance with no version |
| Has the fix been applied? | The date and time of the upgrade | “It should be fine” |
| Do you have a recent backup I can restore? | Backup date and a restore test result | No backups, or backups never tested |
| Did you see suspicious activity before the patch? | A log review summary, even if it says nothing was found | No logs kept |
| Will my plugins and themes still work? | A compatibility check or staging test | Upgrade done with no testing |
| Who do I call if the site goes down? | A named contact and an escalation path | A generic support inbox only |
Keep the replies. If a vendor claims the fix is in place and a break-in happens anyway, a written answer protects you in any later dispute.
Backups That Actually Restore #
The BBC reported advice to back up and to verify that backups can be restored. The second half of that sentence does the real work. Small firms often discover during a crisis that their backup job quietly failed three months ago, or that it saved the database but not the uploaded files, or that the only copy sits on the same server that just got hit.
A usable backup has four properties. It is recent. It includes both files and the database. It lives somewhere other than the production server. And someone has restored it to a test location and confirmed the site loads. Run that restore test now, before the patch, so you have a known-good fallback if the upgrade misbehaves.
If you suspect an intrusion, keep an untouched copy of the compromised site for investigation before you wipe anything. Cleaning too fast destroys the evidence that tells you how the attacker got in and what they took.
Spotting a Compromise After the Patch #
Applying the fix closes the door, but it does not tell you whether someone walked through earlier. Cloudflare saw “thousands” of exploitation attempts before disclosure, so a gap existed in which a determined attacker could have gotten in. Treat the first week after patching as a review period.
Warning signs include new administrator users you did not create, strange files in upload folders, pages that redirect to unrelated sites, a sudden spike in server load, outbound connections to unfamiliar addresses, and complaints from customers about browser warnings. Search engines may also flag your site as unsafe, which can cut your traffic overnight.
If you find any of these, assume the attacker saw your secrets. Change database passwords, admin passwords, API keys and any stored credentials, and revoke old tokens. Our earlier report on a [cyberattack that forced customers to revoke secret keys](https://shattered.io/railway-cyberattack-revoke-secret-keys-2026/) shows how much damage stale credentials can do after the original hole is closed. Switch on multifactor authentication for every admin login while you are at it.
For sites you run yourself, a host-level defense can also help. Tools that block known hostile addresses add a layer while you patch, and our walkthrough on [blocking bad IPs with CrowdSec](https://shattered.io/crowdsec-ubuntu-firewall-bouncer-setup-2026/) covers one open-source option. A filter reduces noise, but it does not replace the fix.
Market Impact: Hosts, Security Vendors and Insurers #
Yahoo News reported that companies scrambled to fix the flaws, forcing websites offline in some cases, and the scramble hit businesses of every size. We have no reliable figure for lost revenue, and we will not invent one. The pattern is clear enough without a dollar amount. Taking a site offline to patch it costs sales for every hour the shop stays dark.
Three groups feel the pressure most. Hosting companies face a surge in support tickets and a reputational test, because customers will remember which provider told them what and when. Security vendors gain attention, since a 9.2 flaw sells managed protection better than any marketing campaign. Insurers watch closely too. Cyber-insurance underwriters already ask about patching habits, and an event like this sharpens those questions. Our report on the cyber-insurance gap flagged by Lockton explains why owners should read their policy terms before they need them.
For small firms, the real market effect is a quiet reshuffling of trust. Owners who learned this week that nobody on their payroll knew where the site ran will start asking harder questions of agencies. Vendors who answered quickly and clearly will keep clients. Those who went silent will not.
How Different Site Setups Compare #
Not every business faces the same exposure. The comparison below is our own analysis of how responsibility typically splits across common setups, not a claim about any named vendor. Check your own contract for specifics.
Managed WordPress hosting
These providers usually control the PHP layer and test updates for you. Your task is to ask for confirmation and review plugins. Exposure tends to be lowest here, as long as the provider acts quickly.
Shared hosting
The provider patches the server, but you may need to pick the right PHP version in a control panel and confirm your plugins work with it. Responsibility sits in the middle, and confusion is common.
Self-managed virtual servers
Nobody patches this setup unless you or your developer does. It offers the most control and the most risk, especially if the person who built it left the company. Owners in this group should act first.
Hosted site builders and custom applications
Hosted builders put the burden on the vendor, so request a written status update. Custom applications written in PHP depend entirely on whoever maintains them, which makes a quick call to your developer the first move.
Historical Context: Emergency Patch Weekends Are Not New #
The industry has lived through this before. Heartbleed and Log4Shell each forced administrators worldwide into rushed patching, and each taught the same lessons. Attackers scan within hours. Small organizations patch last. Cleanup takes far longer than the fix itself. Those episodes also showed that a bug buried in widely shared software spreads risk far beyond one vendor, because countless products inherit it without their owners knowing.
PHP2Shell shares that profile, with one difference. Most people can name the app on their phone, but few can say what language their website runs on. The invisibility of the dependency, more than the 9.2 score, explains why the NCSC called the scale unprecedented. Owners had no way to know they were exposed until a news alert told them.
The public conversation around the flaws also mixes two ideas that deserve separation. One is the technical bug. The other is the web’s habit of leaving old software running for years. Fixing the first takes a day. Fixing the second takes a change in how small firms budget for upkeep. If your company treats the website as a one-time project instead of a living system, this event is your cue to change that.
Five Predictions for the Coming Weeks #
The following forecasts are our analysis, not reported fact. We base them on how earlier emergency patch events unfolded, and we label them as judgments you can test against future news.
- Confirmed small-business incidents will surface. Early reporting shows no named victim, yet scanning at this scale usually produces compromised sites within weeks, and some will belong to small firms.
- Hosts will tighten upgrade policies. Expect more providers to force PHP upgrades instead of waiting for customers to choose.
- Insurers will add patching questions. Applications and renewals will likely ask how fast a business applies critical fixes.
- Site audits will become a sales line. Agencies and security firms will bundle one-off checks and monthly maintenance into new packages aimed at owners who just learned they had no plan.
- Aftershocks will outlast the headline. Even after the first fixes land, stragglers running neglected servers will keep getting probed for months.
None of these requires anything exotic to come true. They follow from how attackers, vendors and underwriters usually behave once a high-profile flaw becomes public.
What to Do After You Patch: Making It a Habit #
The best outcome from this episode is a routine that survives it. Start by naming one person who owns website upkeep, even if that person only coordinates with an outside vendor. Put a recurring reminder on the calendar to review updates monthly. Keep a short document listing your host, your PHP version, your plugins and your emergency contacts.
Next, subscribe to alerts from your host and from your content management system. Many of the sites hit hardest in past incidents were not unlucky, they simply never heard the warning. National cyber agencies such as the UK NCSC also publish guidance aimed at organizations of all sizes, and following one takes minutes a week.
Finally, rehearse a bad day. Ask your developer how long it would take to restore the site from backup, and write the number down. If the answer is “I’m not sure,” run the test. For more reporting in this area, our security coverage hub tracks the fallout as new details emerge.
Frequently Asked Questions #
What is PHP2Shell?
PHP2Shell is the collective name for two critical security flaws in PHP, the programming language used by millions of websites. PHP maintainers released emergency fixes on October 21, 2026. Reports say the flaws may enable unauthenticated remote code execution.
How serious is the PHP security flaw?
Both flaws were rated 9.2 out of 10 on the CVSS v4.0 scale, which places them in the critical band. The UK National Cyber Security Centre described the scale as unprecedented, though it reported no sign of breaches at that point.
Does my WordPress site use PHP?
Yes. WordPress runs on PHP and powers about 40% of all websites, according to The Independent. If your site runs on WordPress, ask your host whether the fix has been applied.
What should small business owners do first?
Contact whoever manages your website. Find out whether it uses PHP, whether it is affected, and whether the fix has been applied. Back up the site and confirm the backup can be restored.
Which PHP version should I install?
The sources we reviewed did not establish the exact fixed release numbers, so we will not name one. The UK NCSC advised organizations using any PHP version to update to the latest fixed version. Ask your host or developer to confirm the correct build for your branch from the official PHP release notes.
Was my business already hacked?
Nothing in the reporting we reviewed names a breached small business, and not every PHP-based site was vulnerable. Check your logs for new admin accounts, unknown files and odd outbound traffic. If anything looks wrong, rotate credentials and bring in a professional.
How quickly did attackers start probing?
Cloudflare CEO Matthew Prince wrote that attempts rose from “thousands” before disclosure to “tens of thousands” within 45 minutes, “hundreds of thousands” within two hours, and “millions” afterward. Those figures count attempts, not successful intrusions.
Do I need to take my site offline?
Some sites went offline while operators patched, as The Independent’s live coverage and other outlets reported. Whether you need to depends on your host’s status and your setup. Ask your provider, and if the fix is not yet applied, ask what interim protection they offer.