A critical flaw in PHP, software that sits underneath a large share of the internet, was patched on October 21. Most businesses run it somewhere without knowing it, and many depend on vendors who run it with their data. This week’s job for leadership is to make sure someone owns the answer to one question: where are we exposed, and is it fixed?
On October 21, the PHP project released emergency fixes for two critical flaws in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed “PHP2Shell.” PHP is the programming language behind WordPress, Drupal, Magento, and a long list of business software. Wiz, the security firm that found the flaws, estimates it powers about 70% of websites, and says every PHP version from the last decade is affected.
The flaws let an attacker take control of a server running PHP without logging in, and can also expose passwords and keys sitting in that server’s memory. CISA told organizations to patch immediately. The UK’s National Cyber Security Centre went further and said to take systems offline if they can’t be fixed right away. Security researcher Kevin Beaumont called it “one of the biggest vulns in years.”
For a business owner, the useful questions are where PHP runs in your business and who is responsible for fixing it.
Why This Isn’t Just a Website Problem
The obvious exposure is a company website. It’s rarely the only one. For a typical Greater Sacramento business, PHP shows up in three places, and each needs a different owner.
The website, client portals, intake and payment forms, booking pages, internal tools on an office server, and old test or staging copies nobody remembers. These are your responsibility to patch, or your IT provider’s.
Many network appliances, storage devices, and vendor-installed applications include a web-based admin page, and some of those are built on PHP. They are often the slowest things in an office to get updated. As forensics expert Hal Pomeranz put it, “There will be a long tail for this one.”
Practice management, payroll, CRM, document portals, and hosting providers may run PHP on their side. You can’t patch their systems, but your client data lives there, so their exposure is your exposure.
There’s also a second-wave risk. Because the flaw can leak passwords, API keys, and login tokens from server memory, a system that was exposed before it was patched may have handed over credentials that still work afterward. Patching closes the hole. It doesn’t undo what may have already leaked.
What the Government Agencies Recommend
CISA, the FBI, the UK’s National Cyber Security Centre, and CERT-EU have all issued guidance, and they agree closely. Their steps are written for the people who manage systems, which for most small businesses means an IT provider, web host, or developer. Your role is to make sure each one is happening and to ask the right question when it isn’t clear.
Your Part This Week
Three things are worth doing yourself, because nobody else at the business is likely to.
- Get answers to the questions above.One conversation or email with your IT provider, host, or developer. If you don’t have one, or nobody is clearly responsible, that gap is the first thing to fix.
- Deal with the site or portal nobody maintains.An old website a freelancer built, a forgotten portal, a test copy still online. Every agency says to take unpatchable systems offline, and these are the most likely to be unpatched. Assign an owner this week or take it down.
- Watch for word from the vendors that hold your most sensitive data.Payroll, practice management, client document portals. Most will publish a notice. If you haven’t seen one by the end of the week, ask.
For your IT team: patched releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The PHP team published source backports for 7.4 through 8.1, and Linux distributions and long-term support vendors are shipping their own packages. NCSC-NL maintains a list of software products with a PHP dependency that may be affected.
Where Things Stand
Updated October 23, 2026
Attackers are actively trying to use these flaws. Amazon’s threat intelligence team reported that PHP2Shell “is now seeing broad exploitation attempts in the wild,” and that working exploits appeared within hours of the patch being released. Arctic Wolf and other security firms have reported widespread scanning across the internet.
Amazon also found an exploitation attempt dated October 17, four days before the public disclosure, and advises organizations to investigate from at least that date rather than from the day the patch came out. That matters for any system that was online and unpatched last week.
What hasn’t been publicly confirmed yet is how many of those attempts succeeded. Sophos reported scanning and failed attempts without evidence of a successful compromise, and Amazon said it was unclear whether the attempts it saw would have worked on real systems. For a business, the distinction doesn’t change the advice. The attacks are underway, so patching can’t wait for confirmed victims.
On October 23, the PHP project also disclosed a related issue (CVE-2026-115560) that only affects an unusual configuration. PHP says it’s unlikely in practice and recommends a setting change until its next routine release. It’s worth one extra question to your IT provider: “Have you reviewed the October 23 PHP advisory as well?”
The bigger lesson. The flawed code sat in PHP for more than a decade. Wiz says turning it into a working attack required steps “at the edge of what human researchers could practically achieve,” and that AI models made it practical in about a week.
Attackers have access to the same capability. The gap between a flaw being disclosed and it being used is getting shorter, which turns two questions into ongoing business requirements: do we know what we run, and how fast can we fix it? A business that can answer both this week is in good shape for the next one.
If a system holding customer information turns out to have been compromised, decisions about notification belong with counsel, but they depend on technical facts gathered quickly. California now sets a 30-day window for notifying affected residents, so preserve logs and don’t wipe a system you suspect was breached before someone has examined it.
Need a straight answer on your exposure?
In 15 minutes, we’ll help you identify where to start, which systems and vendors need attention, and what to ask your IT provider.
Schedule a 15-Minute CallSources: Wiz Research, “PHP2Shell” (Oct. 21, 2026): wiz.io • PHP release announcement: php.net • CISA, “Critical Vulnerabilities in PHP Require Immediate Patching” (Oct. 21, 2026): cisa.gov • UK NCSC, “Critical security issue affecting PHP” (Oct. 21, 2026): ncsc.gov.uk • CERT-EU Security Advisory 2026-018: cert.europa.eu • FBI Cyber Division statement: x.com/FBICyberDiv • NCSC-NL affected software list: github.com • Help Net Security, including Beaumont and Pomeranz comments (Oct. 21, 2026): helpnetsecurity.com • watchTowr FAQ: watchtowr.com • The Hacker News: thehackernews.com • Amazon Threat Intelligence, PHP2Shell exploitation in MadPot (Oct. 21, updated Oct. 22, 2026): aws.amazon.com • Arctic Wolf: arcticwolf.com • The Hacker News, additional PHP advisory (Oct. 23, 2026): thehackernews.com
