TL;DR - At 14:00 UTC on Wednesday (00:30 Thursday morning, Adelaide time), the PHP project ships emergency patches for two remote code execution vulnerabilities, both rated CVSS 9.2. Security firm Sansec expects mass attacks to start within 15 minutes of the release. The bugs live in PHP itself, below WordPress and every other application built on it, so the fix lands at the server level and you cannot patch it from your codebase. What you need to do: name the person who owns PHP in your organisation, inventory your internet-facing PHP hosts today, put your host or MSP on standby for tonight's release, and check your version, because anything older than PHP 8.2 gets no official fix.
By The Numbers
| Item | Value |
|---|---|
| Vulnerabilities | 2, both remote code execution |
| CVEs | CVE-2026-109618 and CVE-2026-109619 |
| Severity | CVSS v4.0 9.2 each, per the PHP security team |
| Patch release | 14:00 UTC, Wednesday 21 October (00:30 ACDT Thursday) |
| Expected time to mass attacks | About 15 minutes after release (Sansec) |
| Claimed affected range | PHP 5.4 onward (leaked tool banner, unconfirmed) |
| Official fixes stop at | PHP 8.2; 8.1 and older get none |
| Estimated exposed hosts | ~1.3 million internet-facing (unverified researcher estimate) |
| Exploitation in the wild | None reported as of 21 October (watchTowr) |
On Monday night I found myself reading a PHP release announcement and starting a timer, because a leaked exploit tool called PHP2Shell is supposedly coming for every PHP site on the internet. That is not a normal Monday activity, even for me. The advisory contains almost nothing: two critical vulnerabilities, both rated 9.2, patches arriving Wednesday, and one line doing the work of a fire alarm - we reserve the right to release earlier.
The details had already leaked by the time I read it. A report nobody has been able to locate describes the tool, and a video shows it popping shells on WordPress, Magento, MediaWiki, Laravel, Drupal and WHMCS. WatchTowr confirmed the two CVEs are real. And Sansec, who spend their working days forensically cleaning up compromised online stores, put a number on the timeline that I have not stopped thinking about since: fifteen minutes.
That number is the story. Not the CVSS score, and not the tool with the action-movie name.
The gap between a patch release and mass attacks used to be measured in weeks. Sansec expects this one to run fifteen minutes.
What we actually know, and what we do not
Verified: two remote code execution vulnerabilities in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2 by the PHP security team, scheduled for release at 14:00 UTC on Wednesday 21 October. WatchTowr reports no exploitation in the wild as of Tuesday, and neither CVE is on CISA's KEV catalogue yet.
Unverified: everything dramatic. The name PHP2Shell comes from the leaked tool's own banner. The claim that it works against every PHP version from 5.4 onward comes from the same leak. Ars Technica could not locate the original report. The PHP project will publish affected versions, fixed versions and technical details with the release, so until then the version range is the tool's marketing, not vendor guidance.
I have seen this pattern enough times to know the leaked scope claim is usually inflated while the underlying bug turns out worse than the marketing. Plan around the confirmed part, and verify the rest on Thursday morning. I will update this post once the release lands with the confirmed details.
Fifteen minutes is an operations problem, not a scoring problem
For two decades the industry's patch maths assumed a gap between advisory and weaponisation. Scan on Tuesday, patch inside the SLA, report monthly. That gap is where whole compliance regimes live, and a fifteen-minute window breaks it. If your first sight of this problem is the release announcement itself, you have already lost. The only workable moment is before, which is exactly why the PHP team did something unusual and published a prepare-now advisory two days ahead of a patch with no details in it.
The first prep step is an org chart question
The PHP advisory asks everyone to prepare so they can upgrade the moment the release lands. Wordfence's checklist and Sansec's checklist both start the same way: work out who is responsible for managing PHP.
It sounds like a throwaway line. It is the whole problem. PHP is not an application, it is infrastructure, and it runs underneath WordPress sites, Magento stores, Laravel apps, MediaWiki installs, internal tools and the odd vendor appliance nobody remembers buying. Sansec's advice is blunt: you fix this at the infrastructure level, by updating PHP on the server, and you cannot fix it from within your application's codebase. So the web team that owns the WordPress site cannot patch this vulnerability. Whoever holds the server keys has to, and in a lot of organisations that name is on a contract that expired in 2019.
If you cannot answer "who updates PHP on our internet-facing servers" in under a minute, that is your real exposure this week. The bug is unknown. The ownership gap is certain.
The long tail: PHP 8.1 and older gets nothing
The PHP project only supports 8.2 and later, so servers on 8.1 or older will not receive an official fix at all. Sansec's advice for those sites is to ask your hosting provider to backport the patch or move you to a supported version. If your operating system vendor packages PHP, a backported fix may arrive through normal OS updates. Anything self-managed, compiled from source, or bolted into an appliance is simply exposed from Thursday onward, indefinitely.
One researcher estimated around 1.3 million internet-connected hosts are likely affected, and even if that figure is rough, the shape is familiar to anyone who read my piece on the fridge botnet: the devices nobody can patch stay online, stay reachable, and stay somebody's problem. This time the somebody might be you.
What to do before 14:00 UTC
- Name the owner. One person or team, by name, who updates PHP on each internet-facing server. Write it down.
- Inventory the estate. Every PHP host you expose to the internet, and the version it runs (
php -vtakes ten seconds). - Call your host or MSP today. Ask them to stand by to apply the PHP update as soon as it is released tonight.
- Check the version line. 8.2 and later get the fix. 8.1 and older need a backport or a migration plan, starting this week.
- Book the window and take backups. Site files and database, before you patch, not after.
- Watch php.net. The homepage carries any change to the release time, including an earlier drop.
- When it lands, deploy within hours. Then forward this to whoever runs your servers before Wednesday afternoon. The useful version of this story is the one where they already knew.
Why this could be good
The pre-announcement is the optimistic part of this story. Not long ago the first public word on a bug like this would have been a mass-exploitation headline. Instead we got a coordinated advance notice with a release time, four separate security firms publishing preparation guidance within a day of the leak, and a reserved right to release early if things go loud. The disclosure process has learned from the Log4j-era storms: give defenders runway even when you cannot give them details. None of this is exciting. But it works.
FAQ
Is PHP2Shell real? The two vulnerabilities are real. WatchTowr confirmed the CVEs and the PHP security team has scheduled the release. The name, the version range and the demo video come from a leaked report nobody has been able to locate, so treat them as plausible but unconfirmed until php.net publishes details with the patch.
What time does the patch drop in Australia? 14:00 UTC on Wednesday 21 October is 00:30 on Thursday morning, Adelaide time. The php.net homepage is the source of truth, and the team has reserved the right to release earlier if details leak further or attacks start.
Does this affect WordPress, Magento and other PHP apps? They run on PHP, which is exactly why the fix is server-level. The bug is in PHP itself, below every application built on it, and the leaked video showed it against WordPress, Magento, MediaWiki, Laravel, Drupal and WHMCS. Updating your plugins does nothing here. Updating your runtime does.
I am running PHP 8.1. Am I covered? Not by an official fix. The project supports 8.2 and later only. If your distro packages PHP, a backported fix may arrive through OS updates. If your host manages PHP, ask them today. Anything you manage yourself on 8.1 or older is exposed until you migrate.
Should I take servers offline until they are patched? Some guidance suggests disconnecting non-essential internet-facing systems until they are patched. If a PHP host is internet-facing and nobody can tell you what it serves, it has just become non-essential until Thursday afternoon.
How is this different from a normal Patch Tuesday? Speed and scope. Two 9.2-rated flaws in the runtime underneath a huge share of the web, an out-of-band Wednesday release, and an expected exploitation window measured in minutes rather than weeks.
My Take
The number I keep coming back to is fifteen minutes. Every patch SLA I have ever written assumed the organisation would have days between learning about a vulnerability and meeting it in the wild. That assumption is dying, and the organisations that notice will restructure around preparation instead of response, because preparation is the only variable still under your control by the time the advisory posts.
The second thing is the org chart. Every messy incident I have worked had a moment where somebody asked who owned the thing that broke, and the room went quiet. Who updates PHP on your servers is a question you can answer today for the cost of one conversation. Do it now, while the sky is still blue.
Mathew Clark Founder, SecureInSeconds Currently: refreshing php.net at 00:30 on a Thursday with the rest of the LAMP crowd Drafted with AI assistance - read, verified, and fixed by a human.
Further Reading
- PHP: News Archive 2026 - the prepare-now advisory itself
- watchTowr: PHP RCE FAQ, CVE-2026-109618 and CVE-2026-109619
- Sansec: Critical PHP RCE - what to do, including the backport advice
- Wordfence: PSA - upcoming critical PHP security release
- Huntress: PHP2Shell leaked critical PHP vulnerabilities
- Ars Technica: PHP maintainers tell web devs to prepare for critical patches
- The fridge botnet audit: the EOL devices nobody can patch
- The private key was the number 4: test your estate before the long tail bites
