Critical PHP and Node.js vulnerabilities: what happened and what to do

Two major security announcements landed together on October 21. That day, the maintainers of PHP and Node.js, two of the technologies a large share of the web is built on, released new versions to fix serious flaws. In both cases the worst-case scenario is the same: someone on the outside, with no username or password, manages to run instructions on the server.

If you are not sure what a vulnerability is or what a severity score means, this article explains it from scratch. Here we stick to the specifics: what happened, who it affects and what to do.

What happened with PHP?

PHP is the language behind most websites that run code on a server, including every WordPress, Drupal and Joomla site and many online stores such as WooCommerce or Magento. If your site has a traditional content management system, it almost certainly runs on PHP.

The flaws are tracked as CVE-2026-109618 and CVE-2026-109619, and the industry already calls them PHP2Shell. They are rated 9.2 out of 10 and let someone send the site a deliberately crafted request and, with it, take control of the process handling it. The most delicate part is that they have nothing to do with your theme, your plugins or the code written for you: the flaw is in PHP itself, and in some setups it is triggered before your application even starts running.

They affect practically every PHP version in use, from 5.4 to 8.5. Public attack code appeared shortly after the announcement, and on October 26 the US cybersecurity agency (CISA) added them to its catalog of actively exploited vulnerabilities. The FBI went as far as recommending that systems which could not be updated immediately be taken offline.

Which PHP versions fix it?

• PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, or later.
• For 7.4, 8.0 and 8.1, which no longer get regular updates, limited patches were published that your provider has to apply on their side.
• Older versions (7.3, 7.0, the 5 branch) have no official fix. If your site still runs on one of them, the only safe way out is to migrate.

If your site is on shared hosting, the PHP version is controlled by the provider. Many have already updated, but it is worth confirming in the control panel or asking them directly, because some keep old versions running so as not to break legacy sites.

What happened with Node.js?

Node.js is the technology behind many modern web applications, APIs and internal systems, as well as much of the tooling used to build today’s websites. On that same October 21, Node.js fixed ten flaws across all its supported versions.

The most serious, CVE-2026-111497, lies in how Node.js decompresses data in the Brotli format. Brotli is a compression scheme used on the web so pages and data weigh less in transit; Node.js decompresses it automatically, for example when your application calls another service on the internet. A deliberately malformed compressed payload can corrupt memory and, in the worst case, allow code to run. Node.js classifies it as high severity, and Google, which maintains the Brotli library, scored it 9.2 out of 10. On October 27, CISA added this flaw to its catalog of exploited vulnerabilities as well.

Several of the other nine concern how certificates and domain names are verified. In plain terms: ways of tricking an application into trusting a server it should not trust.

Which Node.js versions fix it?

• Node.js 22.23.4, 24.22.1 and 26.12.1, or later.
• Unsupported versions, such as Node.js 20 and earlier, do not get the fix.

One important detail: updating Node.js on a developer’s laptop does not update the server. If the application is deployed in containers or prebuilt images, they need to be rebuilt with the new version. And other software that ships its own copy of Brotli may need its own update.

Is my website affected?

A few quick questions to find out:

• Is your site WordPress, a WooCommerce store or any traditional content management system? Then it runs on PHP, and the question is which version. You will find it in your hosting control panel or in WordPress’s Site Health section.
• Do you have a custom application, a customer portal or an API? It may be built on PHP or Node.js. Whoever maintains it should be able to tell you the exact version in a minute. If nobody can answer, that is a signal in itself.
• Is your site static? Sites generated ahead of time and published as files (like this one) do not run PHP or Node.js when visitors arrive, so the risk is much lower. Even so, the environment where they are built should be updated.

To see which technology can be detected from the outside, run your address through our website technology checker. If the result shows the exact PHP version, for instance through an X-Powered-By header, the programs that hunt for vulnerable servers can see it too. Hiding it is one of the measures covered in our guide to HTTP security headers.

What to do this week

1. Take inventory. Note which parts of your digital presence use PHP or Node.js and which version: the website, the store, the customer portal, the integrations.
2. Update to the fixed versions. Ideally you test on a copy first, but with flaws this severe the testing window is measured in hours or days, not weeks.
3. If you cannot update yet, ask your provider to apply the temporary mitigations published for PHP. They reduce the risk but do not remove it: only the update closes it completely.
4. Look for unusual activity since October 21: new admin users, modified files, pages you do not recognise, spikes in outgoing email. If something does not add up, treat it as an incident, not a curiosity.
5. Set a date to migrate whatever is out of support. PHP 7 or Node.js 18 will not get the next patch, and there will be a next one.

Why does this keep happening?

Because that is the nature of software. PHP and Node.js are mature projects reviewed by thousands of people, and serious flaws still turn up. That they get found and fixed is good news; what makes the difference is how long each website takes to receive the fix.

The businesses that got through these weeks calmly have one thing in common: someone already knew which versions they were running, read the announcement the same day and applied the patch with a record of what was done. That is exactly the job of our ongoing support and evolution service: watching the security advisories for what you use, applying updates with method, checking that backups actually restore and alerting you before a customer notices.

And if the review leaves you with a platform on versions that are no longer supported, legacy system modernization is the way out without losing what works. If you would like us to look at your case, get in touch and we will tell you where you stand.