When a critical server vulnerability is disclosed, how fast a website gets patched depends on who has been given that job. The PHP flaws disclosed in October 2026 let attackers run code on a server without logging in. A web application firewall can buy time, but it can be bypassed, so someone still has to patch. The post ends with five questions to put to your hosting provider this week.
Today is a bad day to be running an unpatched PHP server.
Critical vulnerabilities in PHP were disclosed today (CVE-2026-109618 and CVE-2026-109619, covered in the Canadian Centre for Cyber Security’s advisory AL26-026). The worst of them lets an attacker run code on your server remotely, without logging in. PHP sits behind roughly 69% of websites where the server-side language can be identified, and that includes most WordPress sites, so this reaches well past the tech sector. Node.js shipped ten security fixes the same day.
The NSA’s advice is blunt. If you can’t update an affected PHP system right away, take it offline until you can.
That is simple advice for a security agency to give and a hard one for a charity whose donation page runs on PHP, or a municipality taking payments online. Who in your organization gets to make that call? How long would it take them to make it? Would they even hear about the advisory today?
There is a middle option. Cloudflare and Akamai have both pushed web application firewall rules to block attempts to exploit the PHP flaws. Cloudflare says its rules went out about nine hours before the public disclosure, and they cover free customers as well as paid ones. Akamai released detection rules through its App & API Protector product. A WAF sits in front of your server, looks at incoming requests and drops the ones that look like attacks, which buys you time to patch. People call this virtual patching. Most of the big cloud and CDN providers sell something similar, but check that yours has actually shipped rules for these specific flaws before you count on it.
The time it buys is the whole point, because a WAF won’t catch every variation of an exploit and it does nothing if an attacker finds your server’s real address and goes around it. The Node.js fixes show the other gap. Several involve outbound connections, DNS resolution and certificate checks, traffic a firewall watching inbound requests never sees. You still have to patch.
Same website, different risk
Take two organizations running the same WordPress site. One pays for managed hosting that applies security updates automatically, runs a WAF and keeps backups someone has actually tested. The other runs it on a cheap virtual private server, and every update, firewall setting and emergency fix depends on one internal administrator. Neither setup is insecure by default.
The second one is only as secure as that administrator’s calendar today.
What matters is whether someone has clearly been given the job and does it every time. When an advisory like this lands, someone has to work out which sites are affected and get them patched without breaking anything. If you can’t name that person, these are the questions I’d put to your hosting provider, developer or IT team this week:
1/ Who applies emergency updates to PHP, Node.js and the server underneath them? The hosting company, your developer or your own staff? Get a name.
2/ Is there a managed WAF, and can new rules go out within hours of a disclosure like today’s?
3/ Can someone reach the server directly and skip the WAF? If the origin server is open to the internet, the firewall can be bypassed.
4/ How quickly can you deploy a critical patch, and who can authorize taking the site offline if you can’t?
5/ If the site is compromised or goes down, are there tested backups and a written recovery plan, and does everyone know their part in it?
Those answers belong in the hosting decision right beside price and performance.
Not every site needs enterprise security. A simple informational site can be well covered by reputable managed hosting with automatic updates, a basic WAF and reliable backups. A municipal service portal handling residents’ sensitive information is a different risk, and probably needs managed security monitoring, network isolation and a formal incident response plan.
Who owns this
In a lot of organizations the website started as a communications project, and hosting was handed to the designer or the comms team without anyone looking at the operational risk. Since then the site has become where donations, registrations and payments come in.
Boards and executives don’t need to understand the PHP flaws. They do need to know whether the organization can respond when something this basic becomes unsafe. I think a critical website that depends on someone happening to see a security bulletin and finding an hour to update a server is a governance problem. The patch is the easy part.
There will be another day like today, probably soon. The NSA’s advice will be just as hard to follow next time if nobody owns the answer.
Frequently Asked Questions
What are the PHP vulnerabilities disclosed in October 2026?
Two critical flaws, CVE-2026-109618 and CVE-2026-109619, covered in the Canadian Centre for Cyber Security’s advisory AL26-026. The worst of them lets an attacker run code on a server remotely without logging in. PHP runs roughly 69% of websites where the server-side language can be identified, including most WordPress sites, so the exposure goes well beyond tech companies.
Does a web application firewall protect my site?
For a while, and only if your provider has shipped rules for these specific flaws. Cloudflare and Akamai both have, and Cloudflare’s rules cover free customers too. A WAF won’t catch every variation of an exploit, and if someone finds your server’s real address they can go straight around it. It buys you time to patch, and you still have to patch.
Should I take my site offline until it’s patched?
That’s the NSA’s advice if you can’t update right away. For a charity taking donations or a municipality taking payments, it’s a hard call, which is why someone needs the authority to make it before the day it comes up. If a WAF with rules for these flaws sits in front of the site and the server can’t be reached directly, you have a little more room.
Who should be responsible for patching a website?
Whoever it is, they should have a name and it should be written down. On managed hosting that’s usually the provider. On a self-managed server it’s your developer or your own staff. The risk is a site where everyone assumes someone else is watching the security bulletins.