PHP2Shell: Critical PHP RCE Flaws CVE-2026-109618 & CVE-2026-109619

Last updated: October 21, 2026, before the scheduled 14:00 UTC PHP security release

Two critical vulnerabilities in PHP core have triggered an unusually urgent warning for website owners, developers, hosting companies, and security teams worldwide.

The flaws, being referred to collectively as PHP2Shell, are tracked as CVE-2026-109618 and CVE-2026-109619. The PHP security team has rated both vulnerabilities CVSS v4.0 9.2, Critical, while some independent researchers have assessed the potential risk even more severely. PHP

The concern is straightforward: public reporting describes these as pre-authentication remote code execution vulnerabilities. In other words, a successful attacker may not need an account, password, WordPress administrator login, or any prior access to the application.

They may simply need to reach a vulnerable PHP server.

That makes this very different from the usual vulnerable WordPress plugin or outdated theme. This is a potential problem in PHP itself, below WordPress, Laravel, Magento, Drupal, Joomla, Symfony, MediaWiki, phpBB, WHMCS, WooCommerce, and countless custom PHP applications.

PHP’s reach makes the situation particularly serious. W3Techs currently estimates that PHP powers about 69.4% of websites where the server-side programming language can be identified. W3Techs

If you manage WordPress sites, custom applications, hosting infrastructure, or client websites, this is a good time to treat PHP maintenance as part of your broader technical SEO and website health process rather than something that only matters when a site breaks.

What Happened?

Information relating to the vulnerabilities leaked publicly on October 20, 2026, ahead of the planned coordinated disclosure.

Security company watchTowr said the reported vulnerabilities were real, while Huntress reported that watchTowr researchers had successfully reproduced at least CVE-2026-109618. Huntress had not observed exploitation across its own partner environments at the time of its initial report. Huntress

The PHP security team subsequently issued an unusual advance warning.

Its announcement stated that an emergency security release would arrive on:

Wednesday, October 21, 2026 at 14:00 UTC

That corresponds to approximately:

10:00 AM Eastern Time
3:00 PM British Summer Time
7:30 PM India Standard Time

PHP also warned that it reserved the right to publish the update earlier if technical details became public or if exploitation began in the wild. PHP

CERT-EU followed with Security Advisory 2026-018, recommending that organizations immediately identify affected PHP systems and prepare to patch. If immediate remediation is impossible, CERT-EU says organizations should consider isolating internet-facing PHP applications from public networks until they can be fixed. CERT-EU

This matters especially to people maintaining WordPress websites because updating WordPress core, plugins, or themes does not update the PHP interpreter running underneath them.

Security Researchers Expect Exploitation to Move Fast

Sansec, Huntress, watchTowr, Webfence and other security organizations have issued warnings around PHP2Shell.

Sansec has been particularly blunt about the expected exploitation window, predicting that mass attacks could begin within roughly 15 minutes of the public patch becoming available.

Why so quickly?

Because once PHP publishes the patched source code, attackers can compare the fixed code with the vulnerable version, identify what changed, and reverse-engineer the vulnerability. Sansec

This is a familiar race in vulnerability management.

Defenders receive the patch.

Attackers receive the patch too.

The patch itself can effectively become a map showing skilled attackers where the bug was.

That is why businesses running large sites should already know who controls the server layer. A traditional SEO consulting engagement might focus on indexing and traffic, but incidents like PHP2Shell show why ownership of hosting, deployment, backups and infrastructure can be equally important.

The Leaked “PHP2Shell” Tool

Leaked material reportedly included screenshots and videos of an exploitation tool called PHP2Shell, with some reports attributing it to Calif.IO.

The demonstrations reportedly showed code execution against PHP applications including WordPress, Magento, Joomla, Laravel, Drupal, MediaWiki, phpBB, Symfony and WHMCS. Ars Technica

That does not mean those frameworks contain the vulnerability.

The common denominator is PHP.

A perfectly updated WordPress installation could therefore still be exposed if the server is running a vulnerable PHP release.

No proof-of-concept exploitation instructions are included here.

What Researchers Currently Believe Is Vulnerable

This section needs an important distinction.

