PHP and Node.js security updates: what website owners should do now

A security headline lands. Someone forwards it. The website still loads, the hosting dashboard looks normal, and nobody is quite sure who should act.

That gap between hearing about a problem and verifying the fix is where a maintenance agreement earns its money. My first question would be simple: which running systems are affected, and who is responsible for updating them?

Checked on 25 October 2026. PHP and Node.js released separate security updates on 21 October. They are not one shared vulnerability, and an affected version is not proof that a particular website has been compromised.

PHP: update the runtime, not just the plugins

PHP's CVE-2026-109618 concerns memory-exhaustion handling; CVE-2026-109619 involves stale internal state surviving between requests. Both can permit unauthenticated remote code execution. The first was demonstrated against Apache mod_php before application code runs; other deployments need assessment too. The second depends on a reachable sequence of operations across requests handled by the same worker. See PHP's advisories for memory corruption and stale state, published 21 October.

The fixed releases for that pair are 8.2.35, 8.3.36, 8.4.27 and 8.5.12, on their respective branches. Distribution packages can carry backported fixes, so ask for the vendor advisory and installed package build rather than judging the version string alone. NCSC operational guidance.

For a WordPress or PHP application owner, “all plugins updated” therefore does not answer the runtime question. Your developer and hosting provider may own different parts of the job. Get them to name those boundaries.

Node.js: a different fault, with a specific exposure path

CVE-2026-111497 affects the bundled Brotli decoder. An application must decompress attacker-controlled Brotli data through node:zlib for this path to be reachable; consequences can include a crash, memory disclosure or remote code execution. The security releases are 22.23.4, 24.22.1 and 26.12.1. The release also addresses other issues, so a Brotli-only assessment is not a reason to skip updating. Node.js advisory, 21 October.

Seeing “JavaScript” on a website does not tell you which server runtime is deployed. Equally, a successful dependency audit is not an inventory of every running service. Ask about containers, background workers and build systems as well as the public web server.

Read the updates to the update

In its 23 October revision, the Dutch NCSC described exploitation as more complex than initially assessed and its known possible overseas incident as unconfirmed. It still advised prompt patching. That is a dated assessment, not a claim that exploitation cannot happen.

PHP also disclosed CVE-2026-115560 on 23 October. The earlier releases do not resolve this separate session issue. It requires enabled upload progress plus an unusual change from a configured php_binary or php_serialize session handler to php at runtime. PHP recommends disabling session upload progress pending the next regular fix; applications that never change the handler are outside this documented path. Have the maintainer assess and apply the guidance. PHP's 23 October notice.

A five-step checklist for the person paying the bills

1. Name the systems and the owner. List the website, portal, jobs and vendor-managed services. Record who can update each one. Include anything that is easy to forget because customers never see it.
2. Ask for running-version evidence. Request the actual deployed runtime or vendor package status, the relevant advisory and the date checked. A changed Dockerfile or an update available in a dashboard is not a completed deployment.
3. Agree a controlled update. Confirm recoverable backups, compatibility checks and a rollback plan. Prioritise exposed services. If an immediate fix is impossible, have the responsible engineer document the temporary protection and its limitations.
4. Verify the replacement is doing the work. Check the version after deployment and restart affected workers where required. Exercise login, enquiry, checkout or booking journeys that the business relies on. Record the result.
5. Review signs of trouble and keep watch. Unexpected files, accounts, processes or outbound connections deserve investigation. Preserve evidence when something looks wrong; installing a patch is not evidence that an earlier compromise has disappeared.

I would rather hand a client that short evidence trail than a reassuring screenshot of a green dashboard. “Maintained” should mean somebody can explain what changed and how they checked it.

Tell us what your website or application runs on. We can agree the scope of a review and a maintenance plan, including who owns updates and how completion is reported. We will not declare a system safe from its homepage alone.