PHP is about to push an emergency security update that could affect a huge slice of the internet. At 14:00 UTC on Wednesday, October 21, 2026, the PHP security team will ship an out-of-cycle release fixing two critical vulnerabilities, both rated 9.2 out of 10 under CVSS v4.0. Security researchers who studied the flaws under embargo describe them as remote code execution bugs, the kind that can let an attacker run their own code on a vulnerable web server over the internet. If you run anything on PHP, from a WordPress blog to a corporate web app, today is patch day. Here is what is known, what is not, and exactly what to do.
What PHP announced
On Tuesday, October 20, 2026 at 19:33 UTC, the PHP security team published an advance notice on php.net announcing a security release scheduled for the next day, October 21, at 14:00 UTC. The notice says the release addresses two vulnerabilities, each rated critical with a CVSS v4.0 score of 9.2.
PHP kept the notice deliberately narrow. It does not name the flaws, does not describe how they work, and does not list affected versions or the fixed builds. Its official line: full details, affected versions, and the fixed versions will be published with the release.
The team also said the release could arrive earlier than scheduled. Their words: the release could ship sooner should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.
Why the release was announced early: the leak
The embargoed disclosure was originally expected on Thursday, October 22. It broke early after a Hacker News post on October 20 by a user identified as petecooper, who claimed, citing a reliable source, that two critical remote code execution flaws in PHP core were due for disclosure, with reported severity scores of 10.0 and an impact reaching all the way back to PHP 5. The post admitted it had no evidence beyond that claim, and it was later flagged and removed, but screenshots were already circulating.
Security firm watchTowr, which had been studying the flaws under embargo, confirmed on X that the leaked information was real. The company said researchers had been supposed to wait until Thursday at 11:00 a.m. ET, and that it could not share technical details yet for obvious reasons. watchTowr CEO Benjamin Harris told BleepingComputer that the team had reproduced one of the flaws, CVE-2026-109618, in a lab environment, and had not observed exploitation in the wild at the time.
Researchers have started calling the pair PHP2Shell. That nickname comes from the research community, not from PHP itself.
What is confirmed and what is not
There is a lot of noise around this one, so it is worth separating confirmed facts from leaked or unverified claims.
Confirmed by PHP: two vulnerabilities, each CVSS v4.0 9.2, critical severity; an out-of-band security release on October 21, 2026 at 14:00 UTC; full details come with the release; the timeline may accelerate if details leak further or exploitation appears.
Reported by security researchers: both flaws are remote code execution issues, tracked as CVE-2026-109618 and CVE-2026-109619. Those identifiers and the RCE classification come from watchTowr and the leaked material, not from PHP’s official notice, which names neither.
Unconfirmed: the claim that every PHP version from PHP 5 onward is affected. watchTowr’s own FAQ on the flaws says that scope has not been confirmed by an official vendor advisory, and no configuration or feature requirement has been described. The leak’s CVSS 10.0 figure is also unofficial; PHP’s published rating is 9.2. CERT-EU has issued an advisory referencing both CVE identifiers and warning of possible unauthenticated remote code execution, but its assessment draws partly on leaked information, and administrators should weigh official PHP sources over leaked material.
One detail that matters right now: only the four actively supported PHP branches, 8.2 through 8.5, can receive an official fix. Older branches like PHP 8.1 and below have reached end of life and are not getting these patches, which leaves aging servers exposed unless they migrate or use a commercial extended-support provider.
Why this one matters more than most
PHP is the runtime behind an enormous share of the web. Web technology trackers estimate that close to 7 in 10 websites using a known server-side language run on PHP, and that includes most WordPress, Drupal, Laravel, and Symfony sites on the internet. A remote code execution flaw in PHP core is not an application bug you can dodge by keeping one plugin updated. It sits underneath everything the server runs, which is why the PHP team broke its normal release cadence for an out-of-cycle emergency update.
Remote code execution at the interpreter level is the highest-impact class of web server vulnerability. A working exploit can turn into stolen data, defaced sites, injected malware, or a fully compromised server, with no phishing or password required on the victim’s side. That is why even the possibility of pre-authentication exploitation, which CERT-EU flagged in its advisory, is getting serious attention from security teams.
What to do today
1. Inventory every PHP installation
Find out where PHP runs in your environment before the patches land. That includes production web servers, staging boxes, container images, serverless runtimes, and any legacy installs nobody has touched in years. On Linux, php -v gives you the version; Docker users should check their base images. Note anything running an end-of-life branch, since those will not get this fix through official channels.
2. Prepare for an immediate update
PHP’s message is unambiguous: prepare now so you can upgrade as soon as the release is available. Line up your maintenance windows, confirm who is authorized to run updates, and make sure backups of your applications and databases are current. Shared hosting and managed WordPress customers should contact their provider or check their status page, since hosts typically roll out PHP updates across their fleets.
3. Update the moment the release is out
Once the 14:00 UTC release drops, apply the fixed PHP builds to every supported branch you run. The fixed builds will be the newly released versions on the 8.2 through 8.5 branches, with the exact numbers announced at release time. Prioritize internet-facing servers first.
4. Watch for exploitation and technical details
As of the morning of October 21, no in-the-wild exploitation had been reported, and watchTowr is withholding technical details until patches are available. That grace period is likely short, because researchers are already racing to reverse-engineer the fixes, and attackers do the same. A working proof of concept could appear within days of the release, so do not treat the no-exploitation status as a reason to delay.
5. Harden what you cannot patch
Systems stuck on end-of-life PHP cannot get this fix officially. For those, tighten everything around the application: restrict inbound traffic with a firewall or web application firewall, disable unused PHP functions, turn off display of error output, and plan the migration to a supported branch as a matter of urgency. These are general hardening measures, not specific mitigations for these two flaws, since no workaround has been confirmed.
What WordPress and CMS site owners should know
If your site runs on WordPress, Drupal, Joomla, or any other PHP-based platform, the underlying interpreter is what matters here, not your theme or plugins. A fully updated WordPress install on a vulnerable PHP build is still vulnerable. Check which PHP version your host provides, ask your host when the security update will be applied, and apply it as soon as it is available. Shared hosting users are largely dependent on their provider’s rollout schedule, so open a ticket if you get no confirmation by the end of the day.
For context on how quickly plugin and platform-level PHP flaws get targeted, see our coverage of the Bricksforge WordPress RCE flaw, the Backuply SQL injection affecting 600,000 sites, and the Rank Math SEO PRO supply-chain compromise. Each started with a disclosure and ended with active exploitation against slow updaters.
Timeline of events
- October 20, 2026, ~15:20 UTC: a Hacker News post claims two critical PHP RCE flaws, rated CVSS 10.0 and affecting versions back to PHP 5, are due for disclosure on October 22.
- October 20, 2026, evening: watchTowr confirms on X that the leaked information is real, says researchers were under embargo until Thursday 11:00 a.m. ET, and confirms it reproduced CVE-2026-109618.
- October 20, 2026, 19:33 UTC: the PHP security team publishes an advance notice on php.net announcing a security release for October 21 at 14:00 UTC for two critical flaws rated CVSS v4.0 9.2.
- October 21, 2026, 14:00 UTC: the emergency security release is scheduled to ship, with full technical details, affected versions, and fixed versions. The release may come earlier if details go public or exploitation is detected.
The bigger picture
This is a textbook case of an embargo breaking under its own weight. Coordinated disclosure relies on everyone holding information until a fixed date, and once a leak puts the existence of the flaws, their identifiers, and a claimed severity into circulation, vendors have little choice but to compress the timeline. PHP’s decision to pull the release forward by a day reflects that reality: the sooner legitimate fixes are out, the shorter the window in which only attackers hold the details.
It is also a reminder of how much of the internet runs on a small number of foundational components. PHP’s interpreter, its OpenSSL, curl, and XML libraries, these are shared infrastructure. When a flaw lands in one of them, the blast radius is measured in millions of servers, not thousands of app installs. The October 2026 patch cycle has already produced a string of high-severity fixes across that layer, including the Redis RESTORE flaw that was exploited within days of disclosure. The pattern is consistent: disclose, patch, and watch the race between administrators and exploit developers begin.
The safest assumption today is simple. Treat both flaws as remotely exploitable until the official release says otherwise, and be on the updated build before the end of the day.
Frequently asked questions
When does the PHP emergency security update release?
PHP scheduled the security release for Wednesday, October 21, 2026 at 14:00 UTC, which is 10:00 a.m. ET, 7:00 a.m. PT, 3:00 p.m. UK time, and 7:00 p.m. Pakistan time. It may arrive earlier if vulnerability details leak further or active exploitation is detected.
What are CVE-2026-109618 and CVE-2026-109619?
They are the two identifiers researchers are using for the pair of critical PHP flaws, which researchers have nicknamed PHP2Shell. Security firm watchTowr describes both as remote code execution vulnerabilities. PHP’s official notice has not confirmed these identifiers or the RCE classification; official technical details come with the release.
How severe are the PHP vulnerabilities?
PHP rated both flaws critical with a CVSS v4.0 score of 9.2 each. Some leaked reports claimed a maximum score of 10.0, but that figure comes from the leak, not from PHP. Either way, both sit at the top end of the severity scale.
Which PHP versions are affected?
The official affected-version list has not been published yet. Leaked reports claim the flaws affect versions from PHP 5 onward, but watchTowr itself says that scope is unconfirmed. Only the supported branches 8.2 through 8.5 will receive official fixes; older branches are end of life.
Do I need to update if I only run WordPress?
Yes, potentially. WordPress runs on PHP, and a flaw in the PHP interpreter affects the server underneath your WordPress install regardless of whether WordPress itself is updated. Ask your hosting provider when they will apply the PHP security update, and confirm the new version once it is rolled out.
Is there a workaround until the patch is available?
No confirmed workaround or mitigation specific to these flaws has been published. General server hardening is sensible, but the only real fix is the official update once PHP releases it.
Has anyone been hacked through these flaws yet?
As of the morning of October 21, 2026, no in-the-wild exploitation had been reported. watchTowr reproduced one of the flaws in a controlled lab. Given that technical details are now circulating, attackers will move quickly once patches drop, so patching promptly matters more than the current exploitation status.