PHP2Shell (CVE-2026-109618 & CVE-2026-109619): Leaked PHP Flaws and What to Do Now

Shubham JhaOctober 21, 202610 min read

Authors

Shubham Jha

Last checked: October 21, 2026, 08:00 UTC. PHP's fix is due at 14:00 UTC today, and we'll update this post once it's out.

TL;DR

✓PHP has two critical bugs, CVE-2026-109618 and CVE-2026-109619, that researchers say let an attacker run their own code on a server over the internet.
✓PHP rates both 9.2 out of 10 (CVSS v4.0), and the fix ships today, October 21, 2026, at 14:00 UTC (10:00 AM ET).
✓Details leaked two days early, and a demo of an exploit tool called PHP2Shell is already going around. No real attacks have been reported yet.
✓Only PHP 8.2, 8.3, 8.4, and 8.5 will get the fix, so anything older needs an upgrade.
✓Until the fix lands, turning off session.upload_progress.enabled may block one of the bugs. PHP hasn't recommended it, though, and it may not stop both, so patching is the only real fix.

What happened with PHP this week?

On Tuesday, October 20, someone posted on Hacker News that two serious PHP bugs were about to be announced. That post came two days too early.

The bugs were under an embargo, which is a quiet period where the people who know about a flaw keep it secret until the fix is ready. The plan was to tell the world on Thursday, October 22, but once the post spread on social media, that plan fell apart.

Things moved fast after that. A security research firm confirmed the bugs were real and said it had recreated one of them. That same evening, the PHP security team announced it would ship the fix on Wednesday, one day earlier than planned.

The reason this matters so much is where the bugs live. They sit inside PHP itself, the language behind WordPress, WooCommerce, Magento, Drupal, and a huge share of the rest of the web. So even a well-kept site can be at risk if the PHP underneath it is out of date.

What do we actually know so far?

PHP has confirmed only a few facts so far. Everything else comes from the leak and from researchers testing on their own, so it helps to keep the two apart. The table below shows which claims are solid and which ones still need proof.

Claim	Status	Where it comes from
There are two critical bugs in PHP	Confirmed	PHP security team
Both are rated CVSS v4.0 9.2	Confirmed	PHP security team
The fix ships October 21 at 14:00 UTC	Confirmed	PHP security team
The IDs are CVE-2026-109618 and CVE-2026-109619	Widely reported, but PHP's notice doesn't list them	Researchers and CERT-EU
Attackers can run code remotely without logging in	Reported, not yet described by PHP	CERT-EU advisory 2026-018
Every version since PHP 5 is affected	Unconfirmed	The original leak
At least one bug sits in PHP's session upload progress feature	Unconfirmed	Independent researchers
Attackers are using the bugs right now	No reports at our last check	Researchers and incident response teams
The bugs are on CISA's Known Exploited Vulnerabilities (KEV) list or have an EPSS score	Neither at our last check	Public CVE trackers

Keep this table in mind when you read other coverage. Some posts call these bugs a perfect 10 out of 10, but that number came from the leak. PHP's own score is 9.2, and that's the one to go by.

Which PHP versions are affected?

PHP hasn't said yet. It will list the affected and fixed versions when the release goes out, so until then, the safe move is to treat every PHP install you run as at risk.

What we do know is who will get a fix. PHP only patches the branches it still supports, which right now are 8.2 through 8.5. If you're on anything older, no official fix is coming.

PHP branch	Latest release today (no fix yet)	Will it get the fix?	What to do
8.5	8.5.11	Yes	Update as soon as the fix ships
8.4	8.4.26	Yes	Update as soon as the fix ships
8.3	8.3.35	Yes	Update as soon as the fix ships
8.2	8.2.34	Yes	Update as soon as the fix ships
8.1 and 8.0	End of life	No	Upgrade to 8.2 or later, or take the app off the internet
7.x and 5.x	End of life	No	Upgrade to 8.2 or later, or take the app off the internet

Some early posts said PHP 8.0 and 8.1 would get patches. That's not true, since both branches are already past end of life.

Who should worry most?

Anyone running a PHP website or app that faces the internet should pay attention, and that covers a lot of people. WordPress sites, WooCommerce and Magento stores, Drupal sites, and plenty of homegrown admin tools all run on PHP.

WordPress owners should know one thing in particular. WordPress automatic updates won't apply this fix, because the fix is for PHP itself, which WordPress doesn't update. On most managed and shared hosting, your host updates PHP for you, so it's worth asking them today when they plan to roll it out.

