Skip to content
IT-Checklist

PHP2Shell: why DigiD went offline and what to do with your website

Last updated on

Read the in-depth version

On Wednesday 21 October 2026 dozens of websites in the Netherlands suddenly went dark. DigiD (the Dutch government login), the Dutch parliament, the news site of broadcaster RTL, tech site Tweakers, hospitals and city councils. They had not been hacked. They took their own sites offline as a precaution, because of two critical flaws in PHP. Does your website run on WordPress? Then it runs on PHP too.

What happened

PHP is the programming language behind about 70 percent of all websites (NOS, in Dutch (opens in new tab)). WordPress, Drupal and Joomla run on it, and so do countless web shops. The two flaws, together known as PHP2Shell, let an attacker run their own code on the server with an ordinary web request. No login needed. That gives them your website's files, passwords and keys (CERT-EU (opens in new tab)). The bug had been there for more than ten years (Wiz (opens in new tab)).

Researchers found the flaws in August with the help of AI. On the evening of Tuesday 20 October details leaked before the fix was ready. The Dutch National Cyber Security Centre (NCSC) wrote that every system with PHP that can be reached from the internet was presumably vulnerable. So many organisations did not wait. The update came out on Wednesday afternoon and the first sites came back online in the late afternoon (NOS, in Dutch (opens in new tab)).

Why updating WordPress is not enough

The flaw is in PHP itself, the software on the server that WordPress runs on. Updating WordPress, your theme or your plugins does not change the PHP version (Hackread (opens in new tab)). Your hosting provider or web developer has to update it.

The safe versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (CERT-EU (opens in new tab)). PHP 8.1 and older no longer get regular updates. If you run one of those, you need to move to a newer version. Changing settings or a firewall like Cloudflare's makes an attack harder. The hole stays open though.

What to do now

  1. Find out which PHP version your site uses. Check your hosting provider's control panel or ask your web developer. In WordPress you find it under Site Health, then Info and Server.

  2. Ask your hosting provider whether the update is installed. Mention the version numbers above. If you run your own server or VPS, install your Linux distribution's update and restart PHP.

  3. Running PHP 8.1 or older? Plan the move. Test on a copy of your site first, because old plugins do not always work on a newer version.

  4. Check whether someone already got in. "A patch closes the hole, but does not undo an earlier break-in", said Dutch ethical hacker Wouter van Dongen (RD, in Dutch (opens in new tab)). Look for unknown admin accounts and new or changed files. In doubt? Renew your passwords and API keys.

  5. Keep a backup that is not on the same server. Then you can go back to a clean version if something did go wrong.

Put your website in your emergency plan

When small businesses think of an emergency plan, they think of ransomware on a laptop. This week showed that your website may suddenly have to go offline too, without you doing anything wrong. Customers look up your phone number on your site and your web shop stops taking orders.

That's why we added a website section to our incident response plan. You write down beforehand who can take your site offline and where a simple emergency page is ready. Such a page is a single HTML file with your name, phone number and email address, with no PHP and no database. Host it somewhere other than your normal hosting, so you still have it if that provider is down.

Download and print the cyber attack emergency plan

A checklist of a few pages that you fill in once and then print. With the first steps, a list of contacts and the reporting deadlines.

Go to the cyber attack emergency plan

Want to know where you stand? Take the free IT check and see the suppliers and cloud checklist for what to agree with your hosting provider.

In depth: the details

For readers who want more: technical details, the damage and the sources.

The two flaws

The flaws are CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) and CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp). The PHP security team rated both 9.2 on CVSS version 4.0 (php.net (opens in new tab)).

CVE-2026-109618: a bug when memory runs out

PHP enforces its memory limit (memory_limit) with longjmp(). When a request goes over the limit, PHP stops it at once. That can happen while PHP is still reading a form with a file upload. During clean-up PHP then frees memory that was never set up properly. That memory can still hold the attacker's data from an earlier request (CERT-EU (opens in new tab)).

CVE-2026-109619: references that stay behind

