Website Security: A Bad Week for PHP, Node.js and System Administrators
Welcome to the thankless job of Website Security. I’ve spent a rather ridiculous amount of time over the last week looking at software versions. Not glamorous work. Nobody calls to thank you because a web server didn’t get compromised on Thursday. But it’s the sort of work that keeps a perfectly ordinary business from having a spectacularly bad year.
On October 21, the PHP project released fixes for two critical vulnerabilities. The Node.js project published a separate set of security updates the same day. These aren’t obscure programs living in a dusty corner of somebody’s laptop. PHP sits underneath enormous numbers of websites, including WordPress installations. Node.js runs web applications, services, and a staggering amount of the glue connecting modern software.
Both advisories landed while we were reviewing older systems, closing unnecessary exposures, and working out how to preserve data before making disruptive changes. That overlap is the opening chapter of a short series I’m calling The Infrastructure We Trust. The subject is larger than patches. It’s all the important things we depend on without necessarily knowing how they’re protected.
It’s not a plugin
The PHP security team identified CVE-2026-109618 and CVE-2026-109619, two flaws rated 9.2 on CVSS 4.0. Both involve mishandling memory and request state inside PHP itself. Under the right conditions, an attacker who isn’t logged in may be able to execute code remotely. Google and Wiz published a technical explanation of what went wrong. The PHP project described the flaws as critical and said there are no complete alternatives to installing the fix.
This distinction matters to anyone with a WordPress website. Updating WordPress core and every plugin doesn’t update the PHP interpreter running the site. PHP-FPM, Apache modules, hosted control panels, container images, and application runtimes have their own maintenance and patch paths. A green plugin-update screen is nice. But if the tires are bald it doesn’t matter how good the engine runs.
Upstream fixed releases are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Older branches no longer receive official PHP-project updates. Some hosting vendors maintain older branches with their own backported fixes, but you have to verify the actual packaged fix rather than assuming a familiar-looking version number is either safe or vulnerable. A supported version and a documented backport are very different from simply ignoring the problem.
WordPress security & maintenance
Keeping WordPress current is only part of keeping it healthy. Raymond Tec handles updates, backups, security monitoring, compatibility problems, access cleanup, and maintenance — plus the assorted weirdness that accumulates on a site over time.
Node.js had its own security-release day
Also on October 21, Node.js released 22.23.4, 24.22.1, and 26.12.1. The advisory covers certificate and DNS validation problems, dependency updates, and a high-severity out-of-bounds write in its Brotli decoder, CVE-2026-111497, that can permit remote code execution in affected conditions. That does not mean every Node application is trivially exploitable. It does mean operators need to check the release line, how the application uses the vulnerable components, and what process actually runs in production.
Here’s where “we updated the server” gets misleading. If an app runs in a container, changing Node or PHP on the host usually changes nothing inside that container. You may need a new base image, rebuilt dependencies, a new deploy, and verification that the old image isn’t still running. Likewise, a development workstation running a fixed version says nothing about a forgotten production worker.
Website security maintenance is an inventory problem before it’s a patching problem. You need to know what is running, where it is running, how it was installed, what depends on it, and which parts are exposed to the Internet. Otherwise you’re just updating the things you remembered.
What we’ve actually been doing this week: Website Security
Across the systems I maintain, the first step has been separating those questions instead of treating every security alert as the same emergency. Which web services actually execute PHP? Which applications use Node? Which are managed by the operating system, which by a hosting vendor, and which have their own release images? That’s less exciting than running an update command, but it avoids both needless work and missed exposure.
We’ve been verifying patch availability, including vendor-maintained fixes for older runtimes that can’t be upgraded blindly. Older business software has a way of making “just install the latest version” sound delightfully simple until it breaks checkout, licensing, or a dependency nobody remembers installing. That doesn’t excuse running unsupported software indefinitely. It does mean we need a migration and retirement plan, not a reckless midnight upgrade.
On the web-facing side, the hardening work includes reviewing TLS and redirects, locking down administrative paths and hidden configuration files, eliminating diagnostic pages that expose server internals, restricting executable content in upload locations, examining DNS, and checking which services can actually be reached from outside. Firewalls and application filtering are additional layers. They are not a substitute for applying an upstream runtime patch.
Just as important, we have been treating changes as things that can fail. Before making potentially destructive updates, preserve a recoverable copy of the data and configuration; know how to roll back; and check the user-facing transaction that matters afterward. For a store, that might be checkout, order processing, and a refund. For a site, it might be a form submission, scheduled publishing, and the ability to get back into the admin area.
Backups & recovery
Backups are comforting right up until you need one. Raymond Tec helps small businesses build practical backup and recovery plans — including the decidedly unglamorous part where we make sure the thing can actually be restored.
Backups aren’t a checkbox, either
I keep coming back to three different assets: the current working system, the data you need to preserve, and a functioning path to restore it. A backup in the same account with the same administrator permissions may be reachable by the same attacker. A database dump without the application files and configuration may not be a complete recovery. An archive you’ve never restored is a promise, not a test.
For anything containing sensitive customer or financial information, encryption, retention limits, access controls, and a second recovery location deserve as much attention as the backup schedule. We have been working through what needs to be preserved, which copies should be isolated or off-site, and how to avoid making the rescue plan another source of exposure. Some of that work is already implemented; some still needs verification and recovery testing. I don’t intend to confuse the two.
This is also why “the update completed” isn’t the end of the job. You check the effective runtime version, service health, logs, public endpoints, and the real business workflow. Then you leave the monitoring on. A successful package-manager message is not a functional acceptance test.
Why this matters beyond our little corner of the Internet
The October attacks on French supermarkets offer a particularly physical demonstration. Attackers compromised remotely managed refrigeration equipment, forcing stores to throw out spoiled food. France’s national cybersecurity agency warned about exposed management interfaces and recommended removing direct Internet access. Here the vulnerable software wasn’t publishing a page. It was helping keep food cold.
Around the same time, Ahold Delhaize disclosed a separate malicious intrusion that led it to take websites, apps, and other systems offline as a precaution. Its stores largely stayed open, but online ordering and other operations were disrupted. Dutch authorities said there was no established link between the incidents. That’s worth remembering: two alarming events on the same week aren’t automatically the same attack.
I don’t know who attacked the French refrigerators. I do know that a refrigeration controller, a checkout system, and a WordPress server share one uncomfortable property: they can become someone else’s problem when the people responsible for them don’t know what’s exposed, what’s unpatched, or how to recover.
Compromised website help
Sometimes maintenance starts after the damage is done. Raymond Tec can investigate compromised sites, clean up access, recover what can be recovered, and patch the original problem — then help make the next incident considerably less exciting.
What I’d want any business owner to ask
Ask the person who maintains your systems for the current inventory, not a vague assurance that “updates are automatic.” Ask when the underlying runtimes were patched, whether any remote admin interfaces are public, how backups are protected from the production accounts, and when a restore was last tested. Then pick one critical workflow and ask what happens if its main software goes away for a day.
You won’t prevent every unknown vulnerability. None of us will. You can, however, remove a remarkable number of avoidable opportunities for an attacker and make a successful intrusion much less likely to become the end of the business.
In the next article, I’m moving from the software we maintain to the infrastructure we usually take for granted. Water, refrigeration, electricity, and the services that keep ordinary transactions moving. The question is simple: What are we relying on, and what do we actually know about its security?
Keeping a website running is its own job. Raymond Tec provides website security and maintenance, including updates, backups, monitoring, access cleanup, recovery planning, and help when something has already gone sideways.
Sources and further reading
- PHP Project: October 21 critical security releases
- Google Cloud: Technical details of the two PHP runtime vulnerabilities
- Node.js Project: October 21 security releases
- cPanel: PHP vendor-maintained security release guidance
- CERT-FR: Refrigeration controller security alert
- Ahold Delhaize: October 19 incident update
- Raymond Tec: When Security Tools Become the Attack Path
Featured photo: Ray Suarez via Pexels, used under the Pexels License. Illustrative image; it does not depict the French supermarket attacks.