What should you do before the patch?

You have a few hours before the fix lands, and they're worth using. Once PHP posts the patch, attackers can compare the old and new code to see exactly where the bugs are. Sansec, a firm that tracks attacks on online stores, expects mass attacks to start within 15 minutes of the release.

Find every PHP server you run. You can't patch a server you've forgotten about, so start with a list, and include old test boxes and side projects too.
Check the PHP version your website actually uses. Running php -v shows the command-line version, which can differ from the one serving your site. To see the real one, make a temporary phpinfo() page in a spot only you can reach, like behind a login or limited to your IP address, and delete it as soon as you're done. If you run WordPress, the version shows up under Tools → Site Health → Info → Server.
Line up your update. If you manage your own servers, get your update steps ready now so you can move the moment the fix ships. If a host manages PHP for you, ask them today to stand by.
Consider turning off session upload progress. This feature tracks file uploads so a site can show a progress bar, and it's on by default. Researchers who studied the leak say at least one of the bugs hides inside it, but PHP hasn't confirmed that or recommended this step. One researcher says it blocks only one of the two bugs, so treat it as a way to buy time. If your site shows upload progress bars, test your upload pages afterward, since that feature will stop working.
Limit who can reach apps you can't patch. CERT-EU advises isolating internet-facing apps from public networks if you can't fix them right away. This matters most for servers on PHP 8.1 or older, since they won't get a fix at all.

To turn off session upload progress, you have to use a config file, because it can't be changed from inside your PHP code with ini_set(). Pick the one that matches how PHP runs on your server:

; php.ini, or .user.ini if you run PHP-FPM or CGI
session.upload_progress.enabled = 0

# .htaccess, only if PHP runs as an Apache module (mod_php)
php_flag session.upload_progress.enabled off

After you edit php.ini, restart PHP-FPM or Apache. A .user.ini change can take up to five minutes to kick in.

What should you do after the patch?

Once PHP posts the fixed versions, you're in a race with attackers, so move quickly.

Update PHP and restart it. Install the fixed version for your branch, then restart PHP-FPM or Apache so the new code actually loads.
Confirm the version your site is running. Check it the same way as before, through a restricted phpinfo() page or WordPress Site Health. The command-line version alone won't tell you whether your website picked up the fix.
Run a quick check for signs of a break-in. The exploit tool was already going around on October 20, so look back to that date instead of the release time. On Linux, find /var/www -name "*.php" -newermt "2026-10-20" lists PHP files changed since then (swap in your own web folder). Any file you didn't put there is a red flag, because attackers often drop a small PHP file called a web shell to get back in later. A clean result doesn't prove a server is safe, so if anything looks off, bring in your incident response team.
Turn session upload progress back on if you need it. If you switched it off and your site uses upload progress bars, turn it back on once you've confirmed the patched version is running.

The hardest step in all of this is usually the first one, because forgotten servers rarely show up on anyone's list. Strobes Attack Surface Management maps your internet-facing assets, so you have a fuller picture of where PHP might be running before the next bug like this one lands.

Book a demo to see Strobes Attack Surface Management on your own internet-facing assets.

How did the leak unfold?

The whole thing played out in about a day. Here's what happened, newest first, with all times in UTC. For the critical flaws that came before this one, see our Top CVEs of September 2026.

When (UTC)	What happened
Oct 21, 14:00	PHP's scheduled security release (still pending at our last check)
Oct 20, evening	A screenshot and a demo video of an exploit tool called PHP2Shell, credited to the research firm Calif, spread online, and CERT-EU issues advisory 2026-018
Oct 20, 19:33	The PHP security team posts its advance notice
Oct 20, a few hours after the post	A security research firm confirms the bugs are real and says it recreated one
Oct 20, 15:20	A Hacker News post warns that two PHP remote code execution bugs are coming

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the nickname researchers gave these two bugs. It comes from an exploit tool of the same name that showed up in leaked screenshots, where it was credited to a research firm called Calif. PHP hasn't used the name, and it hasn't said who found the bugs.

Is CVE-2026-109618 being exploited right now?

Not as far as anyone knows. At our last check, no attacks in the wild had been reported, but that could change quickly once the fix ships.

I'm on PHP 7.4. Will I get a patch?

No. PHP 7.4 is past end of life, so PHP won't release a fix for it. Your options are to upgrade to PHP 8.2 or later, or to keep the app off the public internet until you can.