Two vulnerabilities rated CVSS 4.0 at 9.2 could expose PHP-powered websites and servers to remote code execution. Patchstack reports active exploitation, while administrators await an emergency security release scheduled for 14:00 UTC today.
The PHP ecosystem is facing an urgent security incident following the disclosure of two critical vulnerabilities in the PHP interpreter that reportedly allow remote code execution (RCE). Tracked as CVE-2026-109618 and CVE-2026-109619, the flaws have prompted an emergency security release from the PHP development team, scheduled for Wednesday, October 21, at 14:00 UTC.
The situation has escalated beyond a routine vulnerability disclosure. In an October 21 advisory, security company Patchstack reported receiving multiple reports of active exploitation from hosting partners, with the first incidents in its published timeline recorded at 07:34 UTC. The reports raise the urgency for organizations running PHP-based websites, applications, and backend services.
The PHP security team confirmed the upcoming release in an official announcement published on October 20, assigning both vulnerabilities a severity rating of 9.2 under CVSS v4.0. The team urged users to prepare to upgrade immediately when patched versions become available and reserved the option to release earlier if technical details became public or evidence of exploitation emerged.
Sources: PHP security announcement, Patchstack security alert, Mallory’s technical analysis.
Two critical flaws in PHP itself
Unlike vulnerabilities limited to a specific content management system or plugin, these issues reportedly affect PHP at the interpreter level. Consequently, the potential exposure extends across a broad range of applications, including WordPress, Drupal, Magento, Joomla, Laravel, and custom PHP deployments, provided they run an affected version.
Remote code execution vulnerabilities can allow an attacker to execute commands or code on a vulnerable server. Depending on the deployment’s permissions, isolation, and security controls, a successful attack could lead to website compromise, unauthorized access to application data, installation of persistent backdoors, or further movement into connected infrastructure.
Patchstack identifies the two vulnerabilities as CVE-2026-109618 and CVE-2026-109619 and reports that technical details leaked ahead of the planned coordinated disclosure. Security researchers at watchTowr reportedly reproduced one of the vulnerabilities, lending further weight to concerns about exploitability.
The incident has also been referred to as “PHP2Shell” in early reporting. The official PHP announcement, however, had not yet published the full technical details or definitive affected-version information at the time of writing.
Active exploitation changes the response timeline
The most significant development is the divergence between the initial pre-release assessment and the latest threat intelligence.
In its October 20 analysis, Mallory reported that it had not observed public exploit availability or confirmed in-the-wild exploitation at the time of publication. The company nevertheless warned that exploitation could emerge quickly once technical details became available.
Patchstack’s October 21 update subsequently reported multiple exploitation incidents communicated by hosting partners. This later reporting suggests that defenders should no longer treat the issue solely as a forthcoming patching exercise.
The reports have not, by themselves, established the full scope of exploitation, the number of compromised systems, or whether every incident involved both vulnerabilities. Organizations should therefore treat the situation as a high-priority incident while avoiding assumptions about the scale or technical details of attacks that have not been independently confirmed.
The practical implication is clear: administrators should prepare for emergency patching now rather than waiting for evidence that their own systems are being targeted.
Hundreds of thousands of internet-facing hosts may remain unpatchable
Mallory’s analysis of internet-facing systems identified a substantial challenge beyond the immediate release: a large population of PHP installations runs end-of-life branches that may not receive upstream fixes.
According to Mallory’s October 20 Shodan-based assessment, approximately 1.5 million internet-facing hosts reporting a PHP version were identified. Of these, 883,717 hosts—roughly 59%—were running PHP 8.1 or earlier, branches that Mallory classified as no longer receiving fixes for this release.
The analysis estimated that around 612,000 hosts were running PHP 8.2 through 8.5, the branches expected to receive patched releases. Mallory also cautioned that the true number of affected websites could be substantially higher: version banners do not identify every PHP host, and a single shared-hosting IP address can serve numerous websites.
These figures are exposure estimates, not confirmed counts of vulnerable or compromised systems. Some operating-system distributors may backport security fixes, and externally visible version information does not necessarily establish whether a particular installation is vulnerable.
Nevertheless, the figures highlight a difficult operational problem. Updating a supported PHP branch may be straightforward, but older deployments can require application compatibility testing, infrastructure changes, vendor intervention, or migration to a supported environment.
Emergency release scheduled for 14:00 UTC
The PHP security team has scheduled the security release for October 21, 2026, at 14:00 UTC. At the time of publication, that release is still forthcoming.
Mallory’s pre-release analysis identifies the following anticipated fixed versions:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
These version numbers are based on Mallory’s reporting ahead of the release. Administrators should verify the final release announcement and vendor advisories before treating any version as definitively fixed.
PHP 8.1 and earlier are identified by Mallory as end-of-life branches without a corresponding upstream fix planned for this release. Organizations operating these versions should urgently establish an upgrade or containment plan.
The PHP team’s official announcement states that full vulnerability details, affected versions, and fixed versions will be published with the release. It also reserves the right to publish earlier if disclosure or active exploitation warrants it.
What administrators should do now
Organizations that operate PHP-powered services should prioritize the following measures.
1. Inventory all PHP deployments. Identify versions running on production servers, containers, staging environments, development systems, and managed hosting platforms. Check PHP-FPM, Apache’s mod_php, CGI-based deployments, and any additional runtime instances that may be overlooked.
2. Prepare to install the official security update immediately. Confirm how PHP is deployed and upgraded in each environment. Coordinate with hosting providers, application owners, and infrastructure teams so that the relevant systems can be patched as soon as verified updates become available.
3. Escalate end-of-life installations. If a deployment runs PHP 8.1 or earlier, contact the hosting provider or platform vendor about supported upgrades and security coverage. Where an upgrade cannot be completed promptly, consider restricting access to trusted networks, applying temporary access controls, or taking exposed systems offline when operationally feasible.
4. Review signs of compromise. Given Patchstack’s exploitation reports, monitor web-server and PHP logs, unexpected child processes, new or modified files in web roots, suspicious outbound connections, and unexplained changes to scheduled tasks or application accounts. Preserve relevant logs and investigate suspicious activity instead of assuming a successful update alone resolves a possible compromise.
5. Avoid relying on unverified workarounds. Patchstack discusses disabling PHP’s session upload-progress feature as a possible temporary mitigation:
session.upload_progress.enabled = Off
This setting may reduce exposure to a particular suspected attack path, but it is not a confirmed complete fix. It should be considered only as a temporary measure following technical review, and it must not replace the official security update.
6. Verify vendor and distribution advisories. Organizations using packaged PHP installations should confirm whether their Linux distribution or hosting provider supplies a backported security fix. Compare the vendor’s advisory and package status rather than relying exclusively on the upstream version string.
Why this incident matters
The incident demonstrates the security risk posed by vulnerabilities in widely deployed application runtimes. A flaw in PHP itself can cross application boundaries, placing websites and services with very different business purposes into the same potential exposure window.
It also underscores the importance of lifecycle management. End-of-life software can remain operational for years because of legacy dependencies, hosting limitations, or the cost of migration. When a critical vulnerability emerges, those systems can become especially difficult to defend because an upstream patch may not exist for their branch.
The combination of a public disclosure, reports of exploitation, and a large population of potentially unpatched hosts creates a narrow window for defenders to act. Asset discovery, reliable patch deployment, and incident monitoring are therefore as important as the vulnerability’s severity score.
What happens next?
The next major milestone is the PHP security release scheduled for 14:00 UTC on October 21. Its publication should establish the official affected-version ranges, confirmed fixes, and technical details needed to guide remediation.
Until those details are available, organizations should treat the two reported RCE vulnerabilities as a critical operational priority, validate their exposure, and prepare their upgrade procedures. Those running unsupported PHP versions should not assume that waiting for the scheduled release will make their systems safe.
With exploitation already reported by Patchstack, the central question for defenders is no longer simply when a patch will arrive. It is whether every exposed PHP installation can be identified, secured, and verified before attackers gain a foothold.
