MSUFCU turned its own website off. That was the right call.

ENGINEERING

OCTOBER 22, 2026

MSUFCU turned its own website off. That was the right call.

11 min read

A PHP flaw became unauthenticated remote code execution with no workaround, so banks and governments went dark on purpose. What happened in Lansing, and why.

If you bank in the Lansing area, your Wednesday probably included a moment of quiet panic. MSU Federal Credit Union's website stopped answering. Online banking stopped answering. The mobile app stopped answering. ComputerLine stopped answering.

Your card still worked. So did everybody else's.

That combination is the whole story, and almost nobody reading the headline got it. This was not a breach. It was a credit union reading a federal advisory, deciding it could not vouch for one part of its estate, and switching that part off while leaving the rest running.

In my line of work, that is not a bad day. That is the drill going correctly.

What went wrong, in plain English

On Tuesday 20 October, two vulnerability identifiers started circulating on social media with incorrect details attached. On Wednesday 21 October, the PHP project published an advisory and emergency patches — a day earlier than planned, because the leak had already started the clock.

The two flaws are CVE-2026-109618 and CVE-2026-109619, nicknamed php2shell. Both scored 9.2 out of 10 on the CVSS v4.0 scale. Both let an unauthenticated attacker — no password, no account, no foothold — run their own code on a server that merely serves web requests.

PHP is the language behind most of the websites whose back-end language can be identified. If you run WordPress, you run PHP. That is a large share of the small business websites in Michigan.

The mechanics matter, because the shape of these bugs is the reason there was no easy fix:

CVE-2026-109618 — when PHP runs out of memory partway through setting up a request, it can leave its own internal bookkeeping half-finished, and the cleanup code then trusts that half-finished data as if it were complete. On Apache with mod_php this can be triggered before a single line of the application's own code has run. Your login page, your input validation, your firewall rules — all of it sits downstream of the bug.
CVE-2026-109619 — PHP can keep internal state that outlives the memory it points at, so the next request the same worker process handles can act on freed memory. A use-after-free, reachable from the open internet.

The earliest affected code path dates back to PHP 5.4.0, released in 2012. This sat in plain sight for 14 years.

Why would a credit union turn its own website off?

Because this time there was no third option, and that is unusual.

Normally a critical bug means a tense afternoon: apply the patch, restart the service, go home. There is usually a middle path too — a firewall rule, a disabled feature, a config flag that closes the door until you can patch properly.

Not here. The PHP project's own position was that no configuration change fully mitigates these vulnerabilities. There was no flag to flip. CISA's alert said it plainly: patch immediately, and for anything that cannot be patched right now, take it offline.

That is why Wednesday looked like a coordinated global outage. It was the absence of a middle option. Within hours, government websites went dark in Finland, the Netherlands, Germany, Belgium, France and Canada. In Japan, Mizuho's banking and securities arms halted services, Shizuoka Bank suspended its site and app, companies in the MUFG group pulled online services, and Japan Airlines, East Japan Railway and Seven-Eleven Japan took web services down. Across Europe, schools and hospitals did the same.

And in East Lansing, a credit union did exactly what the advisory said to do. MSUFCU said the shutdown was intentional, taken so that every recommended update, patch and protection could be applied before service came back. Online and mobile banking returned Thursday afternoon, with remaining features restored in phases as systems were validated. The credit union said there is no indication that member information was compromised.

One honest limitation

I do not know that MSUFCU was running PHP, and neither does anyone writing about this from the outside. No public source establishes it. They may have had direct exposure, they may have had a vendor with exposure, or they may have taken the whole digital estate down as a precaution while they worked out which.

I am leaving that unresolved on purpose, because the uncertainty is the lesson. From the outside you cannot tell what a company's software is made of. From the inside, most owners cannot either.

The part that should bother you more than the bug

The bug is fixed. The disclosure is the part I would still be thinking about.

Defenders are supposed to get a head start — the patch lands, then the details become public, and there is a window to update before anyone can act on them. That window did not exist.

Four days before the advisory, Amazon's threat intelligence team saw probing against its decoy servers. The identifiers leaked onto social media the day before. Then, hours before the coordinated release, a vendor broke the embargo and published container images containing the fix. A patched binary is a diff, and a diff is a map.

