Somebody has probably forwarded you an article with "PHP2Shell" in the headline by now, maybe with a note from the CEO asking whether we're OK. If you're like most finance leaders I know, you're pretty sure this is IT's problem and you'd still like a better answer than "I'll check." So this is my attempt at that better answer, covering the PHP2Shell vulnerability, the Node.js bug that dropped the same day and a few other bad ones from the past week, with most of the attention on what they could end up costing you.
What PHP2Shell is, in plain English
PHP is the language behind a huge share of the web, from WordPress sites and customer portals to the admin screen on some piece of equipment your plant bought in 2017. On October 21, 2026 the PHP project shipped emergency fixes for two flaws, CVE-2026-109618 and CVE-2026-109619, that let an attacker run their own code on a web server without ever logging in. CISA's alert says every PHP installation serving web requests is affected and tells organizations to move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 right away.
A couple of things make this worse than an ordinary patch cycle. Details leaked online before the fix was ready, so attackers had a head start, and Palo Alto Networks' Unit 42 team counted more than 22.6 million internet-facing instances that could be vulnerable. Cloudflare saw millions of exploit attempts within about a day, and Amazon's threat team found one dated October 17, four days before anything was announced. By October 24 a researcher had watched attackers open 35 working shells on his honeypots (decoy servers built to get hit), SecurityWeek reported, and some attackers were trying to plant a botnet called Potassium. Nobody had confirmed a real company getting breached as of October 26, and CISA still hadn't put the flaws on its known-exploited list, though I wouldn't count on that lasting long when a public exploit already works on decoys. PHP also disclosed a third flaw on October 23, which it says only affects unusual setups.
For a CFO, the bigger issue is where PHP hides. Cisco's advisory lists some of its own products as affected, with at least one fix not expected until February 2027, and even Tenable had to patch the PHP inside its own security scanner. When an old PHP version is baked into a vendor's appliance, your IT team can't update it themselves and has to wait for the vendor to ship something. Versions 8.1 and older get limited help at best, which is why CISA suggests taking PHP systems offline if they can't be patched.
The Node.js bug, and why it got less attention than it deserves
Node.js runs a lot of newer web apps and internal tools. On the same day, the Node.js project released fixes for ten flaws across every supported version, and the worst of them, CVE-2026-111497, sits in the code Node uses to unpack Brotli-compressed data. Node's own advisory says it can allow remote code execution. Node unpacks that kind of data on its own whenever an app fetches a compressed web page, so your developers could have done everything right and still be exposed.
How dangerous it is in practice is less clear than with PHP. According to The Hacker News, the public proof of concept only worked against a deliberately weakened test build, and nobody had reported attacks in the wild as of October 22. The flaw lives in the Brotli library itself, though, so fixes are rolling out to other software that uses it. And Node.js 20 reached end of life on April 30, 2026, so anything still on it gets no fix. If your team has a list of upgrades they keep pushing to next year, ask to see it this week, since anything on Node 20 probably belongs at the top now.
The other big ones from the same week
Three more from the past week deserve a line in your risk register. GitLab, which plenty of engineering teams host themselves to store source code, shipped a critical patch on October 21 for a flaw rated 10.0, the top of the scale, that could let an attacker run code on the server without logging in. Nobody had reported exploitation yet, but source code servers tend to hold passwords and keys to other systems, so an attacker who gets in there often has a path to a lot more.
Arista's VeloCloud Orchestrator manages an SD-WAN product that multi-site companies use to connect plants and branches, and CISA added a flaw in it, rated 9.9, to its exploited list on October 23. An attacker needs a logged-in account, even a read-only one, but Arista says it's being used in real attacks.
The same day, CISA added a flaw in Collabora's built-in document server for Nextcloud, a self-hosted file sharing tool, after attackers used it to plant web shells. Collabora says few Nextcloud users run that piece, mostly home users, so it's probably not you, but I'd still put it in the email to IT.
What this means for a mid market CFO versus a large enterprise one
This plays out differently by company size, and I'm generalizing here.
At a $50 million manufacturer, the main website usually has someone watching it, whether that's IT or the agency that built it. The places I'd look are a customer portal a contractor built years ago, a PHP tool on a server nobody's touched since the person who set it up left, or a supplier's hosted ordering page. Small IT teams lean on outside providers, so a good part of your exposure comes down to how fast those providers patch. That belongs in the same conversation you'd have about a supplier starting to wobble: how quickly do they move when something breaks, and would you hear about it from them first or from the news?
A large enterprise has more of everything. There's probably PHP and Node in hundreds of places, plenty of them inside vendor products, and the hard part is finding them all. Patching the main stack might take days, while getting every appliance vendor to ship a fix can take months, and somebody has to pay for the stopgaps in between, like firewall rules or pulling a system off the internet. If you're public, the SEC also gives you four business days to disclose a cyber incident once it's judged material, and that call usually runs through finance.
What to do this week
Max De Pree said the first responsibility of a leader is to define reality. In a week like this, that means getting someone in the building to tell you where you stand with dates attached. You don't need to understand memory corruption for that, as long as your questions can't be answered with a shrug.
Ask IT, or your managed service provider, to answer these five in writing by Friday. I've worded them for finance, because each answer ends up on a budget line or in a number someone will ask you about later.
- What's our exposure, counting vendor products, anything a third party hosts for us, and the GitLab, VeloCloud and Nextcloud flaws above? The rest of the list depends on this answer. It tells you which vendors you're relying on, and anything still running Node 20 or PHP 8.1 and older is where the unplanned money shows up, because the fix there is moving the app to a supported version. That's developer or contractor time nobody put in the 2027 budget, so ask for a rough estimate now while you're still building it.
- What's still open, who owns each item, and when does it close? Anything stuck waiting on a vendor becomes a contract question. If a supplier needs months to ship a fix, pull the agreement and see what it says about security obligations, service credits and termination rights, then give whoever signs the renewal a heads-up. If IT controls are in scope for your audit, expect the auditors to ask about this list too, and walking in with owners and dates is a lot cheaper than cleaning up a finding.
- What will the stopgaps cost, and does taking anything offline touch revenue? Firewall rules and extra monitoring usually mean overtime or an outside firm billing by the hour, and an incident response retainer can burn down faster than you'd think. Pulling a customer portal or ordering page offline means lost orders and a sales team fielding angry calls. The UK government ended up with 32 online services unavailable last week, most of them shut down on purpose as a precaution, so get the revenue at risk per day in front of you before IT makes that call alone.
- Does our real patch timing match what we told our cyber insurer? If the application promised critical fixes within a certain number of days and the answer to question two says otherwise, a claim could get contested, and the retention you'd carry is a number you can look up today. Ask your broker whether the renewal questionnaire will ask about this too, because a weak answer there tends to show up in the premium.
- If something goes wrong, how fast does finance hear about it? Very few companies budget for a breach, and the bill runs to forensics, outside counsel, customer notification, maybe credit monitoring, plus the downtime. For a public company it also starts the SEC disclosure clock once someone decides it's material, and that's a hard decision to make well if finance finds out two days late. Agree now on who calls you and how quickly.
After that, send a one-paragraph note to your two or three biggest software and hosting vendors asking whether their products are affected and when they'll be fixed, and keep the replies somewhere your auditors and insurer could see them. If the CEO is the one who forwarded the article, send back IT's answers with a date next to each item. I wrote more about handling the forwarded-article moment here.
CFOmarketIQ sends finance leaders a regular briefing on the outside news that moves their numbers, and the first one is free.
Questions CFOs ask about PHP2Shell and the Node.js bug
Is PHP2Shell being exploited right now?
Attackers are trying, at scale. Cloudflare saw millions of attempts within about a day, and by October 24 a researcher had seen working shells opened on decoy servers, with some attackers trying to install a botnet. As of October 26, 2026 no real company had confirmed a breach and CISA hadn't added the flaws to its known-exploited list. Until IT confirms you're patched, assume you're exposed.
Does this affect us if we don't run a website on PHP?
Possibly. PHP turns up inside vendor appliances and in tools third parties host for you, and Cisco and Tenable both had to patch products that include it. Ask IT whether anything you own or rent runs PHP and faces the internet, including systems a vendor manages on your behalf.
How fast should these vulnerabilities be patched?
CISA told organizations to update PHP immediately and suggests taking systems offline if they can't be patched. Most companies try to close critical internet-facing flaws within a few days. Whatever your policy says, check it against what you told your cyber insurer, because the insurer will go by what's on the application.
What should a CFO ask IT about a critical vulnerability?
Five things: where we're exposed, what's still open and when it closes, what the stopgaps cost, whether our patch timing matches what we told the insurer, and how fast finance hears about an incident. You don't have to check the technical work. You just want every open item to have an owner and a date, with a dollar figure where there is one.
A note on all of this: it is general information, not financial, legal or tax advice. Run anything you plan to act on past your own advisors first.