PHP Critical Vulnerability October 2026 (CVSS 9.2): How It Was Found, How the Exploit Works and Is There a PoC?

by Remiz · October 21, 2026

Yesterday the PHP security team posted something you don’t see very often on php.net. An advance notice. Not a release, not a changelog. Just a heads-up that something big is coming.

Two critical vulnerabilities. Both rated CVSS v4.0 9.2. Fix scheduled for Wednesday, 21 October 2026 at 14:00 UTC.

That’s it. That is the whole announcement.

And within hours, the search boxes started filling up. “php vulnerability october 2026 exploit”. “php 9.2 cve poc github”. “how does the new php rce work”. If you landed here after typing something like that, welcome. Grab a chair. I’ll tell you exactly what is known, and you might not like the answer.

What Did php.net Actually Announce?

Here is everything the PHP team has said, in plain words:

There will be a security release on 21 October 2026 at 14:00 UTC.
It fixes two critical vulnerabilities.
Both are rated CVSS v4.0 9.2.
All PHP users should get ready to upgrade as soon as it is out.
They may release earlier if details leak or if they see it being exploited in the wild.
Full details, affected versions and fixed versions will be published with the release.

Read that last line again. The details come with the release. Not before.

So How Does the Exploit Work?

Nobody outside the people involved knows. Honestly.

There is no public write-up. No technical breakdown. No CVE description with a juicy paragraph explaining which function breaks. The PHP team is doing exactly what responsible maintainers should do. Keep the details private until the patch exists, so that millions of sites get a fair head start.

A 9.2 score tells you it is serious. It does not tell you what it is. It could be in the core engine, could be in a bundled extension, could be in something like the FPM side. Anyone telling you which one, today, is guessing.

How Was It Found?

Also not public yet. Usually the credits and the story behind a finding ( who reported it, how they found it, fuzzing, code review, a bug bounty) come out together with the advisory or a little after it, sometimes as a nice blog post from the researcher. If that happens, it will be worth reading. But that is after the fix, not before.

Which PHP Versions Are Affected?

Not announced. The team said affected versions will be listed with the release. If you see a site with a confident table of “affected: 8.x.x to 8.x.y” today, ask yourself where they got it from.

Is There a CVE Number Yet?

Not publicly linked to this announcement at the time I am writing this. You might see CVE IDs reserved somewhere, but a reserved ID with no description tells you nothing about the bug.

Is There a PoC on GitHub?

This is the part I really want people to read.

Whenever a big vulnerability is announced but not detailed, fake “PoC” repos show up on GitHub, Telegram and random forums within a day. Some are just empty clickbait. Some are a lot worse. Security researchers have reported many such fake exploit repos that actually contain malware, built to infect the machine of whoever downloads and runs them. Think about who runs a PoC the day after an announcement. Exactly the people who are curious, in a hurry and not reading the code carefully.

So if you find a “working PHP 9.2 RCE exploit” today, the most likely thing it exploits is you.

A Note for Those Hoping to Get In Early

Let’s be honest. Some people searching for this are hoping to find something usable before everyone patches. If that is you, I am not going to help with that, and neither is anyone legit right now, because there is nothing public to help with. The whole point of this kind of advance notice is to close that window. Server admins, hosting companies and Linux distros are already lined up to push the fix the moment it drops. And the PHP team clearly said they will release even earlier if they see exploitation in the wild.

Spend that energy on something that pays better and doesn’t end badly. Bug bounties are a real thing. The people who found these two bugs are probably going to get credited on php.net. That’s a much nicer way to be part of this story.

If You Run PHP Sites

Just one thing for now. Know which PHP version each of your sites and servers is running, and know how you are going to upgrade it ( your host, your package manager, your Docker image, whatever). That’s all the prep you need until the actual release comes out.

Wait for php.net. Don’t Follow Speculation.

Weird thing is, the less information there is, the more confident the internet becomes. Over the next few hours you will see YouTube videos, tweets and “analysis” posts explaining exactly how this works. Almost all of it will be made up.

The only reliable source is the PHP team itself. Wait for the official release and advisory on php.net, and the security advisories on the php-src GitHub repository. Read the real details there. Don’t download “exploits” from strangers, and don’t build your plans on someone’s guess.

I’ll update this post once the official details are out.

Thank you for reading, and as the PHP team says, thank you for helping keep PHP secure.