Security researchers have demonstrated how 2 critical vulnerabilities in PHP can allow unauthenticated attackers to execute malicious code against websites running WordPress, Drupal, Joomla and other PHP-based applications, prompting emergency security updates and warnings from hosting providers.
The vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619 and collectively known as PHP2Shell, each carry a CVSS v4.0 severity score of 9.2.
Unlike vulnerabilities affecting individual plugins or content management systems, PHP2Shell targets the underlying PHP interpreter. This means websites running fully updated applications may still be exposed if their hosting infrastructure uses a vulnerable PHP runtime.
On October 21, 2026, PHP maintainers released emergency security updates addressing both vulnerabilities and warned that temporary configuration changes cannot provide complete protection.
The fixed versions are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
Researchers have also published technical analyses and proof-of-concept demonstrations showing how the vulnerabilities can be exploited. Reports of malicious activity targeting affected systems have increased the urgency of patching.
Wiz Research demonstrates remote code execution against WordPress
According to technical research published by Wiz Research, the vulnerabilities originate from memory-safety problems within PHP’s core execution environment.
Wiz researchers demonstrated unauthenticated remote code execution against WordPress, Drupal and Joomla in controlled testing environments.
The demonstrations are significant because the affected applications did not require a separate plugin vulnerability to become exploitable.
Instead, researchers targeted weaknesses in the PHP runtime responsible for processing requests and managing internal memory.
Wiz reported identifying the first vulnerability on August 19, 2026, using AI-assisted security research. The team subsequently demonstrated exploitation against WordPress and disclosed its findings to PHP maintainers in August.
The research involved collaboration with Calif, OpenAI and other security researchers during the coordinated disclosure process.
Wiz’s analysis describes multiple underlying memory-safety issues grouped under the 2 CVEs, including conditions involving freed memory and inconsistent internal state.
Successful exploitation could allow attackers to execute code with the privileges of the PHP process, potentially exposing application configuration files, database credentials, API keys and other sensitive information.
Researchers also demonstrated memory-disclosure techniques capable of exposing information retained within the PHP process.
These findings establish that the vulnerabilities are exploitable under demonstrated conditions. They do not establish that every PHP-powered website can be compromised or that widespread successful exploitation has occurred.
Two vulnerabilities, different memory-safety failures
The official PHP security advisory published October 21 identifies 2 distinct classes of vulnerability.
CVE-2026-109618: Remote code execution through out-of-memory corruption
The first vulnerability involves PHP’s handling of memory allocation failures.
According to PHP maintainers, an out-of-memory condition can interrupt request processing while internal data structures are only partially initialized.
During subsequent cleanup, PHP may incorrectly interpret invalid or incomplete internal data as legitimate information.
Under exploitable conditions, this memory corruption can lead to unauthorized code execution.
CVE-2026-109619: Remote code execution through stale global state
The second vulnerability involves internal state that can remain accessible after its associated memory has been released.
When a PHP worker processes another request, it may access that stale state before normal initialization replaces it.
This creates a use-after-free condition that researchers have demonstrated can be exploited for remote code execution.
The second flaw is particularly relevant to environments where PHP workers handle multiple requests over their lifetime.
Although the vulnerabilities have different technical causes, both can expose internet-facing PHP applications to serious security risks.
Apache mod_php installations face particularly high risk
The PHP security team warned that all PHP installations serving web requests should be evaluated for exposure.
Affected deployment environments include:
- Apache servers using
mod_php. - PHP-FPM deployments.
- PHP-CGI configurations.
- LiteSpeed web servers running PHP.
- FrankenPHP environments.
PHP maintainers consider Apache installations using mod_php particularly exposed.
Researchers demonstrated an attack in which an unauthenticated HTTP request could trigger exploitation before the target application’s own code begins executing.
This matters because application-level protections may not prevent exploitation if the vulnerable behavior occurs earlier in PHP’s request-processing lifecycle.
Other PHP deployment models are also affected, although the precise exploitation requirements and available attack paths can differ.
Organizations should therefore avoid assuming that a particular web server or PHP integration method automatically protects them.
Public exploit demonstrations increase urgency
The release of technical research has been accompanied by public proof-of-concept demonstrations and repositories claiming to reproduce the vulnerabilities.
Researchers have demonstrated attacks against popular PHP applications, including WordPress, Drupal and Joomla.
A publicly circulated exploit demonstration also credited security researcher LCFR and Calif.io for their contribution to the demonstration.
That credit is distinct from attribution for the original discovery of the vulnerabilities, which involved a broader coordinated research effort.
Technical findings and application-specific demonstrations are available through the PHP2Shell research project.
The availability of proof-of-concept material lowers the barrier for additional researchers and attackers to investigate the flaws.
However, not every publicly shared exploit has been independently validated, and the existence of working demonstrations does not prove that attackers have compromised large numbers of production websites.
Security researchers and hosting providers have reported suspicious activity consistent with attempts to exploit the vulnerabilities.
Patchstack reported receiving information from hosting partners about potential exploitation activity on October 21.
Cloudflare also disclosed that it developed and deployed web application firewall protections in coordination with researchers and PHP maintainers.
Those protections may help block known attack patterns, but they do not replace the security fixes released by the PHP project.
WordPress sites remain exposed until PHP is patched
WordPress administrators face an important distinction: updating WordPress core, themes and plugins does not necessarily update PHP itself.
PHP is installed and maintained separately by the hosting provider or server administrator.
A WordPress website running the latest version of WordPress could therefore remain vulnerable if its underlying PHP installation has not received the October 21 security fixes.
The same concern applies to Drupal, Joomla, Laravel, Magento and custom PHP applications.
WordPress administrators can identify their PHP version through the dashboard:
Tools → Site Health → Info → Server → PHP version
However, the displayed version does not always reveal whether a hosting provider has applied a backported security fix.
Some operating system vendors and managed hosting providers maintain patched PHP packages without changing the upstream version number in the same way as an official PHP release.
Customers should therefore confirm patch status directly with their hosting provider.
For shared and managed WordPress hosting, customers may not have permission to install PHP updates themselves.
In those environments, the hosting provider is responsible for deploying the relevant security packages.
Organizations using self-managed servers, containers or custom hosting infrastructure must ensure that the PHP runtime used by their web applications has been updated.
Millions of PHP servers create a difficult patching challenge
PHP2Shell has attracted widespread attention because PHP remains deeply embedded in internet-facing infrastructure.
According to internet-scanning research published by VirusTotal, approximately 5.1 million IP addresses were associated with PHP during its analysis.
Approximately 3.8 million of those addresses had at least 1 open port, while only around 1.1 million disclosed identifiable PHP version information.
Among systems exposing version details, VirusTotal identified substantial numbers running unsupported PHP branches.
The findings included approximately 758,000 IP addresses associated with PHP versions from 5.4 through 8.1, all outside routine upstream security support.
VirusTotal also identified approximately 538,000 IP addresses associated with WordPress, 141,000 with Laravel and 107,000 with Nextcloud within its PHP-related results.
These figures describe observed technology deployments, not a confirmed count of vulnerable websites.
Many PHP installations do not disclose version information, and the presence of PHP alone does not establish whether a specific exploit path is reachable.
Nevertheless, the data illustrates the scale of the remediation challenge facing hosting companies, website administrators and organizations maintaining legacy applications.
Unsupported PHP branches require special attention
PHP maintainers released fixes for the actively maintained 8.2, 8.3, 8.4 and 8.5 branches.
PHP 8.1 and older versions no longer receive routine upstream security releases.
However, the PHP security team also provided minimal source-level backports for PHP 7.4, 8.0 and 8.1 to assist organizations that cannot immediately migrate.
These backports are not a replacement for moving to a supported PHP branch.
Linux distributions and long-term support vendors may also provide patched packages for older versions.
Administrators should consult their operating system vendor, hosting provider or control panel supplier to determine which security updates are available.
Organizations running unsupported PHP releases without a vendor-maintained patch path should prioritize migration.
Temporary configuration changes cannot fully prevent exploitation
Before the emergency releases, researchers discussed configuration changes that might reduce exposure to specific attack paths.
One widely circulated recommendation involved disabling PHP’s session upload-progress functionality:
session.upload_progress.enabled=0
The official PHP advisory confirms that this setting can block certain demonstrated paths associated with CVE-2026-109619, but it does not eliminate all possible exploitation routes.
PHP maintainers also documented temporary measures involving memory limits, request-size restrictions and other runtime settings.
These measures may reduce exposure to particular conditions, but none provides complete protection against both vulnerabilities.
Some changes can also affect application behavior or availability.
For that reason, administrators should not treat configuration adjustments or web application firewall rules as permanent remediation.
Installing the official security fixes or vendor-maintained patched packages remains the recommended response.
What website administrators should do now
Organizations operating PHP-based websites should immediately determine whether their production environments have received the October 21 security updates.
The following actions should take priority:
- Verify the PHP runtime: Identify the PHP version used by each public-facing website, application and container.
- Install security updates: Upgrade to
8.2.35,8.3.36,8.4.27or8.5.12, or install a vendor-confirmed backported fix. - Contact hosting providers: Confirm whether managed hosting environments have received the emergency patches.
- Investigate suspicious requests: Review web server and security logs for unusual request activity, crashes and unexpected PHP worker behavior.
- Check application integrity: Investigate unfamiliar scripts, modified application files and unexpected administrative activity.
- Review exposed credentials: If compromise is suspected, assess whether database passwords, API keys or other application secrets may have been accessed.
- Limit unnecessary exposure: Restrict public access to development systems, administrative interfaces and services that do not require internet connectivity.
- Preserve evidence: Retain relevant logs and system information before rebuilding potentially compromised environments.
Administrators should also verify that all PHP workers have restarted after the patched runtime is installed.
In environments using multiple PHP versions, updating a single runtime may leave other applications exposed.
Organizations should confirm the actual PHP version serving each application rather than relying solely on the command-line installation.
PHP2Shell highlights a security risk beneath popular applications
The PHP2Shell vulnerabilities demonstrate how weaknesses in a shared programming language runtime can affect applications that would otherwise be considered fully updated.
The attack surface is not limited to WordPress, and patching individual applications does not address vulnerabilities in the interpreter executing their code.
BreachNews previously examined critical WP2Shell vulnerabilities affecting WordPress websites and Click2Shell, a separate WordPress vulnerability involving PHP code execution.
Those vulnerabilities are unrelated to PHP2Shell, which affects PHP’s underlying runtime rather than a specific WordPress component.
The latest findings also demonstrate the growing role of AI-assisted vulnerability research in identifying complex memory-safety problems within widely deployed software.
Wiz Research’s disclosure provides a detailed example of how researchers combined automated analysis with manual investigation to identify and validate serious vulnerabilities.
With technical findings and exploit demonstrations now public, organizations should prioritize patch verification and investigation of suspicious activity rather than relying on temporary filtering measures.
The PHP development team has made the emergency security releases available through its official download page.
The number of production websites successfully compromised through PHP2Shell remains uncertain, but the demonstrated ability to execute code without authentication makes unpatched internet-facing PHP installations a significant security concern.
