On the morning of 21 October DigiD was offline. So were MijnOverheid, the website of the Tweede Kamer, Tweakers and the National Cyber Security Centre's own site. Not because they had been hacked, but because they did not want to be.
A lot of webshops did the same, including shops we look after.
What happened
On 20 October details of two critical flaws in PHP leaked, before the people who maintain PHP had a fix ready. The PHP team rated both 9.2 out of 10 and scheduled an emergency release for 14:00 UTC the next day, 16:00 Dutch time.
That left most of a working day in which the problem was public and the fix was not. CERT-EU, the cyber security service of the EU institutions, told organisations that could not patch straight away to consider taking their sites offline. The UK and Australian agencies gave similar advice.
Why this one was different
Most security problems in a shop live in a plugin, a module or a theme. You update that one piece and move on. This one is in PHP itself, the language the shop runs on. That puts every PHP site in scope at once: WordPress and WooCommerce, Magento, Shopware, PrestaShop, Laravel and everything else built on it.
Both flaws allow remote code execution. In plain terms: someone on the internet can make your server run code of their choosing. On a shop that means access to customer accounts, addresses and order history, and the chance to plant a script in the checkout that copies what customers type.
Early reports put every version from PHP 5 onwards in the affected range. Early analysis points at the way PHP handles file uploads and the progress of those uploads, which is switched on by default.
Reports about attacks were mixed. Some hosting companies and Cloudflare said they were already seeing them. Australia's cyber agency said it was not aware of any.
Why going offline was a sensible call
Taking a shop offline costs a day of sales, or half of one. Someone running code on your server can cost you your customers' data, a report to the privacy authority and a long cleanup. When the fix is hours away and nobody is sure whether attacks have started, closing for the afternoon is a reasonable trade. It is also easy to undo, which a data breach is not.
What made it painful for many shops was not the decision. It was working out, under time pressure, who could make it, how to close the shop cleanly, and who would open it again.
If your shop runs on PHP
The fix is a new PHP version on your server. It does not arrive through WordPress updating itself, a Magento or Shopware update, or your plugins. Whoever manages the server has to install it.
Find out who that is. Your hosting provider, your agency, a freelancer who set up the server years ago. If you have to search for the answer, that is the first thing to fix.
Ask which PHP version your shop runs. Versions past their end of life may never get this fix. If your shop is still on one of those, this is the moment that becomes expensive.
Ask when the update will be installed, and get the answer in writing.
For anyone who manages servers and cannot update yet, two settings reduce the exposure. They are not a fix:
session.upload_progress.enabled = Off. This only turns off upload progress bars. Uploads keep working.session.use_strict_mode = 1, which is sensible hardening anyway.
Check them where the site actually runs. php -i on the command line reads the CLI configuration, which is often a different file from the one PHP-FPM uses:
php-fpm8.3 -i | grep -E "upload_progress.enabled|use_strict_mode"Write it down before the next one
This will happen again, with PHP or with something else every shop depends on. Write down three things while the day is still fresh: who updates your server, how you take the shop offline, and who decides to open it again. The next emergency release will not wait for you to work it out.