When the Patch Alert Lands: A Small Business Guide to Handling Vulnerabilities (Using PHP2Shell)

Last week a lot of IT people had a bad Wednesday. Two serious flaws in PHP, the programming language behind a huge share of websites, were fixed on October 21, a day after word of them leaked online. Within hours of the fix, security firms were seeing exploit attempts against their test servers. Hosting companies scheduled emergency maintenance, and plenty of websites, including some Canadian government sites, went offline as a precaution while they patched.

This guide uses that event to show what you should do before, during and after any "patch now" warning. You don't need to read code to do any of it.

What Happened, in Plain Terms

Two flaws, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell, were found in PHP itself. The PHP security team rated both 9.2 out of 10 (critical) on the CVSS v4.0 scale. The worrying part is the combination: an attacker could run their own commands on the server, and they could do it with an ordinary web request, without logging in. A strong password or two-factor sign-in on your website doesn't help when the weakness sits underneath the login page. PHP handles the malicious request before your website's own code even runs.

News of the flaws leaked online on October 20, the day before the planned release, and PHP posted an advance warning the same day. The fixed versions shipped on October 21 as scheduled (8.5.12, 8.4.27, 8.3.36 and 8.2.35). CISA put out an alert that day, and so did Canada's Cyber Centre. Security firms including Huntress, Datadog Security Labs and Sophos published their own write-ups. Amazon's threat intelligence team reported an exploit attempt against one of its test servers dating back to October 17, four days before the fix, and many more within hours of the release. On October 26, CISA added both flaws to its catalogue of vulnerabilities known to be exploited in real attacks.

Not every early report held up, though. Sophos and Palo Alto's Unit 42 each withdrew an early claim of a successful compromise after further analysis couldn't confirm that PHP2Shell was the way in. That's a useful lesson on its own: not every strange thing you see this week is this bug.

One more detail matters for a lot of offices. PHP 8.1 and older no longer get official releases. For 7.4, 8.0 and 8.1, the PHP team published only minimal source-code patches for people who build PHP themselves, so anyone on those versions had to rely on their host or Linux vendor for a patched package, or upgrade. Versions older than that got nothing. Those offices had a harder week.

Now the part that catches owners out. "We don't use PHP" is not a safe answer. WordPress, Drupal and Joomla sites run on it. So do common hosting control panels such as cPanel and Plesk, and so do plenty of self-hosted tools and appliances that quietly bundle it, like a booking system or a document portal. Even Palo Alto Networks listed its own firewall software as affected. If a vendor runs it for you, it's still your exposure.

Before: Find Out What You Actually Run

You can't patch what you don't know exists. Most small businesses have never written the list down, and the first attempt is usually humbling.

Start with a simple inventory, a spreadsheet is fine:

• Every website and web application, including the old one from the previous agency that nobody switched off
• Servers and network devices that have an admin web page
• Software your vendors host for you (accounting, booking, client portals) and who to call there
• Who installed it, who maintains it, and who pays the renewal

Next to each row, write the name of the person responsible. Not a team, a person. When the alert arrives, "somebody should look at that" is how two days disappear.

Then pick one person to own advisories. In a fifteen-person office that might be the office manager with your IT provider behind them. Their job is small: read the alerts, ask "do we run this?", and start the process below.

Good places to get alerts:

• The Canadian Centre for Cyber Security alerts and advisories
• CISA's alerts, which are free and widely cited
• Security bulletins from your key vendors, such as Microsoft and your web host
• Your IT provider, who should be telling you before you find out from the news

Finally, ask your MSP and your hosting provider for a written status the next time something like this happens. A two-line email ("we run PHP 8.3 on your site, updated to 8.3.36 on this date") is worth more than a verbal "we're on it."

During: The First 24 Hours

When the alert lands, answer five questions before anyone touches anything.

1. Do we run the affected software? Check the inventory, then ask vendors about what they host for you. (Advisory owner and IT provider.)
2. Is it reachable from the internet? A public website is far more exposed than a tool used only on the office network. (IT provider.)
3. Is it being exploited right now? CISA and vendor write-ups will say, and the answer changes the speed completely. (Advisory owner.)
4. What is the fix, and what could it break? Check plugins, themes and custom code before the update, not after. (IT provider and web developer.)
5. How do we undo it? A fresh backup and a named person who can restore it. (IT provider.)

Those answers set the pace. A rough rule that works for most small offices:

• Exploited in the wild and internet-facing: hours, not days. Drop other work.
• Serious, not yet exploited, internet-facing: within a few days.
• Serious but internal only: your normal maintenance window, soon.
• Low severity: the regular monthly cycle.

