PHP Emergency. Know Where Your Organization Stands
If you've seen headlines this week about a "PHP emergency," you're probably wondering what it is and whether it touches your organization. The short answer: it might, and it's worth finding out this week.
On October 21, 2026, the team that maintains PHP, the behind-the-scenes software that runs most of the world's websites, released an urgent fix for two serious security flaws. The same day, the federal Cybersecurity and Infrastructure Security Agency (CISA) urged organizations to update immediately.
You don't need to be technical to understand what this means for you. Below, we break it down in plain English: what happened, what's at risk, and the questions to ask your IT provider.
What is PHP, and what went wrong?
Think of PHP as the engine under the hood of a website. Visitors never see it, but it's what makes the contact form send, the client portal log in, and the payment page work. According to W3Techs, nearly 70% of websites run on it.
The flaws found in PHP, nicknamed "PHP2Shell," are like a defect that lets a stranger take control of that engine remotely, without a key. They don't need a password. They don't need anyone at your organization to click a bad link. They just need your website to be online and running an unpatched version.
Both flaws are rated 9.2 out of 10 for severity. Worse, details leaked online on October 20, a day before the fix was ready, and watchTowr and other security firms soon spotted criminals actively attacking websites.
What could an attacker get?
A website is often more connected than people realize. If an attacker takes control of the server behind it, here's what could be within reach:
Client information. Intake forms, contact requests, uploaded documents, and portal logins all pass through your website. Whoever controls it can read and copy them.
Passwords and digital keys. Researchers showed attackers can also peek into the server's memory. Qualys notes that memory can hold passwords and the digital keys that connect your website to other systems.
Your other systems. Those keys often unlock email, billing, scheduling, or document platforms. A website problem can quickly become an organization-wide problem.
Your reputation. An attacker who controls your website controls what visitors see. That could mean fake payment instructions or scam pages showing up under your name.
Why this one is such a big deal
Most security flaws affect one product. This one sits in the foundation that millions of websites are built on, so everything on top of it inherits the risk.
It's everywhere. WordPress sites, client portals, and custom-built tools commonly run on PHP. CISA says the flaws affect every PHP installation that serves web pages.
Training can't stop it. Staff education helps with phishing emails. It does nothing here, because no human mistake is required.
Criminals got a head start. Amazon and Cloudflare both reported attack activity, and Cloudflare saw attackers trying to slip past its protections.
Why this matters for law firms, CPA firms, and business leaders
Your website is no longer just a digital brochure. For many organizations it collects client details, accepts document uploads, takes payments, and links to client portals. That puts it squarely inside your responsibility to protect client information.
For attorneys: ABA Model Rule 1.6(c) requires reasonable efforts to keep client information safe. Leaving a known, actively exploited flaw unaddressed is hard to call reasonable.
For CPAs and tax professionals: The FTC Safeguards Rule requires a written security plan, and IRS Publication 4557 spells out what the IRS expects. Both assume you know what systems you rely on and keep them updated.
For every business leader: Cyber insurers and larger clients increasingly ask how quickly you fix serious security issues. "Our web person handles that" is rarely an answer they accept.
Your exposure doesn't end with systems you own, either. The client portal, e-signature service, payment page, or hosting company you use may run PHP behind the scenes. Even Cisco issued an advisory for its own products affected by these flaws.
Older websites face the biggest risk
Like a phone that stops getting updates, older versions of PHP may not get this fix at all. The newest versions are fixed. Some older ones only have partial fixes, and the oldest have none.
That's a bigger group than you might think. W3Techs data shows roughly one in three PHP websites still runs one of those older versions.
This is common in professional services. A website built years ago and left alone because "it still works" is exactly the kind of system that slips through the cracks. If that sounds like yours, it should be at the top of your list.
So, should you be worried?
Not panicked, but you should get answers this week. The organizations that get hurt by flaws like this usually aren't the ones that heard the news. They're the ones that assumed someone else took care of it.
You don't need to understand the technology to stay on top of this. You just need clear answers from whoever manages your website and online tools, whether that's an IT provider, an internal IT team, or your web host. Here are five questions to send them today:
Do any of our systems run PHP? Ask about the website, client portal, internal tools, and anything a vendor hosts for us.
Has every one of them been updated with the fix? Ask for a yes or no for each system, not a general "we're on it."
Are any of our systems too old to receive the fix? If so, ask what the plan is to replace them, the target date, and what protects them in the meantime.
Have you checked whether anyone got in before the fix? Attacks started before most systems were updated. Installing the fix today doesn't remove an intruder who got in last week.
Have our outside vendors confirmed they're protected? Ask your portal, payment, and hosting providers to confirm in writing.
A note to forward to your IT team: the fixed releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Versions 8.1, 8.0, and 7.4 have only limited fixes, per Qualys.
"We fixed it" isn't the same as "we can prove it"
The riskiest answer to those questions is "I think so." Fixes like this one are easy to miss. Qualys points out that a single server can hold several copies of PHP, and updating one can leave the others exposed. The fix also doesn't take effect until the system restarts.
That's why the answer you want is evidence, not reassurance. That means a list of where PHP runs, confirmation that each system was updated and when, and a documented check that no one got in. Clients, insurers, and regulators increasingly expect to see exactly that.
This is what we mean by Evidence-Based Security & Accountability. Shield IT Networks works alongside your existing IT provider or team, not in place of them. We verify what was done, document it, and help close any gaps, so your organization can show its work.
Know where your organization stands
This isn't the first website emergency this year, and it won't be the last. Just three months ago, a similar flaw hit WordPress, and attackers began exploiting it within hours of the fix. The organizations that come through these moments well are the ones that already know what they run and who is accountable for it.
If you're not sure where your organization stands, we can help you find out. A Cyber Readiness Assessment gives you a clear, documented picture of your risk, from your website and client portals to the vendors behind them, in language your whole leadership team can understand.
Sources
Comments