Two critical vulnerabilities in the PHP core, collectively known as PHP2Shell, enable remote code execution without authentication. After a proof-of-concept was leaked prematurely, Dutch organizations, including the NCSC, took their websites offline as a precaution. The official patches released today at 4:00 p.m.
The vulnerabilities are registered as CVE-2026-109618 and CVE-2026-109619 and have a CVSS score of 9.2. An attacker does not need any login credentials. Interaction with a user or administrator is also not required. According to the National Cyber Security Center, a simple POST request may be enough to execute external code on a vulnerable web server.
The problem lies in the PHP engine itself. The issue arises during the parsing process (analyzing data and converting it into a comprehensible format) of incoming HTTP requests in memory. This happens before the application code even runs. As a result, application-level security measures are ineffective. A heavily secured custom system is just as vulnerable as a standard WordPress installation. Even frameworks like Laravel or Symfony and a CMS like WordPress offer no protection because their security checks aren’t active during this request phase. Anyone who successfully executes the exploit can immediately run code with the privileges of the web server process.
The timing makes the situation particularly challenging. Normally, responsible disclosure handles such a vulnerability, with a tested patch ready before the details go public. With PHP2Shell, that process went awry. A working proof-of-concept was leaked via an anonymous post on Hacker News. As a result, the PHP maintainers had to abandon their release schedule and rush to create emergency patches.
Dutch sites go offline as a precaution
The consequences were clearly visible this morning. Various major Dutch web platforms, security forums, news sites, and government portals temporarily took their systems offline or disabled dynamic features. The NCSC did the same with its own website. These organizations felt the risk was too great to wait for a working, tested patch. IT teams had to decide as early as last night whether to shut down critical systems as a precaution.
That patch is now on the way. PHP will release the official fixes today at 4:00 p.m. Dutch time. The NCSC advises organizations to be prepared to install the update immediately. Afterward, they must restart PHP-FPM or Apache. When you update a Linux server, the new PHP binaries and libraries are written to the disk. However, active processes in RAM continue to execute the old code. Only when the process manager controlling PHP restarts will the server load the patched version.
Is the vulnerability already being actively exploited? Reports on this vary. Reports say SOCs detected massive, automated scans within hours of the proof-of-concept being leaked. Botnets scanned large blocks of IPv4 and IPv6 addresses for open ports, looking for servers running PHP. The initial waves of attacks are believed to be opportunistic and primarily aimed at installing web shells and cryptominers. Ransomware groups and APTs are also reportedly using the vulnerability to gain entry, then move further through the network. However, the NCSC currently reports no confirmed active exploitation. Huntress also initially observed no exploitation in the wild.
Large attack surface
The number of potential targets is large. Nearly 75 percent of all websites whose server-side technology is known run on PHP. However, the language has lost ground in recent years to Node.js, Go, and Python. Because the flaw exists in a widely used codebase, it affects virtually all active PHP versions. Security firm Sansec cites all installations running PHP 5.4 or later. The company specifically highlights online stores running on Magento, Shopware, or WooCommerce.
CMS platforms such as WordPress, Drupal, and Joomla are also at risk. For many organizations, these form the foundation of their websites. Less visible, but just as vulnerable, are internal applications: intranets, time-tracking systems, and older CRM packages. While they often appear inaccessible from the internet, attackers can still reach them through routing errors or supplier connections (supply chain).
Emergency measures until the patch
For many organizations, the PHP version they’re running is the biggest problem. Official fixes are only released for supported branches, currently PHP 8.2 through 8.5. PHP 8.1 and older versions do not receive official patches from PHP itself.
Those running such an older version must rely on expensive commercial support contracts from Linux vendors or migrate. It is recommended to immediately migrate sites running PHP 8.1 or older to a supported version, or to temporarily take them offline.
In large enterprise environments, a controlled rollout takes time, so administrators resort to temporary measures. The first line of defense is a Web Application Firewall (WAF). Cloudflare, AWS, and Akamai enable virtual patches within hours. Users of these services must, however, verify that the rules against anomalous multipart/form-data payloads are active and set to block.
And without such an external filtering layer, administrators must intervene on the web server itself. By changing the configuration, they can discard suspicious requests before they reach PHP-FPM. A commonly used but user-unfriendly measure is to temporarily block all file uploads or significantly reduce the maximum POST size.
If that doesn’t work, the only option left is the emergency brake: putting the application into a static read-only mode or taking it offline entirely. Security analysts must also search log files for Indicators of Compromise (IoCs). Automated scanners may have already infiltrated servers in the hours before the emergency measures took effect.
Tip: Serious vulnerabilities in PHP; emergency patches on the way