PHP and Node.js CVEs of 21 October 2026: The Full List and How Our Engineers Guard Our Sites

On 21 October 2026 the PHP and Node.js projects both released security updates. Below is a summary of their official announcements, with the CVE numbers so they are easy to search for and to match against the systems you run.

PHP: two critical flaws

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): memory corruption after PHP runs out of memory, which can lead to remote code execution. CVSS v4 score 9.2, severity Critical.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): global state from one request carries over into the next, which can also lead to remote code execution. CVSS v4 score 9.2, severity Critical.

PHP versions below 8.2.35, 8.3.36, 8.4.27 and 8.5.12 are affected. The fix is in those four versions.

Node.js: ten CVEs, four of them High

• CVE-2026-111497 (High): an out of bounds write in the Brotli decoder that can lead to remote code execution.
• CVE-2026-105482 (High): dns.resolve truncates host names that contain a NUL character.
• CVE-2026-105483 (High): the TLS certificate host name check can be bypassed when the IP is written with full width digits.
• CVE-2026-106069 (High): the TLS certificate host name check can be bypassed when the host is read loosely as an IP address.
• CVE-2026-105481, CVE-2026-106072, CVE-2026-106074 (Medium): keep-alive sockets, certificate validation for non canonical IPv4 addresses, and random values that repeat across snapshots.
• CVE-2026-106070, CVE-2026-106071, CVE-2026-106073 (Low): ZipFile, and two flaws in the Permission Model.

The fix is in Node.js 22.23.4, 24.22.1 and 26.12.1. The release also updates OpenSSL, c-ares, Undici, SQLite and the CA certificate list (after the withdrawal of the eMudhra intermediate certificate). Node.js 20 is not part of this release.

What we found when we checked: the PHP and Node.js services on our main production server already run on versions that contain the fixes. We checked it directly on the running server, not from configuration notes.

If you run your own servers: run php -v and node -v and compare them with the versions above. Packages from a Linux distribution often keep the old version number after a fix is applied, so also check your package provider's security notes. If your application runs in a container, rebuild the image so it pulls the new base, instead of only changing the version number.

Official sources: Node.js Security Releases, 21 October 2026, advisory GHSA-w8hw-w9fx-j79w and advisory GHSA-6wmf-4rv5-p3rp.

CVE stands for Common Vulnerabilities and Exposures, a public list of security flaws. Every known flaw gets one unique number, in the form CVE-year-number, so everyone in the industry talks about the same flaw.

Almost every CVE is also given a severity score from 0 to 10. A high score does not automatically mean our sites are in danger. Two things decide that: whether we use the affected part, and whether that part can be reached from the internet. So the first question our team asks when an announcement lands is always the same: are we affected, and can it be reached from outside?

Both run millions of sites, which makes them attractive to attackers: one flaw can be tried against thousands of targets at once. Both also have very large package ecosystems. One package we install usually brings dozens of others with it, so a flaw can come from a library we never chose ourselves.

On top of that, a website is open to the internet 24 hours a day. A flaw that has not been patched can be tried at any time, including midnight and weekends.

We follow the same order every time, so no step is skipped when we are in a hurry:

1. Read the announcement and understand which part is affected.
2. Check whether we use that part. Because our versions are locked, the answer comes quickly instead of being a guess.
3. Raise the version as a single change of its own.
4. Run the automated tests.
5. Send it to production through the same path as every other change.
6. Check directly that the new version is really running on the server, instead of trusting a "success" report.
7. Write down what changed, so the next person knows.

Patching is only half the story. The other half is building a system that stays safe even when the patch does not exist yet. That is what the next six habits do.

Every runtime and component is written down with an exact version. If a version can change silently, we do not know exactly what is running, and we cannot answer the most important question when a flaw is announced: are we affected?

Locked versions also make our work repeatable. A build today and a build next month use exactly the same parts, so no change slips in without us noticing. If an update causes trouble, we know exactly which version to go back to.

When PHP, Node or a component beneath them ships a security fix, we raise the version as a single change of its own. It is never bundled with a new feature, so if something goes wrong the cause is clear and the change is easy to undo.

A real example: when one of our server components shipped a security release, we installed it without carrying any other change, ran the whole test suite, and shipped it. One change, one reason.

Three kinds of attack are the ones we guard against most. Injection, which slips commands in through form fields. Cross site scripting, or XSS, which plants a script in a page that other people will view. And SSRF, which tricks our server into reaching its own internal addresses.

So form entries, links, uploaded files and addresses typed by users are checked before they are stored. Content is cleaned of harmful scripts when it is saved, and every outgoing request to an address a user can influence passes a guard that refuses internal destinations. This layer protects us even when a new flaw is announced and its patch is not yet available.

The principle: if something leaks, limit how far the damage goes. Everyone holds only the permissions they need. Editors prepare drafts, only authorised people can change what is live, and sensitive settings are for admins only.

Integration keys and other secrets are stored encrypted, can only be written and never read back through the system, and are never written to logs or error messages. Changes that affect what is live also leave an audit record.

Many attacks start with something crude: looking for secret files such as copies of configuration or backups, probing the login pages of other systems, trying to sneak in through the address, slipping in commands, using scanners and attack tools, or flooding the site with requests.

Requests like that are refused or slowed down before they reach the application. Every visitor has a budget of requests per minute. When a flood is detected, the site can switch by itself to a browser check for one hour, then return to normal. Everything is visible on a dashboard, so we know what is trying to get in.

Errors in production go straight into monitoring, so problems are visible right away and not a week later from a user complaint. Our releases are small and frequent, so every change is easy to understand.

The previous version stays available. If a change turns out to be a problem, we can pull it back quickly, without rewriting anything under pressure.

Every security rule we write has an automated test. If a change accidentally loosens it, the build fails before it reaches production. That way protection that already exists does not quietly disappear when the code changes.

As a partner or customer you do not need to change anything. What you feel is a site that stays fast and available, and data that does not end up in the wrong hands. All the habits above exist so that you never have to think about it.

No system is immune, and new flaws will keep appearing. What we can do is shorten the distance between an announcement and a patch, limit the damage when something gets through, and be honest about what we know.