PHP has not yet officially confirmed the complete technical root cause, affected-version range, prerequisites or final patched versions at the time this article is being written.

However, independent research and leaked material currently point toward PHP’s core session.upload_progress functionality.

The feature is enabled by default and has existed since the PHP 5.4 generation. PHP’s own documentation confirms that session.upload_progress.enabled defaults to enabled. PHP

Public research currently describes several possible attack primitives associated with the flaws:

Session fixation through multipart POST data that may bypass normal session.use_only_cookies expectations.
Client-controlled filename data reaching PHP session files without sufficient validation.
A reported use-after-free condition involving destruction and __destruct re-entrancy that could eventually result in memory corruption and arbitrary execution.
Cross-request session-handler or serialization-handler mismatches under PHP-FPM environments.
Manipulation of PHP’s session upload-progress state across requests.

Independent research currently places the potentially affected range at approximately PHP 5.4.0 through PHP 8.5.x, while several early reports describe the scope more broadly as PHP 5 onward. GitHub

Until PHP publishes the formal advisory, treat the precise technical explanation as researcher analysis, not final vendor confirmation.

For administrators managing many URLs or applications, maintaining an accurate inventory is as important here as maintaining a clean XML sitemap inventory for search. You cannot patch infrastructure you have forgotten exists.

Which PHP Versions Will Receive Fixes?

PHP currently lists only 8.2, 8.3, 8.4 and 8.5 as supported production branches. PHP 8.1, PHP 8.0, PHP 7.x and PHP 5.x are already end-of-life. PHP

That creates a major problem.

If PHP2Shell affects those older releases, sites still running them should not expect an official upstream PHP security patch.

They need to upgrade PHP, isolate the application, or remove it from public access.

Pre-release/staging material currently points toward the following likely security releases:

PHP 8.2.35
PHP 8.3.36
PHP 8.4.27
PHP 8.5.12

PHP distribution staging has already contained announcement drafts for those versions, but administrators should still wait for php.net to identify the officially fixed releases before treating those version numbers as final confirmation. PHP Foundation Discourse

If you’re maintaining older custom WordPress builds and functionality, PHP compatibility testing should become part of the upgrade process now rather than an excuse to stay permanently on an unsupported runtime.

Is There a Temporary PHP2Shell Workaround?

There is currently no configuration-only mitigation that should be treated as equivalent to patching.

Some researchers have recommended temporarily disabling:

session.upload_progress.enabled = Off

Because current research associates PHP2Shell with session upload progress, this could reduce exposure to some suspected attack paths.

But it should not be treated as guaranteed protection.

The full attack surface has not yet been formally documented by PHP, and multiple researchers have warned that disabling the feature may not eliminate every exploitation path.

Similarly, blocking multipart/form-data requests at Cloudflare, Nginx, Apache, a reverse proxy or another WAF may reduce exposure to suspected vectors.

The problem is that multipart requests are also used by legitimate functionality such as:

file uploads
media libraries
contact forms with attachments
ecommerce uploads
document portals
some administrative functionality

Blocking them globally could break production applications.

Use temporary WAF rules as a risk-reduction layer, not as permission to avoid patching.

Early Attack Activity Has Already Been Reported

The situation became more urgent on the morning of October 21.

Reuters reported that Cloudflare CTO Dane Knecht said the company was seeing early attacks emerge and was adjusting mitigations as new vectors appeared. Cloudflare was reportedly deploying temporary firewall protections while the PHP fix was still pending. Reuters

Other security organizations had not independently confirmed widespread exploitation at the same point in time.

That distinction matters.

We are not yet necessarily looking at universal mass exploitation, but defenders should no longer assume this is merely theoretical.

Once the official patches are released, automated internet-wide scanning becomes considerably easier.

PHP2Shell Emergency Action Checklist

If you operate a PHP website, do these steps now.

1. Inventory every PHP server

Do not check only your main website.

Look for:

WordPress installations
Magento stores
Laravel applications
Drupal or Joomla sites
staging environments
abandoned subdomains
internal dashboards
WHMCS installations
custom PHP applications
old VPS instances
development servers accidentally exposed to the internet

