PHP, Node.js and Go patched critical flaws in the same week: what happened and how not to fall behind

Between October 19 and 21, 2026, three languages that power a large share of web systems published security updates. If your system runs PHP, Node.js or Go, the short answer is: update today, and start with PHP.

People called it a "hack", but what happened is more specific: critical flaws were published and, in PHP's case, attack attempts started before a patch existed. As far as the official advisories go, there are documented attempts but no confirmed compromise. It's not worth waiting for that to change.

The summary in one table

PHP: the one that can't wait

Both flaws have the same effect, remote code execution, and different origins:

• CVE-2026-109618: if a request exhausts memory_limit at just the wrong moment, PHP can be left with half-initialized internal data and later treat it as valid.
• CVE-2026-109619: a fatal error can leave internal state pointing to memory that has already been freed, and the next request handled by the same worker uses it.

They reach any PHP installation serving web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest with mod_php, where the project itself demonstrated an exploit in which an unauthenticated request triggers the attack before any application code runs. The php.net advisory is explicit: there are no complete mitigations, and updating is the only safe choice.

The timeline explains the urgency:

• October 17: Amazon spots the first exploitation attempt on a honeypot, four days before the patch.
• October 21, 14:00 UTC: the embargo lifts. The same day several proofs of concept appear, and Amazon records attempts from different infrastructure, which suggests more than one actor.
• October 23: PHP publishes an informational advisory (CVE-2026-115560) recommending that session.upload_progress.enabled be turned off until the next release.

Two details that are easy to miss. PHP 8.1 and older no longer receive updates, and PHP 8.2 reaches end of life on December 31, 2026: if you're there, now is the time to plan the migration. And on October 26 rebuilt Windows builds shipped with Brotli 1.2.1, for a flaw we'll get to in a moment.

Node.js: ten flaws in a single release

On October 21 Node.js fixed ten vulnerabilities across the 22, 24 and 26 lines. Four are high severity: the Brotli decoder in node:zlib (an out-of-bounds write that allows remote code execution), two TLS hostname checks that can be bypassed, and a DNS resolution that truncates names containing NUL characters. The rest are medium or low severity.

They also updated the certificate bundle because of the compromise of an eMudhra intermediate CA, along with several dependencies: c-ares, OpenSSL, SQLite and Undici.

A common trap: npm update does not update Node.js. What you have to change is the runtime or the container image. And unsupported release lines are treated as affected in every security release.

Go: the quiet one, but not a minor one

Go 1.26.10 and 1.27.3 shipped on October 19 with security fixes in crypto/x509. The detail: the standard library adds a denylist so that Certificate.Verify returns an error for certain known intermediate certificates that are no longer trusted. It affects versions before 1.26.10 and 1.27.x releases before 1.27.3. Everything points to this being the same intermediate-CA episode Node.js mentioned.

Two things to keep in mind. Eleven days earlier, on October 8, other security fixes had already shipped (in the go command and in crypto/tls, net/http, html/template and other packages), so this is not an isolated event. And Go compiles static binaries: updating the compiler on your machine does not change what runs in production. You have to rebuild and redeploy.

One component, two ecosystems

The identifier CVE-2026-111497 shows up in both the Node.js and the PHP advisories. It's an out-of-bounds write in Brotli decompression. In Node.js it lives in the node:zlib decoder; in PHP's Windows builds it can be reached through the cURL extension when automatic response decompression is enabled, something cURL ships disabled by default but that applications and HTTP libraries can turn on.

The lesson is uncomfortable: vulnerabilities travel through dependencies. Watching the language alone isn't enough.

Does it affect us?

The first thing we did is what we suggest you do: ask what runs, where, and in which version. For the site and its contact form, the answer is this:

• The site you're reading is static pages served by nginx. There is no PHP or Node.js running to display them.
• Node.js is used only to build the site. It doesn't stay running in production.
• The contact form backend uses PHP and is already on a fixed version: we checked the version the server reports.
• Go: the site has no Go components.

We took the chance to close two doors. We stopped reporting the PHP version in responses, because attackers look for specific versions, and we turned off session.upload_progress, which we don't use and which is the feature the October 23 advisory mentions.

How a constant service prevents this

A patch isn't an event: if it depends on someone remembering, it arrives late. What works is a routine with owners, and that's what we mean by a constant service:

1. A living inventory. Which language, which version and which dependencies each service runs, in one place. This week's question was "which version runs where?". If answering it takes days, you've already lost ground.
2. Official advisories, not headlines. We follow php.net, the Node.js security blog and go.dev, and we don't wait for the news to reach social media.
3. Two speeds. Hours for a critical flaw under active attack, like this one; a weekly window for the rest. Amazon recommends measuring patch timelines in hours, not days, for internet-facing systems.
4. Rebuild, don't just update. Containers and binaries don't update themselves: you have to rebuild the image and redeploy.
5. Less surface. Don't expose versions, turn off what you don't use and, in front of everything, an application firewall that buys time. But PHP says it plainly: buying time is not the same as being fixed.
6. An end-of-life calendar. PHP 8.2 expiring on December 31 has already been announced. Planning for it avoids an urgent migration.
7. Look backwards. Amazon recommends starting your log review from October 17, not from the 21st, and searching for the string PHP_SESSION_UPLOAD_PROGRESS in form uploads.

None of this is sophisticated. The hard part is keeping it up week after week, with someone who owns the topic, a calendar and a record of what was done.

---

If you want to know which versions you're running and what's missing, tell us which systems you use and we'll review them together. To see how we handle day-to-day operations, take a look at our cloud infrastructure and DevOps solution.

Sources

• PHP security advisory of October 21 and 2026 announcements archive
• PHP Foundation: today's PHP security release and how we're strengthening PHP security
• Amazon Threat Intelligence: PHP2Shell exploitation prior to public disclosure
• Node.js: October 21, 2026 security releases
• Go release history and GO-2026-6809