← All insights

The PHP emergency patch of 21 October: four questions for your web partner

Jacques Domenie · October 21, 2026 · 4 min read

Updated 21 October 2026, after PHP's release at 14:00 UTC.

On 20 October I read the PHP security team's announcement: two critical vulnerabilities, an emergency release on 21 October at 14:00 UTC. Then I opened the list of supported versions, and one detail stayed with me. Versions PHP no longer supports get no official update. In many mid-sized companies, PHP sits in a layer the company never sees: a web agency, hosting provider or IT service provider runs it. The risk stays with the company. So there is one thing to do: send your web partner four questions and record the answers in your supplier register.

Where PHP sits in your company

PHP is the programming language behind about 70% of websites whose language is known. In a mid-sized company it usually runs the corporate website (often WordPress), the web shop (WooCommerce, Magento, Shopware), the customer or dealer portal and the intranet. Hosting control panels and suppliers' equipment use PHP as well. You see none of it.

What PHP has confirmed

The safe versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. According to PHP, the two flaws allow unauthenticated remote code execution. In plain words: someone on the internet can run their own commands on the server behind your website without logging in. It applies to every PHP installation that serves web requests. PHP rates the risk highest for Apache with mod_php, where an attack has been demonstrated that works before your website's own code runs.

That means a WordPress or plugin update does not fix this. PHP itself has to be updated, and your partner does that, not your marketing team. According to PHP, updating is the only safe choice; temporary settings do not make an installation safe.

Little is certain yet about attacks. On 21 October Patchstack (via hosting providers) and Cloudflare reported the first ones; nobody has confirmed them independently. The Dutch National Cyber Security Centre (NCSC) took its own website, ncsc.nl, offline as a precaution on 21 October. Details leaked before the agreed date, so attackers had a head start.

The detail that stayed with me

If you run an old PHP version, you get no official update. PHP supports versions 8.2 to 8.5. Given the severity, the security team did publish a minimal source-code fix for 7.4, 8.0 and 8.1, for people who build PHP themselves. Some Linux distributions and long-term-support vendors also ship a repaired version. For anything older, PHP offers nothing.

That is no edge case. According to W3Techs, 27.0% of PHP sites run PHP 7 and 7.7% run PHP 5. So almost 35% of PHP sites run a major version with no official update. Add the sites on PHP 8.0 and 8.1, and it is almost half.

The second detail is less visible. PHP 8.2 gets security updates until 31 December 2026, ten weeks after this patch. A site neatly updated on 8.2 now faces the same question in January.

Why this is a supplier question

You don't run PHP yourself, but the risk is yours. If the web shop goes down or customer data leaks, that is your problem, not the web agency's. Do you know, off the top of your head, which PHP version runs under your web shop, and what your contract says about how fast your partner patches? If not, that is where the gap is.

Researchers call a web application firewall a stopgap at best, and PHP itself says there are no complete alternatives to updating. "We have a firewall in front of it" is therefore not a complete answer.

The four questions

Send these questions to your web agency, hosting provider or IT service provider:

  1. Which PHP version runs on each of our sites and systems: website, web shop, portals, intranet and control panels?
  2. When will our sites run PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or a repaired version from your vendor), and how will you confirm that to us?
  3. What happens to our sites on PHP 8.1 or older, which get no official update: a repaired version, an upgrade, shielding, or taking them offline? And what is the plan for sites on 8.2 before 31 December?
  4. How would you notice if one of our servers had been compromised, and within how many hours would you tell us?

Put the answers in your supplier register: the list of suppliers and what each one runs for you. One line per site is enough: supplier, PHP version, date of the patch, plan for end of support, and the contact in case of an incident.

And the Dutch Cybersecurity Act?

If your company falls under the Dutch Cybersecurity Act (Cyberbeveiligingswet, Cbw), supply-chain security and vulnerability handling are part of your duty of care. A significant incident then needs an early warning within 24 hours. Question 4 decides whether you can meet that deadline. If your company is not covered, the questions are exactly the same. What the Act asks of directors themselves is in my piece on article 24 of the Cbw.

Do you know, without calling anyone, which PHP version runs under your web shop?

Jacques Domenie led the IT function of a bank under central-bank supervision and led enterprise architecture in two industrial companies. He works for organisations part of the week through Delfen.

Contact: domenie@delfen.com or delfen.com/en/contact.

Sources

Recognize this question in your own organization? That is worth a conversation.

Get in touch