PHP2Shell Vulnerabilities: WEM No-Code Is Not Affected

The vulnerabilities themselves are serious. Both carry a CVSS v4.0 score of 9.2 and can allow unauthenticated remote code execution on servers running PHP, and organizations across the Netherlands, including government bodies, took websites offline as a precaution while they waited for fixes. This article explains what happened, why WEM No-Code sits outside the impact zone, and what WEM customers should still check in the systems that run alongside the platform.

On October 20, 2026, the PHP security team gave advance notice of a critical security release. On October 21, it published fixes for two flaws that security researchers have nicknamed PHP2Shell. According to the official PHP security advisory, every PHP installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed.

PHP rates the risk highest for mod_php, where a demonstrated exploit triggers the attack before any application code runs. That detail matters: well-written application code offers no protection here, because the flaw sits in the PHP engine itself rather than in anything built on top of it.

The Dutch response showed how seriously the threat was taken. Before patches were available, the Nationaal Cyber Security Centrum (NCSC) advised owners of PHP websites to make their own risk assessment and, where needed, take sites offline preventively until the update arrived. The NCSC took its own website offline as a precaution, and a number of Dutch government websites followed, as reported by the Rijksoverheid.

Patches are now out, and the NCSC’s current alert is direct: if you use PHP in websites or web applications, install the updates as soon as possible. The NCSC has also published a decision tree to help organizations work out which measures apply to them. CERT-EU gives the same advice at the European level.

One line in the Rijksoverheid update is worth noting. A large share of central government websites, including Rijksoverheid.nl, do not use PHP, so the vulnerabilities did not apply to them. The same logic is why WEM No-Code customers did not need to take anything offline.

When a critical flaw hits a language that runs much of the web, IT teams have hours, not days, to establish which of their systems are exposed. The tempting assumption is that every web application platform carries the same exposure. It does not. Exposure depends on what actually runs in your stack.

The WEM platform does not use PHP in any of its components. As Douwe Roelofsen, COO of WEM No-Code, wrote to customers and partners on October 21, 2026: “Your WEM applications and environments are therefore not affected by these vulnerabilities, and no action is required on your side.”

Three facts about the WEM No-Code architecture explain why this is a component-level answer rather than a configuration workaround:

• No generated source code. WEM applications are typed models executed by a fixed engine. There is no generated PHP, or any other generated source code, sitting on a web server for an attacker to reach.
• A hardened runtime. WEM’s environment runs on a hardened Kubernetes cluster deployed on an ultra-thin Linux distribution with a single entry point, and it is regularly penetration tested by enterprise and government organizations.
• The same answer for every deployment option. Because no component uses PHP, the answer holds whether you run on WEM’s cloud, a dedicated public cloud such as Azure or AWS, or on-premise.

WEM No-Code being unaffected does not mean every system around it is. Many organizations run PHP somewhere in their landscape: a corporate website on a PHP-based CMS such as WordPress or Drupal, an intranet, a portal from another vendor, or integration tooling. If any of those exchange data with your WEM applications, they deserve attention this week.

1. Inventory your PHP systems. List every internet-facing system that runs PHP, including products where PHP is embedded, and you depend on the vendor to ship an update.
2. Update to a fixed release. Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. PHP notes that Linux distributions and LTS vendors received the patches in advance, so check your vendor’s packages first.
3. Plan for older versions. PHP 8.1 and older no longer receive updates from the PHP project. PHP published minimal source backports for 7.4, 8.0, and 8.1 given the severity, but upgrading to a supported version is the durable fix.
4. Treat mitigations as temporary. PHP lists interim configuration measures, but states they reduce exposure to specific attack paths without making an installation safe.
5. Ask your vendors directly. For packaged products, request the vendor’s patched version and timeline in writing, and use the NCSC decision tree to decide what to do in the meantime.

PHP2Shell will not be the last critical flaw in a widely used runtime. For a CIO or IT leader, the useful question is not only “which language does this platform use?” but “when the next runtime vulnerability lands, who carries the patching work, and how fast will I know where I stand?”

On a self-managed stack, each owner has to find, test and install the fix, and the clock starts the moment a patch becomes public, because attackers can compare patched and unpatched versions. On a managed platform, that work should sit with the vendor. Use these four questions to test any enterprise no-code platform you rely on:

For financial institutions, this is also a regulatory question. Under DORA, how your ICT providers handle vulnerabilities is part of your own operational resilience, which we cover in our guide to DORA compliance and operational resilience.