A request sometimes leaves internal data behind, for example after a fatal error. The memory has already been freed while the reference to it stays in place. A later request on the same worker uses that reference before PHP resets it (php.net (opens in new tab)).

What Wiz showed

Wiz worked out four bugs. They all go wrong when PHP stops in the middle of a request because of a fatal error or because it runs out of memory (Wiz (opens in new tab)).

  • A use-after-free in the session upload progress feature. Together with the memory leak below, Wiz used it to run code without logging in on WordPress, Drupal and Joomla.

  • A memory leak through the PHPSESSID cookie. During a multipart upload PHP can send pieces of freed memory back in that cookie. The website does not even have to use sessions. This let Wiz read memory from other requests, including passwords, tokens and API keys.

  • A use-after-free in the backtrace of the last fatal error. Wiz used it to take over Drupal.

  • Type confusion in OPcache, the cache that keeps compiled PHP code in shared memory. If a memory request fails at the wrong moment, another worker can reuse a slot marked as free for something else. Wiz used it to take over WordPress.

According to Wiz even a simple "Hello World" page on a vulnerable PHP version could be attacked. More variants exist. The update tackles the root cause and closes all of them, Wiz says.

Which servers are most at risk

Every PHP installation that handles web requests is at risk. That means PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates mod_php as the most dangerous. There the attack works with one request without logging in, before any code of the website runs (php.net (opens in new tab)). With PHP-FPM the website itself has to perform a suitable operation. More workers lower the chance per request, and the flaw is still there (Hackread (opens in new tab)).

An attacker gets the rights of the web process. That gives them the files and passwords that process can reach. It does not automatically make them administrator of the whole server (Hackread (opens in new tab)). PHP also sits inside appliances, network devices and management screens. The Dutch NCSC keeps a list of such products on GitHub (NCSC (opens in new tab)).

Affected and fixed versions

Wiz says nearly every version back to PHP 5.4 is hit by at least one of the bugs. The fix is in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (php.net (opens in new tab)).

PHP 8.1 and older no longer get updates from the PHP project. Small source patches were published for 7.4, 8.0 and 8.1 for people who build PHP themselves. Linux distributions and long-term support vendors got the patches in advance and sometimes ship backports for old versions too. The volunteer-run package source rpms.remirepo.net had no updates on release day. PHP advised switching to your distribution's packages or building from source. Also mind the calendar: PHP 8.2 gets no more updates after 31 December 2026 (php.net (opens in new tab), CERT-EU (opens in new tab)).

Temporary measures and why they are not enough

If you cannot update straight away, PHP lists a few measures. They make an attack harder. PHP itself says they do not make your installation safe (php.net (opens in new tab), CERT-EU (opens in new tab)).

  • Set session.upload_progress.enabled=0 in php.ini, the FPM pool or the server configuration and restart every worker. Doing it through ini_set() or .user.ini does not work. This only blocks the known route through sessions.

  • On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This only blocks the route through fatal error backtraces.

  • Set post_max_size to 8M if you have no uploads, or 32M if you do. Keep upload_max_filesize below it. Also set limits on the web server or proxy for request size and for the number of fields and multipart parts.

  • Set memory_limit=-1 through php_admin_value, so a website cannot change it back. A memory shortage at a lower level can still reach the faulty code. Do not use RLIMIT_AS or RLIMIT_DATA, because they can cause exactly that shortage. A container or cgroup limit that only stops the affected worker is fine.

  • Hiding error messages with error_reporting, display_errors or @ does not help.

Cloudflare added firewall rules, also for customers on the free plan. Cloudflare itself calls this a stopgap. It only helps if your server accepts traffic through Cloudflare alone (Patchstack (opens in new tab)).

Was the flaw already being exploited?

Sources differ. The Dutch NCSC had not seen active exploitation by Wednesday afternoon (NOS, in Dutch (opens in new tab)). Cloudflare saw the first attacks at 07:43 UTC. Patchstack received reports from hosting partners that morning, but by mid-afternoon its own data only showed attackers probing (Patchstack (opens in new tab)). The Dutch NCSC expects attackers to keep trying to use these flaws for a long time (RD, in Dutch (opens in new tab)).

