PHP vulnerability (PHP2Shell): what happened and what it means for your website

On October 21, 2026, PHP patched two critical vulnerabilities that allow for remote server takeover without a password. Thousands of sites in Belgium and France were taken offline as a precaution. If your site runs on WordPress, updating it is not enough: it is the version of PHP installed on your server that matters.

‍

What happened with PHP on October 21, 2026?

PHP, the language that powers approximately 70% of sites for which the server technology is known (W3Techs), urgently released versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. These fix two vulnerabilities in the PHP engine itself, not in a plugin or theme.

The first (CVE-2026-109618) is triggered when a request exhausts the allocated memory: internal data remains half-initialized and can be hijacked. The second (CVE-2026-109619) allows an internal state to persist after its memory has been freed, which a subsequent request can then reuse. In both cases, the potential result is the same: an attacker executes their own code on the server.

The PHP project is clear regarding workarounds: there are "no complete mitigations, updating is the only safe choice." In other words, filtering or tinkering with the configuration does not make a server secure. Only updating provides protection.

‍

‍

Artificial intelligence played a central role. According to Wiz, the exploit required a chain of steps at the limit of what a human researcher could construct, and AI models lowered that barrier. The downside is obvious: attackers have access to the same tools.

‍

Why were so many sites taken offline when none were hacked?

Sites were taken offline because a remote code execution vulnerability that requires no authentication is the worst-case scenario for a web server. No one needs to steal a password: a well-crafted request is enough.

Three factors accelerated the panic. Details leaked on October 20, the day before the scheduled release, with a demonstration video shared by mistake. Amazon Web Services reported on October 21 that the vulnerability was already being "widely" exploited. And Cloudflare, whose protection rules were active from 5 a.m., reported millions of attempts across its network.

Faced with this, authorities chose caution. The Centre for Cybersecurity Belgium (CCB) asked any organization unable to install the patch immediately to take its site offline. In France, ANSSI issued the same request to government sites (alert CERTFR-2026-ALE-014).

Taking a site offline is therefore not an admission of a hack. As summarized by Dimitrios Salampasis, a researcher at Swinburne University of Technology, quoted by France 24 : taking a site offline does not mean it has been hacked. As of October 22, the CCB had not recorded any attacks against a Belgian site.

‍

Which sites and companies were taken offline?

The organizations taken offline were primarily government agencies, hospitals, and media outlets: structures that host many PHP sites themselves and cannot afford to take any risks.

‍

In Belgium

The CCB's own website was taken offline. This was followed by the federal police (with 101 remaining reachable), the FPS Finance (finances.belgium.be, ruling.be), official Flemish sites at the request of the Minister-President, the Flemish Parliament, the Wallonia Public Service portal, the municipalities of Brussels and Ghent, Antwerp hospitals, and the Grand Hôpital de Charleroi (with no impact on patient care), according to RTBF and La Libre.

In the private sector, the school platform Smartschool was inaccessible, as were VRT, several DPG Media sites, and Roularta magazines (Le Vif, Trends Tendances, Flair, Femmes d'aujourd'hui).

One detail sums up the entire incident: MyMinfin, the online tax portal, remained accessible while finances.belgium.be was down. The reason is simple: MyMinfin does not run on PHP.

‍

In France

The Ministry of the Interior placed all its exposed sites into preventive maintenance, including those of the prefectures and the Paris Police Prefecture, at the request of ANSSI. No compromises have been reported.

‍

Elsewhere in the world

In the Netherlands, the NCSC took its own site offline, as did Overheid.nl, MijnOverheid, DigiD, and the Port of Rotterdam portal. Finland restricted several public services (Valtori), the University of Freiburg in Germany shut down its WordPress sites, and Wikimedia suspended certain services. In Canada, federal government sites also went down (CBC).

‍

‍

Why does PHP power so many sites?

PHP powers so many sites because it is the engine behind the most popular CMS platforms: WordPress, as well as Drupal, Joomla, PrestaShop, and Magento. WordPress alone powers over 40% of websites (W3Techs). According to Censys, at the time of the incident, there were approximately 2.58 million servers and 54.9 million websites running on PHP exposed to the internet.

