Two critical vulnerabilities in PHP have prompted emergency security updates, early exploitation attempts, and precautionary shutdowns of major online services across Europe. For organisations relying on PHP, the priority is clear: identify affected systems and update them without delay.
On 21 October 2026, PHP released emergency fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Collectively known as PHP2Shell, both flaws carry a CVSS score of 9.2 and could allow unauthenticated attackers to execute code on vulnerable servers.
The vulnerabilities affect PHP itself, rather than a particular website, plugin, or framework. That makes the issue especially significant for organisations using PHP-based platforms such as WordPress, Drupal, Joomla, Magento, and Laravel.
What Makes PHP2Shell So Dangerous?
PHP2Shell involves two flaws in how PHP handles incoming requests.
One vulnerability can cause PHP to exhaust memory while processing a request, leaving cleanup operations working with incomplete data. The other allows stale data from one request to influence another.
Under vulnerable conditions, a specially crafted request could enable remote code execution. The flaws may also expose sensitive information, including passwords, authentication tokens, and cryptographic keys.
Because the weaknesses exist within PHP's request handling, they can be triggered before an application's own code executes.
The recommended fixed versions are PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 and PHP 8.2.35.
Organisations running older, unsupported versions need to assess upgrade options or obtain appropriate vendor-maintained security fixes.
Attack Attempts Began Before Public Disclosure
The PHP2Shell timeline highlights how little time defenders may have to respond to emerging vulnerabilities.
Researchers from Calif and Wiz reported the flaws in August, with coordinated disclosure originally planned for 22 October. However, vulnerability details leaked on 20 October, prompting an accelerated response.
More concerningly, Amazon's MadPot honeypots recorded an apparent exploitation attempt on 17 October, several days before the public disclosure.
Additional attempts followed on 21 October, with Amazon observing activity from multiple apparent threat actors. Exploit attempts also appeared rapidly after the emergency patches became available.
Although the early attempts were not confirmed to have successfully compromised real systems, they demonstrate that malicious activity can precede both public advisories and available fixes.
For security teams, the lesson is important: the date a vulnerability becomes public is not necessarily the date attacks begin.
European Services Taken Offline as a Precaution
PHP2Shell quickly became more than a technical security advisory.
In Denmark, the school communication platform Aula was taken offline as a precaution. Services associated with the Danish Meteorological Institute (DMI) and Copenhagen Municipality were also affected by precautionary shutdowns.
In the Netherlands, government services including DigiD and MijnOverheid were temporarily unavailable.
These measures reflected the seriousness of the potential exposure, not confirmed successful compromises.
With approximately 2.24 million internet-facing servers advertising PHP, identifying vulnerable installations is a substantial challenge. According to the reported figures, 59% of servers that disclose a PHP version were running PHP 8.1 or older.
What Should Organisations Do Now?
The immediate priority is to establish where PHP is running and whether those installations are vulnerable.
Security and IT teams should identify PHP across websites, internal applications, development environments, and vendor-managed services. Affected installations should be updated to fixed releases or patched distribution packages.
Organisations should also review relevant web server and PHP logs dating back to at least 17 October, investigate suspicious activity, and request confirmation of remediation from hosting providers and software vendors.
Web application firewall rules can provide additional protection against known attack patterns, but they do not remove the underlying vulnerabilities.
How SecTeer Helps Organisations Improve Visibility
PHP2Shell reinforces a fundamental cybersecurity challenge: organisations cannot remediate vulnerable software they do not know they have.
In response to the severity of PHP2Shell and the reported exploitation attempts, SecTeer has introduced dedicated PHP detection through VulnDetect.
This helps organisations identify PHP installations within their monitored environments, improve software visibility, and determine which systems require further investigation.
That visibility matters because finding PHP does not automatically mean a system is remotely exploitable. Actual exposure depends on how the software is deployed and whether it processes untrusted requests.
By combining software inventory with vulnerability intelligence, VulnDetect supports more informed remediation decisions. SecTeer's broader approach to vulnerability detection and patch management helps IT teams maintain visibility and act on security risks.
The Bigger Lesson From PHP2Shell
PHP2Shell demonstrates how quickly a critical software vulnerability can develop into a widespread operational concern.
The combination of severe vulnerabilities, pre-disclosure attack attempts, and precautionary service shutdowns illustrates why organisations need both rapid security updates and reliable visibility into their software environments.
Do you know where vulnerable software is running in your organisation?
Learn more about SecTeer and discover how VulnDetect can help you identify software risks and strengthen your vulnerability management process.