The attack happens below the website, so the logs of WordPress or Drupal show little. Wiz lists a few signs (Wiz (opens in new tab)).

  • Unusual multipart requests followed by memory limit errors or repeated HTTP 500 errors.

  • PHPSESSID cookies in your server's responses that are unusually large or oddly formed.

  • PHP workers that restart for no clear reason.

Patchstack advises treating a server that was vulnerable as hacked and replacing the passwords and keys stored on it (Patchstack (opens in new tab)).

Timeline

The role of AI

Wiz used its own system Wiz Atlas and the AI models Gemini 4 Argon from Google and GPT-5.6 Sol from OpenAI. They helped find the bugs, adapt the attacks to different versions and settings, and check the fix. Wiz had working attacks on several systems within hours. One researcher did in a week what used to take a top team months (Wiz (opens in new tab)).

That cuts both ways. Security researcher Costin Raiu said AI is powering a "race to exploit". Lukasz Olejnik of King's College London said that with AI, exploitation may happen instantly and on a large scale (RTÉ (opens in new tab)).

How other countries reacted

In the Netherlands at least 13 of the 25 regional safety authorities took their sites offline, and so did NotuBiz, the meeting system of more than a hundred councils, provinces and water boards (RD, in Dutch (opens in new tab)). Others included the Dutch football association KNVB, the sick-leave tool of benefits agency UWV, the upload system of public broadcaster NPO and charities such as the Dutch Cancer Society. The Schiphol airport app briefly showed no live flight data (NOS, in Dutch (opens in new tab)). Hosting provider Mijndomein took its web hosting and webmail offline (Mijndomein, in Dutch (opens in new tab)). Ahold Delhaize saw no link with the attack on Albert Heijn a week and a half earlier (NOS, in Dutch (opens in new tab)).

In Belgium all Flemish government sites went offline for a while (NOS, in Dutch (opens in new tab)). So did public broadcaster VRT, the Federal Public Service Finance, court websites, e-ID, Smartschool, eight hospitals, rail operator Infrabel, the Port of Antwerp-Bruges and the Rock Werchter festival. The Belgian Centre for Cybersecurity had not seen attacks in Belgium on Wednesday (VRT, in Dutch (opens in new tab)). The French Interior Ministry put all its websites into maintenance mode. In Finland Valtori took government services offline and in Denmark Kombit shut down services including the national school platform. Japanese prime minister Sanae Takaichi urged website owners to install the fix (RTÉ (opens in new tab)). Japanese hosting providers also went into emergency maintenance (Patchstack (opens in new tab)). The US NSA called on people to update (NOS, in Dutch (opens in new tab)).

Many countries still reacted more calmly than the Netherlands. Dutch security expert Sijmen Ruwhof told the AD that media attention made the difference. Once DigiD, the NCSC and RTL go dark, it is easier for an IT person to ask the boss to switch off the company site too (AD, in Dutch (opens in new tab)).

The PHP Foundation

The foundation behind PHP was frank about its own role. As early as 2024 there were signs that one of the bugs could be exploited. Work on a fix kept stalling, because the security team could not agree and too few people had the right knowledge. The foundation itself calls this a structural failure. It also says Calif posted a video too early by mistake and that the company Chainguard broke an agreement not to publish yet (AD, in Dutch (opens in new tab)). From now on the security team can decide by majority (NOS, in Dutch (opens in new tab)).

What it costs

Nobody knows yet what taking all those sites offline cost. On 21 October we found no reliable estimate. Dutch justice minister Van Weel said taking sites offline has an impact on the digital society (NOS, in Dutch (opens in new tab)). Experts expect the effects to last for months. Sites that do not update quickly stay vulnerable, and an earlier break-in sometimes only comes to light later (RD, in Dutch (opens in new tab)).

Sources