PHP2Shell sat in the first group. Reachable without a login, rated critical, exploit attempts reported within hours, and on CISA's known-exploited list five days later.

Take a backup before you update, and confirm it can actually be restored. Sites that update cleanly most of the time still occasionally break on a plugin, and a recoverable mistake is a much better afternoon than an unrecoverable one.

When You Can't Patch Right Away

Sometimes the fix isn't available or isn't safe to apply today. That was true last week for anyone running an end-of-life PHP version, and it's always true for some vendor-managed appliances where you wait for the manufacturer.

The goal in that situation is to make the system harder to reach until you can fix it properly.

• Reduce exposure. If the system doesn't have to be public, take it off the internet or limit it to known addresses or a VPN. For PHP2Shell, CISA's advice was blunt: if you can't update right away, or you're on PHP 8.1 or older, take those systems offline until they're fixed.
• Put something in front of it. A web application firewall or your host's filtering can block a lot of junk traffic. It's a speed bump, not a cure, so treat it as temporary.
• Watch it more closely. Ask for logs to be kept and someone to look at them daily until the patch is in.
• Isolate it. If the server holds nothing else important, make sure it can't reach your file server, backups or other systems.
• Write a date. A workaround without a deadline becomes permanent. Decide when the upgrade or replacement happens and who approves the money.

If the real problem is that the system is years out of support, this is the moment to say so to whoever signs the budget. An emergency is a good time to get the upgrade funded.

After: Prove It, Then Look Backwards

"We ran the update" and "the update worked" are different statements. Verify.

• Check the version. Have someone look at the version number actually running and compare it to the fixed release. A server can have the update downloaded and still be running the old code until a restart.
• Check everything that uses it. The website you remember may not be the only one. Old test sites and secondary domains often share the same server.
• Look for signs of earlier trouble. If a flaw was being exploited before you patched, the patch doesn't remove someone who already got in. Ask your IT provider to review logs, check for unfamiliar files and new admin users, and look for unexpected outbound traffic or the web server starting programs it normally wouldn't. Start the review from the earliest known attack, not the patch date. For PHP2Shell, Amazon suggested going back to at least October 17. Keep those withdrawn reports in mind, though: odd behaviour isn't automatically this particular bug.
• Rotate secrets that lived on the server. Database passwords, API keys, payment gateway keys and anything stored in configuration files should be treated as seen if the server was exposed and unpatched while attacks were going on. Researchers showed that these flaws can also leak the contents of the server's memory, which can include exactly those passwords and keys.
• Decide whether anyone has to be told. If personal information may have been accessed, you may have to report it. Under PIPEDA, a breach that creates a real risk of significant harm must be reported to the Privacy Commissioner and to the people affected. You also have to keep a record of every breach, including the ones you don't report. Our PIPEDA compliance guide explains how that test works. Also check your cyber insurance policy, since many require prompt notice.
• Hold a short review. Twenty minutes. What did we not know we had? Who was slow to respond and why? What do we change?

How We Handle This at ACE IT

We hold ourselves to the same steps we've just suggested to you. When an alert like this lands, we check our own inventory for the affected software first, take backups before touching anything, apply the fix, and write down what we found and when. It's a short exercise when the list already exists, which is the point of keeping one. None of this makes anyone immune, and new flaws turn up every week. The difference is finding out in an hour instead of a month.

When something like this lands for our clients, we tell them what we looked at, what we changed and when, and what we're still waiting on from a vendor.

A Checklist You Can Copy

People

• One named owner for security advisories, with a backup
• A named owner for each system, including vendor-hosted ones
• A phone number for your IT provider and host that works after hours

Inventory

• Every website, server, appliance and hosted tool listed
• Software versions recorded and reviewed at least quarterly
• End-of-life systems marked, with a replacement date

Alert sources

• Canadian Centre for Cyber Security and CISA alerts subscribed
• Vendor bulletins for your main platforms
• MSP and host asked to notify you directly

Patch targets (a starting point, adjust to your business)

• Critical, exploited, internet-facing: hours, same day
• Critical, not yet exploited, internet-facing: within 3 days
• High severity, internal only: within 2 weeks
• Medium and low: the monthly cycle

Before and after

• Backup taken and restore confirmed before the change
• Rollback person named
• Version checked after the change
• Logs reviewed for the weeks before patching
• Credentials rotated where the server was exposed
• Breach and insurance notice decision recorded
• Short review held and changes written down

Related Reading

Patching routines are covered in our piece on automated patch management. If you suspect an attacker got in, start with the first 60 minutes of a cyber incident. For the bigger picture of what happens when one missed update leads to something worse, see ransomware in the GTA, and check what your insurer expects in cyber insurance requirements.