On servers you manage directly, check the runtime with:

php -v

You can also verify versions using your hosting panel or controlled phpinfo() output.

If you’re auditing a larger website estate, tools such as a URL cleaner, crawl budget estimator and the broader free SEO tools library can help organize the web-facing side of the inventory, but PHP itself must be checked at the server or hosting level.

2. Identify who actually controls PHP updates

For each site, determine whether PHP is managed by:

you
your system administrator
your developer
your hosting provider
a managed WordPress provider
a cloud platform
a client IT team

Do not assume someone else is doing it.

3. Take complete backups

Back up both:

website files
databases

Verify that the backup is usable and stored separately from the server being patched.

4. Prepare for the 14:00 UTC release

Schedule a maintenance window at or before 14:00 UTC on October 21.

PHP has explicitly said the release could arrive earlier.

Monitor php.net continuously until the fixed releases are confirmed.

5. Install the patched PHP version immediately

Once PHP publishes the official fixed versions, update without unnecessary delay.

Then test:

homepage
admin panel
forms
checkout
file uploads
APIs
cron jobs
plugins/modules
custom PHP functionality

For WordPress-heavy environments, this is where good website development practices and staging become extremely valuable.

6. If you cannot patch, restrict or disconnect

For vulnerable systems that cannot immediately be upgraded:

place administration behind a VPN
apply strict IP allow-listing
remove unnecessary public routes
isolate the server from public networks

If adequate isolation is impossible, take the application offline temporarily.

That is not overreaction. It is directly consistent with CERT-EU’s recommendation. CERT-EU

7. Check managed hosting

If you use services such as managed WordPress hosting, contact the provider and confirm:

whether your PHP release is affected
whether the provider controls PHP patching
when the emergency release will be deployed
whether temporary WAF protection is active

Do not assume a green WordPress update screen means PHP is safe.

8. Monitor after patching

Review:

web server access logs
PHP error logs
authentication logs
recently modified PHP files
new administrative accounts
unusual scheduled tasks
unexpected outbound connections
WAF alerts

Consider additional WAF monitoring during the hours following disclosure.

If you’re already performing a broader website review, a free website and SEO audit can identify the search-facing issues afterward, but suspected compromise requires a proper security investigation, not an SEO scan.

This Is Not a WordPress Plugin Vulnerability

This is perhaps the most important takeaway.

PHP2Shell is being reported as a PHP core vulnerability.

Installing a WordPress plugin update does not fix PHP.

Updating Elementor does not fix PHP.

Updating Laravel does not fix PHP.

Updating Magento does not fix PHP.

The runtime underneath the application must be patched.

That makes PHP2Shell relevant not just to WordPress administrators but to developers building custom tools and web applications, teams running business automation systems, and organizations maintaining large content and search-focused websites.

The Race Starts When the Patch Drops

Critical vulnerabilities often create an uncomfortable paradox.

Publishing the patch protects defenders, but it also gives attackers new information.

PHP2Shell is especially concerning because PHP is everywhere, the vulnerabilities reportedly require no authentication, and internet-wide scanning for outdated PHP installations can be automated.

Systems running supported PHP versions should patch immediately.

Systems running unsupported PHP versions should be upgraded.

Systems that cannot be upgraded or isolated should seriously be considered for temporary shutdown.

The PHP team has given administrators advance warning. The useful window is measured in hours, not weeks.

Share this warning with anyone responsible for a PHP server, especially teams managing WordPress, Magento, Laravel, Drupal, Joomla or older custom applications.

And check your servers now, not after the first compromise report arrives.

For ongoing technical website work and future incident write-ups, you can also follow the SEO & AI Notes archive and practical website case studies.

Primary Sources

The situation is developing quickly. Use primary or first-party reporting wherever possible:

Stay Updated

Monitor php.net for the final security releases, affected-version information and official mitigation guidance. The PHP Foundation’s @ThePHPF account on X is also worth following while the disclosure develops.

Do not rely solely on social-media screenshots, leaked exploit demonstrations or unofficial mitigation advice. Once the official PHP releases become available, patching the runtime should be the priority.