So Apparently PHP Had a Bug Sitting There for Years. And Then AI Found It.

And then I quietly go back to my Flutter code.

Unfortunately, my company uses PHP.

So when I started seeing news about two critical vulnerabilities in PHP that were suddenly causing websites to go offline, my first reaction was not:

"Wow. This is an important cybersecurity event."

It was more like:"Oh."

"This is actually our problem."

So obviously, I started reading. And the more I read, the more ridiculous the whole thing became.

Two critical vulnerabilities. Remote code execution. Millions of websites potentially affected. Companies and governments taking services offline. AI helping researchers find and develop the exploit.

And the bugs?

They had been sitting inside PHP for more than a decade.

Apparently they were just waiting for their moment.

Okay. What Actually Happened?

On October 21, 2026, the PHP team released emergency security updates for two critical vulnerabilities:

• CVE-2026–109618
• CVE-2026–109619

They've since been referred to as PHP2Shell. Both vulnerabilities affect the PHP runtime itself and were rated 9.2 on the CVSS scale. The scary part is that successful exploitation can allow an attacker to execute code remotely without authentication on vulnerable systems. wiz.io And this isn't a vulnerability hiding inside one obscure PHP package. It's in PHP itself. That distinction matters.

You could have a perfectly secure application sitting on top of a vulnerable PHP runtime and still have a problem.

Which is a slightly uncomfortable thought. Especially if you're someone who has spent three hours checking your application code only to discover the actual problem is somewhere underneath it.

The Bug Was Older Than Some of My Code

This is the part that got my attention.

The vulnerabilities affect PHP versions going back to PHP 5.4, meaning the underlying problematic code had been around for more than a decade. wiz.io

And before someone reads that and thinks:

"So there was an RCE sitting there for 10 years?"

Not exactly. Vulnerable conditions existed for years. But turning them into a reliable, remotely exploitable attack required chaining multiple memory-safety problems together and dealing with things like PHP's memory layout, request handling and different application configurations.

In other words:

The bug existed. The practical exploit was the hard part.

And apparently that distinction became much less comforting in 2026.

Why Was It So Difficult to Exploit?

The vulnerabilities involve memory-safety issues in PHP's core engine.

Very simplified version: PHP can hit certain fatal or out-of-memory conditions while processing a request. That can leave internal state in a bad condition. A later request or worker can potentially reuse that stale state. And from there, an attacker may be able to read or corrupt memory. Eventually, that can become remote code execution. wiz.io

I say "very simplified" because the actual technical details get deep very quickly. And I have a healthy respect for my own limitations. I am a Flutter developer. I am not going to read one memory-corruption research paper at 2 AM and suddenly become the final boss of exploit development.

Although, knowing me, I would probably try. Then spend the next three hours wondering why the exploit doesn't compile.

And Then Websites Started Going Offline

This is where the story stopped being an interesting security article and became an actual internet problem.

Governments, companies and public institutions around the world temporarily took websites and services offline while they assessed and patched their systems.

Reuters reported outages across Europe, Asia and North America, including government portals and public services. Organizations in Germany, France, Belgium, the Netherlands, Finland and the Czech Republic took services offline, while other organizations including the Wikimedia Foundation and Internet Archive also temporarily restricted services.

And this wasn't necessarily because all of those systems had already been hacked. A lot of the shutdowns were precautionary.

Basically:

"We don't know whether we're vulnerable enough yet, so let's remove the thing from the internet while we figure it out."

Which, honestly, is probably the least exciting but most responsible sentence in this entire story.

Final Thoughts

I'm still a Flutter developer.

I still have plenty of problems that can be solved by staring at an error message for 20 minutes and then changing one line of code.

But incidents like PHP2Shell are a good reminder that the applications we build don't live in isolation.

"Apparently sometimes the backend problem becomes everyone's problem."

— Shivani Bagal 🤍