On Wednesday 21 October, Node.js and PHP both shipped security fixes on the same day. PHP sits under every WordPress site. Node runs a large share of newer web apps, including our own platform. Here is what was fixed, what we did about it and what our host did for you overnight.
What was actually fixed
PHP fixed two critical flaws, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 out of 10. Either one can let an attacker run their own code on the server without logging in. PHP's announcement says every PHP installation serving web requests is at risk, and that the suggested workarounds only narrow the exposure. Updating is the only complete fix.
The researchers who found them combined the two into an attack they called PHP2Shell. Sansec reports that a public exploit exists and that Cloudflare saw early attacks hours before the release. It also says the public exploits fail on a standard PHP setup, because most of them need a second weakness in the site itself. So this was serious, but it was not "every WordPress site gets hacked tonight".
Node.js fixed four high-severity issues. The worst was a bug in its Brotli decompression that could allow remote code execution. Two more were ways to get past the check that a TLS certificate belongs to the server you meant to talk to. Node 20 has reached end of life, so it got no fix at all.
The PHP half was our host's job
On shared hosting you do not control PHP itself. The host does. Our WordPress hosting runs with Synergy Wholesale, an Australian wholesale host, and their status page reads like a good timeline of how this should go (all times AEDT, Thursday 22 October):
- Midnight, an hour before the release went public: they restricted file uploads through PHP on customer websites, and on their own management interface too.
- 8:58am: CloudLinux, who make the server operating system, were preparing patches for every PHP version from 5.2 up.
- 2:44pm: patches deployed and the restrictions lifted.
The upload restriction fits the attack. According to Sansec, it needs the kind of request a browser sends when a form uploads a file. Blocking uploads is consistent with closing that path until the patches were in. If a contact form with an attachment field failed on your site on Thursday morning, that is why.
Why your version number did not change
This part would trip up a careful person. Look up the PHP version on a site hosted this way today and it may still show the September version number (8.3.35, not 8.3.36). That does not mean it is unpatched.
CloudLinux puts the fix into its own build of the version you already have. Its advisory says its packages carry the fix as a backport, so their version numbers stay below PHP's. The fix shows up in the package changelog on the server, which only the host can see.
I checked the PHP versions on the WordPress sites we look after on Friday and saw exactly that: the old numbers. From the outside there is no way to tell a patched build from an unpatched one. What you can do is read your host's status page, and that is a good reason to pick a host that has one and writes on it promptly. If yours said nothing this week, ask them.
The Node half was ours
Our own platform (this site, the Website Builder, Insights reporting, Monitoring and our proposals system) runs as eleven Node services on Render. Hosting platforms like that do not upgrade your Node version on release day. They run the version you have told them to, or a default if you have not.
We had not told them precisely enough. Most of our services were on the platform's default, which was older than the fix. Two had drifted onto the newest major version through an open-ended "version 20 or later" setting. One was still on a version that no longer gets security fixes at all. None of that shows up until you go looking.
Every service now has an exact version pinned, so it only changes when we change it on purpose and test it. I did not trust the setting either: I confirmed the version actually running in every service's deploy log.
And the libraries underneath
The same week we audited every package the platform depends on. Most fixes were small patch updates. The Website Builder was the exception. It was built on Astro 5, and Astro's critical remote code execution flaw in image processing is only fixed from Astro 7.2.8. There is no fix for version 5.
Jumping two major versions at once is how sites break, so before anything went live we ran the old and new versions side by side against the real data. All 23 public pages returned the same status codes with identical visible text, and the stylesheet matched production exactly. Then came the test suites: 87, 392 and 900 tests passed across the three biggest projects. The first reporting data refresh after the update completed 8 of 8 with no errors.
A few items left over need bigger upgrades. None are critical, so they are scheduled rather than rushed in alongside everything else.
What this means for your site
- On WordPress with a decent host: PHP should have been patched for you this week. Check your host's status page or ask them. Your plugins and themes are still your job, and they are the more common way in. How a backup plugin let an attacker in →
- On PHP 8.2: it stops getting security fixes on 31 December 2026. Plan the move to 8.4 now and test it on a copy first.
- Running an app on Node: ask whoever built it which Node version it is pinned to. "Whatever the default is" is the answer to worry about.
- On a care plan with us: this is already done. It is exactly the work the standing patching note in your report refers to. What changed in your reports →
Patching week is the least visible part of looking after a website. When it goes right, nothing happens. That is the point, and it is also why you should know it is happening.
Want patching week handled for you, with the work written down?
Managed hosting and care →