This success has a downside. The language that runs banks, shops, and public services is maintained by a small team. The first signs of these vulnerabilities were identified in 2024 during an audit funded by the German government (Sovereign Tech Agency, OSTIF, Quarkslab), though no attacks were demonstrated at the time. Wiz compares the scale of the incident to Log4Shell, the 2021 Java vulnerability.

‍

Is my WordPress site affected?

Yes, potentially, if your server is running a version of PHP earlier than 8.5.12, 8.4.27, 8.3.36, or 8.2.35. The point many people miss: updating WordPress, your theme, or your plugins changes nothing. Automattic, the company behind WordPress.com, has reiterated that these updates alone do not protect you.

The question is therefore not "Is my WordPress up to date?" but "Who updates the PHP on my server, and have they done it?"

‍

‍

What to do this week

1. Check your PHP version: in WordPress, go to Tools > Site Health > Info tab > Server section.
2. If it is lower than the patched versions, ask your hosting provider for written confirmation of the update, including the date.
3. If you are on PHP 8.1 or older, consider the server exposed: the PHP project no longer releases official patches for these versions. Plan an upgrade, making sure to test your theme and plugins.
4. Have your server logs checked from October 20th onwards, as recommended by CERT-FR.
5. While waiting for the patch, a web application firewall (Cloudflare, Sucuri, or your host's offering) reduces the risk, though it does not eliminate it.

‍

What are the permanent risks of a PHP-based site?

The real risk of a PHP site isn't the language itself; it's that no one is clearly responsible for the server. The host thinks it's the agency, the agency thinks it's the host, and the marketing team doesn't know which version is running.

WordPress.org figures show it clearly. On October 22, 2026, 35.8% of WordPress sites connecting to its servers were running on PHP 8.1 or older—versions that no longer receive official patches. Another 23.7% were using PHP 8.2, for which security support ends on December 31, 2026. As of January 1, 2027, nearly 6 out of 10 WordPress sites will be running on a version of PHP without official support, unless they are upgraded by then.

On top of that, there is the rest of the stack: unmaintained plugins, modified themes that you're afraid to update, and shared administrator access. PHP2Shell is not an isolated accident. It is the spectacular version of a daily problem.

‍

Why were Webflow sites not affected?

Webflow sites were not affected because Webflow does not run on PHP. Its Trust Center is explicit: "Webflow's core services are not built on PHP and are not affected. No action is required from customers."

The difference is structural. A WordPress site generates every page on demand, on a server where PHP and the database are exposed with every visit. A Webflow site is published as ready-to-use pages, served by a global content delivery network (CDN). The visitor never reaches a PHP server that you need to update. Hosting, SSL certificates, and security patches are managed by Webflow, not by you.

That doesn't mean there is zero risk. Webflow indicates that it is still evaluating internal, non-production systems that use PHP. And on your site, what you add remains your responsibility: accounts without two-factor authentication, third-party scripts, custom code, or connected tools that run on a PHP server themselves. A WordPress blog alongside a Webflow site remains a WordPress blog that needs monitoring.

‍

Should you leave WordPress after PHP2Shell?

For a brochure site or lead generation site, yes, if no one on your team knows which version of PHP is running or who is updating it. You are paying for a server to be monitored for a need that doesn't require one. Webflow removes this issue and lets your marketing team evolve the site without a developer.

For a complex WooCommerce store or a business application with a responsive technical team, no, not necessarily. WordPress remains a defensible choice if someone is clearly responsible for the server, with a tested update process. Changing platforms in a rush creates other risks.

A well-executed migration does not cause a loss in SEO: 301 redirects, preservation of ranking URLs, and carrying over tags and structured data. At We-R, a migration to Webflow for a site with about twenty pages and a blog takes 6 to 12 weeks. To compare the two platforms beyond security, read our WordPress vs Webflow comparison.

‍

The next vulnerability is already on its way

PHP2Shell was discovered with the help of AI, and it won't be the last. The same tools will accelerate the discovery of vulnerabilities in all legacy and widely deployed software. The question is no longer "will my site be affected?", but "who is handling it when it happens?".

If you don't have a clear answer, let's talk. We'll review your current site and give you an honest assessment of whether you should migrate or not. Discover our Webflow support services