PHP to Ship Out-of-Cycle Security Release for Critical Remote Code Execution Vulnerabilities

The PHP development team has announced plans to issue an out-of-cycle security release to address two critical vulnerabilities that have been assigned a severity rating of 9.2 out of 10 on the CVSS v4.0 scale. While security researchers have warned that the flaws could enable remote code execution, official details regarding the exact nature of the vulnerabilities, the affected components, and the specific mechanics of the bugs have been withheld by the vendor pending the official software update.

The emergency release schedule was accelerated following an unexpected information leak. On October 20, a post appeared on Hacker News claiming that two high-severity remote code execution flaws affecting PHP versions dating all the way back to PHP 5 would be publicly disclosed later in the week. The anonymous poster assigned a maximum CVSS score of 10.0 to the vulnerabilities and stated that disclosure was expected on Thursday, October 22, though they openly admitted they had no concrete evidence beyond asserting their insider knowledge.

Shortly after the Hacker News post circulated, cybersecurity firm watchTowr published a statement on social media confirming that the leaked information was genuine. The firm noted that the vulnerabilities were actively under a coordinated embargo and that researchers and industry stakeholders had intended to maintain confidentiality until the scheduled Thursday disclosure date. Following the breach of confidentiality, the PHP team issued an advance notice at 19:33 UTC on October 20, moving the emergency patch deployment forward to Wednesday, October 21. In its official notice, the PHP project stated that updates could be published earlier than planned if details of either vulnerability became public or if evidence of active exploitation began to appear in the wild.

The initial leak primarily revealed the existence of the vulnerabilities, a preliminary timeline, and two specific CVE identifiers: CVE-2026-109618 and CVE-2026-109619. Although the official PHP security advisory does not explicitly name these identifiers, security researchers have adopted them alongside the moniker "php2shell" to track the developing situation. Furthermore, the claim that every PHP version since PHP 5 is vulnerable remains unconfirmed by official sources. In an FAQ document published regarding the incidents, watchTowr emphasized that the broader scope of affected versions has not been verified by an official vendor advisory, nor have specific configuration requirements or necessary feature flags been detailed.

As the industry awaits the official software patches, security analysts have underscored the rigid support lifecycle maintained by the PHP project. PHP officially provides bug fixes and security updates exclusively for its four currently supported branches. Under this policy, only versions 8.2, 8.3, 8.4, and 8.5 are eligible to receive official vendor patches for these critical vulnerabilities. The active support branches currently include PHP 8.4 and PHP 8.5, which receive regular maintenance and bug fixes, while PHP 8.2 and PHP 8.3 have transitioned into security-fix-only phases.

Older software branches, including PHP 8.1, PHP 8.0, all iterations of PHP 7, and legacy versions of PHP 5, have reached their end-of-life milestones and no longer receive support or security updates from the official PHP development team. Consequently, if the vulnerabilities do indeed extend to these legacy versions as speculated in early reports, millions of deployments running older software will not receive an official vendor-supplied patch, leaving administrators reliant on internal mitigations, Web Application Firewalls, or upgrading their environments entirely.

The scale of legacy software currently exposed on the public internet remains a significant concern for enterprise security teams. Data compiled from internet-facing telemetry tools illustrates the potential magnitude of the exposure. According to analysis conducted by security firm Mallory, approximately 884,000 internet-facing hosts reported running PHP version 8.1 or older when queried via Shodan just prior to the emergency announcement. This figure represented roughly 59 percent of the approximately 1.5 million hosts that volunteered a specific PHP version in their HTTP response headers, while an additional 740,000 hosts exposed PHP services without broadcasting a version number at all. Security experts emphasize that these figures reflect HTTP banners rather than confirmed vulnerabilities, but they nonetheless highlight the vast footprint of aging PHP installations across the global web infrastructure.

In the absence of an immediate patch or a formal vendor workaround prior to the release window, organizations have been scrambling to prepare their networks. Rapid-response guidance issued by cybersecurity firms such as Huntress and organizational advisories from bodies like CERT-EU have focused on asset discovery, network segmentation, and hardening perimeter defenses. Security researchers have stressed the importance of identifying all internal and external PHP dependencies, auditing server configurations, and monitoring for anomalous traffic patterns once technical details of the vulnerabilities are finally made public.

Despite the high severity scores and the abrupt nature of the leak, industry observers have noted a temporary absence of active exploitation. Huntress reported that it had not observed any exploitation attempts across its partner environments, nor had researchers successfully constructed or reproduced a working proof-of-concept exploit at the time of the initial advisories. Similarly, watchTowr confirmed in its technical documentation that no exploitation had been documented in the wild and that the identifiers had not yet been added to the Cybersecurity and Infrastructure Security Agency Known Exploited Vulnerabilities catalog.

This relatively calm pre-patch period stands in contrast to previous high-profile PHP incidents. For instance, when CVE-2024-4577—a critical vulnerability affecting PHP running in CGI mode on Windows systems—was publicly disclosed in June 2024, threat actors began launching automated exploit attempts against honeypot infrastructure within 24 hours of public disclosure. Security teams are acutely aware that the release of the official PHP security update will likely be followed closely by the reverse-engineering of the patches, making rapid deployment critical for vulnerable organizations once the code becomes available.

The forthcoming software release is expected to resolve the remaining ambiguities surrounding the vulnerabilities. The official documentation will ultimately clarify which branches are genuinely affected, which internal subsystems of the PHP engine are involved, and whether successful exploitation requires specific runtime configurations, specialized inputs, or authenticated access. Until those details are officially published by the PHP development team, administrators continue to monitor communication channels and prepare their infrastructure for immediate patching upon the availability of the fixes.