Cloudflare reported thousands of exploitation attempts in the ten hours before the public announcement. Tens of thousands within forty-five minutes of it. Hundreds of thousands within two hours. Millions in total. One researcher had a working exploit built inside a day.

By the time the people who had to patch were told what to patch, the people attacking it had been at work for days.

The scoreboard, as of today

Here is where I disappoint anyone who wants this to be a disaster story.

As of 22 October 2026, no successful break-in has been publicly confirmed anywhere. Germany's federal cyber agency said the flaw turned out to be harder to exploit than expected. The Netherlands reported no indication of active misuse. Japan's government confirmed no attacks exploiting the flaws. CISA had not observed exploitation as of its Wednesday alert.

Set against that, Amazon's security chief stated that php2shell is now being broadly exploited in the wild. Both things are true at once: an enormous number of attempts, and no confirmed success. Millions of attempts against a patched server is just traffic.

I am stating the date on that, because it is exactly the kind of sentence that goes stale quietly. If you are reading this well after October 2026, go and check whether it still holds.

The AI part, which cuts both ways

This flaw was found with AI, and that is not a press release.

A researcher at Calif.io found the first issue on 1 August 2026 using one of OpenAI's models. OpenAI investigated and turned up more of the chain. The security firm Wiz found both bugs independently, also using AI models. The PHP Foundation credited all three.

The interesting detail is why AI mattered. The underlying flaws had been in PHP for over a decade, sitting in one of the most-read open-source codebases on earth, reviewed by thousands of people. What stopped anyone exploiting them was not secrecy. It was that proving exploitability required chaining together a sequence of steps right at the edge of what a human researcher could practically hold in their head.

That barrier is where the safety was. And that barrier just moved.

Good people got there first this time, which is the only reason this story is about websites going offline for a day rather than about what was taken. But the capability that found a decade-old memory corruption bug in PHP is generally available, and it does not care who is holding it. The honest summary is that the defenders won this race by a few weeks, and the race itself got faster for everybody.

What I checked in my own systems

Before writing any of this I went and looked, because I would rather give you a number than an opinion.

Across everything I run — my own agency's systems, the software operating my handyman company, client applications and about a hundred serverless functions — there is no PHP at all. No PHP source files. No PHP interpreter installed on the machine that runs the lot. Every function is Node or Python.

That is a comfortable answer and I want to be careful not to oversell it, because it only covers code I wrote. It says nothing about a vendor's admin portal, a marketing site somebody set up years ago, or a plugin inside a plugin. For most businesses that is exactly where the exposure lives — and "I don't use PHP" is almost never the same sentence as "I'm not exposed."

Which brings me to the only part of this that is actually about you.

Four questions worth asking this week

Does your website run WordPress? If yes, it runs PHP. That is not a criticism; WordPress runs a large share of the internet and runs it well. It is just a fact you should know about your own business.

Who patches it, and did they, on Wednesday? If the answer is "the guy who built it, I think," that is worth a phone call today. If you are on managed hosting, most hosts patched this within hours — but most is not yours.

If your website had to go off for a day, what else would stop working? This is the question MSUFCU had already answered before Wednesday. Their cards kept working because card processing is not downstream of their website. Your contact form, your booking calendar, your quote requests, the number customers tap to call you — if all of that lives in one place, you do not get to make the choice MSUFCU made. You just go dark.

Would you even know? Not whether you were attacked. Whether your site is down right now. Most small business owners find out from a customer, and the ones who find out from a customer find out late.

That last one is the one I care about most, because it is the cheapest to fix and the most commonly ignored. Every monitor I build has to make its own failure louder than its success. If a check breaks, I want an alert on my phone, not silence that looks like health.

MSUFCU had a plan, executed it, lost a day of digital banking, kept the card rails up, and told members what was happening while it was happening. For an institution that size, that is a good week, not a bad one. The businesses that had a bad week were the ones who found out on Thursday.

Sources

Primary:

On MSUFCU:

Technical analysis:

Exploitation telemetry, the global response, and the discovery:

If you want the cheap version of question four, I run a free check that loads your site in a real browser and tells you what is broken on it — no signup, no email, nothing to buy: run the website check.

And if you would rather talk about the whole picture, the free 30-minute Operations Audit is where I look at how your business actually runs and tell you what I would automate first — including when the answer is "nothing yet."

11 min read