Mitchel van Emmerik Full-stack developer
Steam LinkedIn Twitch
© 2026 Mitchel van Emmerik
Nederlandse versie RSS feed
Blog

PHP2Shell, ten days later: what it did to Dutch webshops

On 21 October a PHP bug put Dutch webshops in lockdown. Ten days later: what happened, how hosts chose differently, and what to check now.

6 min read 12 views

  • php
  • security
  • e-commerce
  • php2shell

Ten days ago, a lot of the Dutch web went quiet on purpose. On Wednesday 21 October, sites from DigiD to Tweakers showed maintenance pages, hosting companies switched off entire platforms, and webshops stopped taking orders in the middle of a working day. The reason was PHP2Shell: two critical bugs in PHP itself.

Now that the dust has settled, I want to look back at what happened to Dutch webshops, which choices were made, and what is still open.

What PHP2Shell is, in short #

PHP2Shell is two vulnerabilities in the PHP engine, CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 (critical), and both can let an attacker run code on a server without logging in. The flaws are triggered while PHP is still reading the incoming request, before your application code even starts.

That's why it was so serious for webshops. Magento, Shopware, WooCommerce, PrestaShop: it didn't matter how clean or up to date the shop software was. If the PHP underneath was vulnerable, so was the shop. Even a shop's own maintenance mode didn't help, because PHP parses the request before the shop gets to check that flag.

PHP released fixed versions on 21 October at 16:00 Dutch time: 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

21 October: lockdown day #

The bugs became public before the planned release, so from Wednesday morning everyone was in a hurry. As a precaution, MijnOverheid, DigiD, the Tweede Kamer website and even the NCSC's own site went offline, and RTL Nieuws and Tweakers showed maintenance notices. Webshops and sports clubs followed.

For webshops, the decision was mostly made by their hosting company, and Dutch hosts chose very differently. Webhosters.nl kept a timeline per host:

  • Offline until patched. Hypernode, home to many Dutch Magento shops, took its whole platform offline at 14:30. Shops on PHP 8.2 to 8.5 came back between 16:45 and 18:18, the rest by 20:33. Mijndomein was offline from 14:30 to 18:05. The Versio group and the Yourhosting group took sites offline around 17:45 and only had everything back late on Thursday: about 29 hours without a shop.
  • Online with temporary measures. Hosts like Antagonist, Cloud86, Hoasted and Keurigonline kept sites up. They switched off the PHP feature behind one of the bugs (session.upload_progress), added firewall rules and patched through the evening and night. Keurigonline explained why: their setup keeps PHP separate from the web server and isolates every account, which lowers the risk.

E-commerce agencies made the same trade-off for their clients. Epartment summed it up as "liever even offline dan open voor een aanvaller" (better offline for a while than open to an attacker) and had almost all servers patched by 22:00.

At Guidance, where I work on Stentor, our B2B e-commerce platform for wholesalers, we had the same day. We updated our clients and took precautions. A lot of sites were on lockdown.

Ten days later: how bad was it? #

So far, less bad than feared. Partly because it was taken so seriously.

  • On 21 October Dutch e-commerce security firm Sansec already said mass exploitation looked less likely than first expected, and that stores didn't have to go offline as long as PHP got updated.
  • On 23 October the NCSC said the chance of large-scale abuse was lower than first thought, according to Webhosters.nl.
  • None of the hosts on that overview reported a break-in on their platform, and none of the agencies I read found signs that shops were hit.

That doesn't mean it's over. A few things are still open:

  1. Not everyone patched. NOS figures quoted by Webhosters.nl counted about 113,000 patched Dutch sites on 22 October, and about 145,000 that might still be vulnerable.
  2. Old PHP has no official fix. PHP 8.1 and older no longer get releases; there are only source backports that a host or vendor has to apply. Worldwide, Qualys counts 71% of PHP installs on end-of-life versions.
  3. PHP itself isn't done. On 23 October PHP advised keeping session.upload_progress.enabled off even after patching, because of a related issue that will be fixed in the next regular release.
  4. Appliances. The NCSC-NL tracker lists 217 vulnerable products, from firewall web interfaces to phone systems. They have PHP inside, and you can't update it yourself.

What webshop owners can learn from this #

  • An up-to-date shop is not an up-to-date server. Plugin and Magento updates didn't fix this one. Ask your host or agency which PHP version and build your shop runs on.
  • Check the build, not only the number. Distributions and hosts sometimes patch without changing the version number. The build date in phpinfo() tells you more.
  • Know your lockdown plan before you need it. Who decides to go offline, how do you inform customers, and how quickly can you be back? On 21 October some shops were back in two hours, others after more than a day.
  • Don't put off a PHP upgrade. On a supported version you just install the patch. On an old one you have to hope someone backports it. PHP 8.2 is supported until 31 December 2026; this site runs on it too, so that clock is ticking for me as well.

Is your site already secured? #

Check your PHP version now. These are the first versions with the fix:

PHP branch Patched from
8.5 8.5.12
8.4 8.4.27
8.3 8.3.36
8.2 8.2.35
8.1 and older no official release, only vendor backports

Check the PHP that actually serves your website, not just the one on the command line; they can differ. On your own server or container:

php -v

On shared hosting, look at the PHP version and build date in your hosting control panel or a phpinfo() page (and remove that page afterwards). If you run Docker, a container only gets the fix when you rebuild it with a fresh base image:

docker compose build --pull && docker compose up -d

Lower than the table above, or not sure? Ask your host or agency today. And keep session.upload_progress.enabled = 0 in your php.ini until PHP's next regular release.

Sources #