Short answer: on October 21, 2026 the PHP project released emergency fixes for two serious flaws. Security researchers call them "PHP2Shell." An attacker can use them to take over a web server without a password. If your website runs WordPress, Joomla, Drupal or Magento, it runs on PHP, and it needs this update now.
What Is PHP, and Why Does This Matter?
PHP is the software that builds web pages on the fly for most small-business sites. Roughly seven out of ten websites use it, including nearly every WordPress site.
Think of it as a brand of door lock that most of the buildings on Main Street happen to use. This week the lock maker announced a defect that lets someone open the door without a key. The fix is ready. The trouble is that burglars heard the news the same day everyone else did.
What Happened
- The flaws: two bugs in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619. Both are rated critical (9.2 out of 10).
- Who is affected: any server that uses PHP to answer web requests. That covers the common setups most hosting companies use.
- The fix: PHP versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The release was moved up a day after details leaked early.
- Older versions: PHP 8.1 and older no longer get regular updates. The federal Cybersecurity and Infrastructure Security Agency (CISA) advises taking those sites offline until they can be upgraded.
- Attacks: security firms, including Amazon and Cloudflare, report that attackers are already trying it against live servers.
What Could an Attacker Do?
These flaws allow what security people call remote code execution. In plain terms, a stranger on the internet can run their own commands on your web server, as if they were sitting at its keyboard. They don't need a password, and nobody at your business has to click anything. They only have to send the right request to your site.
Once they're in, they can do anything the website itself is allowed to do. That usually includes:
- Copying your data. Customer names, email addresses, contact form messages, order details and the passwords the site uses to reach its database.
- Infecting your visitors. Hidden code on your pages can push harmful software onto the phones and computers of the people who visit. Some of it is built to steal passwords, including online banking logins.
- Changing your site. Fake pages and hidden links to scam sites. Google and web browsers may then show a warning in front of your site.
- Sending email in your name. Spam and fake invoices sent from your server can get your business email blocked by other companies' mail filters.
- Leaving a back door. Attackers often plant a hidden way back in. Updating PHP afterward closes the original hole but doesn't remove what they left behind.
- Borrowing your server. Some use it to attack other sites or to mine cryptocurrency. Your site slows down, and some hosts will suspend the account.
Infecting visitors is the one that worries me most, because it reaches people who never did business with you online. Maybe your site is a few simple pages with your hours, your phone number and a map. There's no customer data on it, so it's easy to think nobody would bother. An attacker doesn't need your data, though. They can use your site to get to your customers.
Picture a regular customer checking your Saturday hours on their phone. Their phone picks up something nasty from your page, and a few days later a stranger is logged into their bank account. They may never work out where it came from. If they do, it's your business name they'll connect it to, and that kind of damage to a reputation is hard to undo.
Any one of these can cost a small business far more in cleanup and lost customers than keeping the server up to date.
I've Seen This Up Close
One of my recent free website reviews was for a fairly large business. Their site was running PHP 7.4. That version came out almost seven years ago, and its last security update was in November 2022, nearly four years ago.
It was so far behind that this week's fix doesn't cover it. PHP released no official update for 7.4, only bare-bones code changes a programmer would have to build in by hand. A typical shared hosting company won't do that for you. The real way out is an upgrade, and on a site that old it usually means updating the theme, plug-ins and parts of the site along with it.
That's more common than you'd think. The site kept working, so nobody looked under the hood. That's how most outdated sites happen. A flaw like PHP2Shell is when that gap starts to cost money.
What Should a Business Owner Do This Week?
- Find out if your site runs PHP. If it's WordPress or a similar system, the answer is yes. If you aren't sure, ask whoever built or hosts it.
- Ask your host one question. "Has PHP on my site been updated to the October 21 release?" Get a yes or no in writing.
- Ask what version you were on. If the answer is 8.1 or older, the site needs more than a quick update. Plan for an upgrade soon.
- Check your backups. Make sure a recent copy of your site exists somewhere other than the server it runs on.
On cheap shared hosting, the hosting company usually updates PHP for you, but on its own schedule. On a do-it-yourself server or an old site nobody looks after, nobody updates it at all. Those sites stay open to an attack like this until someone notices.
How Managed Hosting Cuts the Risk
I'll be straight with you. No hosting company can promise a site will never be broken into. New flaws turn up every year, and PHP2Shell won't be the last one. What a good host can do is manage the risk, so a break-in is less likely and does less harm if it happens.
Part of that is knowing what to look for. People who run their own site tend to think about protecting their own information, if they think about security at all. Most never stop to consider the customer checking their hours from a phone. An experienced host does, and it shapes the choices below, including how quickly updates go in and how sites are kept apart.
Most of the risk from a flaw like this comes from the days between the fix coming out and someone installing it. Managed hosting is about keeping that gap short. Someone whose job it is watches for these notices and acts on them.
Here's what that looks like on my hosting plans.
- I watch the security notices. I follow the PHP project, CISA and the major security firms, so keeping up with this isn't on your plate.
- I keep software on supported versions. Sites stay on versions that still get security fixes, so an update like this one is a small step instead of an emergency rebuild.
- I test before I install. I run a separate test lab, apart from the servers that host customer sites. An update gets tried there first, the way a good mechanic test-drives a car around the block before handing back the keys.
- I take a backup before every change. It's like snapping a picture of the wiring before you swap out a light switch. If an update causes trouble, I can put the site back exactly the way it was.
- I limit what a break-in can reach. Each site runs in its own separate space, like apartments with their own locked doors. Trouble in one unit doesn't open the others. The servers also accept no direct connections from the internet, which leaves attackers fewer ways in.
- I monitor every site. Every week I get a report for each site. It confirms each backup ran on schedule, includes a health check that works like an automated version of my free website review, and shows how much memory and processing power the site used. I also set limits for each site. If one suddenly goes past them, I get an alert right away instead of waiting for the weekly report. A jump like that can mean someone has slipped something onto the server, like the cryptocurrency mining mentioned above.
Fixing It With Minimal Downtime
When a fix like this comes out, the work on a managed plan goes roughly like this:
- Read the notice and confirm which sites are affected.
- Install the update in the test lab and make sure the sites still work.
- Take a fresh backup of each live site.
- Apply the update to the live servers. For most sites the restart takes seconds, and visitors rarely notice.
- Load each site and check that pages and contact forms still work.
- If anything is wrong, roll back to the backup and work the problem in the lab.
You get a short note saying it's done. You don't have to call anyone or wait in a support queue.
Is My RockNet Site Affected?
This website doesn't run PHP at all. It's built as plain pages ahead of time, so there's no PHP for an attacker to reach. Where a customer needs a system that does run PHP, such as WordPress, it gets updated using the steps above.
Frequently Asked Questions
Is My WordPress Site at Risk?
Yes, unless PHP on the server has been updated to the October 21 release (8.5.12, 8.4.27, 8.3.36 or 8.2.35). Updating WordPress itself or its plug-ins doesn't fix this one. The fix has to be applied to PHP on the server.
Do I Need to Do Anything if My Host Manages Updates?
Ask them to confirm it in writing, and ask which PHP version your site was running. Some shared hosts update quickly. Others take days, and some leave old versions alone.
My Site Runs an Old Version of PHP. Now What?
PHP 8.1 and older don't get regular security fixes anymore. Your site likely needs an upgrade, which can mean updating its theme and plug-ins too. Until then, the safest course is taking it offline or putting a web application firewall in front of it. That's a filter that catches known attack traffic before it reaches your site, much like a spam filter catches junk mail before it reaches your inbox.
How Would I Know if My Site Was Already Hacked?
Watch for pages you didn't create, links to unfamiliar sites, a security warning in Google or the browser, or a sudden slowdown. Any of those is worth a look by someone who knows what to check. If a site was broken into before it was updated, the update alone won't clean it up.
Can You Look at My Site?
Yes. My free website review covers security and software updates, among other things, and I only look at what anyone on the internet can see. I don't need any logins from you.
