--- title: "PHP2Shell and Node2Shell: is your website affected? | Murarum" description: "PHP and Node.js patched critical flaws on 21 October 2026. Which sites are exposed, which versions fix them, and what to ask whoever runs your website." url: https://murarum.ro/en/insights/php-node-vulnerabilities-october-2026 language: en alternate_ro: https://murarum.ro/articole/vulnerabilitati-php-node-octombrie-2026 --- 7 min read · Website maintenance # When PHP and Node.js both had critical vulnerabilities in the same week, who was watching your website? If your website runs on PHP, as WordPress and many other CMSs do, it was exposed to critical vulnerabilities patched on 21 October 2026 until PHP was updated to 8.5.12, 8.4.27, 8.3.36 or 8.2.35\. A Node.js app was exposed only if it decompresses Brotli data an attacker can send; the fix is Node.js 22.23.4, 24.22.1 or 26.12.1\. What decided which sites were protected was whether someone felt responsible for them: the technology mattered less, since PHP and Node.js were patched the same day. By Mircea Muraru · 26 October 2026 Updated 23 October 2026: added PHP's follow-up advisory, CVE-2026-115560. ## What happened on 21 October On 21 October 2026, PHP and Node.js both released security fixes for flaws rated CVSS 9.2, critical, in their CVE records. Researchers and the press call them PHP2Shell and Node2Shell. Those names do not come from the projects: PHP2Shell is used by the security press and vendors, and Node2Shell was coined by Imperva's research team. PHP2Shell covers two vulnerabilities, CVE-2026-109618 and CVE-2026-109619\. Both are memory errors that can let an attacker run code on the server without logging in. PHP says every installation that serves web requests is affected, and the risk is highest on Apache with mod\_php, where the demonstrated attack works before your site's own code runs. PHP 8.1 and older received no fix at all. On 23 October PHP added a smaller follow-up, CVE-2026-115560. Node2Shell is CVE-2026-111497, a flaw in the Brotli decompression library that ships with Node.js. Node.js rates it high. It matters only when an application decompresses Brotli data an attacker controls. Node.js 20 and older get no fix. Why care if your site is only a brochure? Remote code execution means someone else runs their code on your server: they can read form submissions and the database, change your pages, or use the server to attack others. A small site is a target because nobody is watching it. The official notices are on [php.net](https://www.php.net/) and the [Node.js blog](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases). Is anyone exploiting them? PHP and Node.js have not reported exploitation in the wild, and CISA's catalogue of known exploited vulnerabilities did not list any of the three on 23 October. Rapid7 reports it has not observed exploitation in the wild for PHP, but has seen reports of exploitation attempts. That is enough reason to patch this week. ## How to find out if it concerns you ### What to ask your agency or hosting provider - Which PHP or Node.js version runs our site in production today, and was it updated after 21 October? - If it is PHP 8.1 or older, what is the plan to move to a supported version, since no fix was released? - If it is Node.js: does our app decompress Brotli data from outside, for example Express 5.0-5.3 or body-parser 2.0-2.3 accepting Brotli request bodies, fetch() reading Brotli from a server we do not control, or direct use of zlib? A bare HTTP server does not decode Brotli on its own. - Who applies the update, and who confirms it to us in writing? ### Signs that nobody is answering If the question stays unanswered for 24 hours, treat the answer as "nobody". The same goes for replies that bounce between parties: the agency says the host updates PHP, the host says the version is the customer's choice. Other signs: nobody can tell you the version, the server access is in the name of a developer who left, or the last change to the site was the launch. If the site depends on one agency's accounts, read [how to choose a CMS without agency lock-in](https://murarum.ro/en/insights/choose-a-cms-without-agency-lock-in). ## What we did: there from the start, transparent with every client Three things mattered more than the exact hours: we were there from the first day, we told every client plainly where they stood, and the problem got fixed. For every platform we had built or knew, with or without a contract, we followed the same order: 1. Inventory. We listed which client platforms run PHP and which run Node.js, and the exact version in production. For the Node.js apps we checked whether the code decompresses Brotli data from outside. 2. A message to every client, in business language: what happened, whether their site is exposed, what we propose and what we need from them. 3. Where the exposure was real and the patch could not go in at once, we proposed a maintenance window until it could. 4. We applied the patches, or asked the hosting provider to, and tested the key flows: forms, logins, payments. 5. We confirmed in writing to each client: the version before, the version after, and what we checked. The result: every exposed platform we look after was updated, and every client knew at each step what was happening, what it meant for their business and what came next. Nobody had to ask us whether they were affected. Our own site runs on Next.js and Node.js. The day after the release we moved production to Node.js 22.23.4 and Next.js 16.4.2, and checked that our code does not decompress Brotli request bodies. Here is a model message you can adapt and send to your own customers or ask your agency to send you: > On 21 October, PHP and Node.js released fixes for critical vulnerabilities that can let an attacker run code on the server. Your site runs on \[PHP / Node.js, version\]. It \[is / is not\] exposed. We propose to update it on \[date\], with \[no downtime / a short maintenance window\]. If the update cannot be done today, we recommend keeping the site in maintenance mode until then. We need your approval \[and access to the hosting account\]. We will confirm in writing when it is done, with the version before and after. ## Why we did it for clients without a contract Some of the sites we checked were delivered as projects, with no maintenance agreement after launch. We checked them anyway, because when it is about their site, we are their agency. The client does not know which version of PHP runs under their contact form, and should not have to. The uncomfortable part: this works on goodwill. It depends on us having the time that week, on still having access, and on the client answering quickly. It is not a model anyone can rely on, which is exactly why [maintenance](https://murarum.ro/en/approach/maintenance) exists: a written agreement that someone watches the stack, with a reaction time agreed in advance. ## Putting the site into maintenance mode is a business decision Taking a site offline until it is patched has a cost: hours without enquiries, orders or bookings. Leaving an exposed site online has a different cost: customer data, a defaced site, a server used to attack others, and the conversation with customers afterwards. A developer can tell you whether you are exposed. Whether to switch off is for whoever owns the business. Fifteen minutes and these questions are enough: 1. Is the site exposed? For PHP, yes, until it runs a fixed version. For Node.js, only if it decompresses Brotli data from outside. 2. Can the patch go in today? If it can, patch it and skip the maintenance window. 3. What does the site hold: forms with personal data, customer accounts, payments? 4. What does one day offline cost: enquiries, orders, bookings you can name? 5. Can a static page with your phone number and email replace the site for a day? 6. Who decides, and who tells customers? If the site is exposed, holds customer data and cannot be patched today, a static page for a day usually costs less than the alternative. ## What a maintenance contract should contain So that next time you do not depend on goodwill, the contract should state: - A reaction time for critical vulnerabilities, written down and agreed for your site. - Who watches security advisories for your exact stack: language, framework, CMS and main dependencies. - Planned major version updates, so you never sit on a version that no longer gets fixes, as PHP 8.1 and Node.js 20 did this week. - A tested backup: how often it runs, where it is kept and when a restore was last tried. - One named person you can call. Some things are not worth paying for: a bundle of support hours that resets every month with no record of what was checked; round-the-clock on-call for every small issue on a presentation site; and automatic updates of everything, untested, which trade one risk for another. Our levels are on the [maintenance](https://murarum.ro/en/approach/maintenance) page. Platforms we build under [product development](https://murarum.ro/en/services/product-development) are handed over with documentation and accounts in your name, so whoever maintains them can work from that. ## Ten questions for your website this week 1. Which PHP or Node.js version runs our site in production today? 2. Was it updated after 21 October 2026, and to which version? 3. If it is PHP 8.1 or older, or Node.js 20 or older, when do we move to a supported version? 4. If it is Node.js, does the app decompress Brotli data from outside? 5. Who watches security advisories for our stack, by name? 6. Who has the access to update the server, and is that account in our company's name? 7. When did the last backup run, and when was a restore last tested? 8. Is a reaction time for critical vulnerabilities written down anywhere? 9. Who decides on maintenance mode, and who tells our customers? 10. If our agency stopped answering tomorrow, could someone else take over from the documentation and accounts we hold? ## Frequently asked questions ### Is my WordPress site affected by PHP2Shell? WordPress runs on PHP, and PHP says every installation serving web requests is affected until it runs 8.5.12, 8.4.27, 8.3.36 or 8.2.35\. PHP 8.1 and older received no fix, so a site on those versions needs a move to a supported version. Ask your host or agency which version runs in production. ### Is my Node.js app affected by Node2Shell (CVE-2026-111497)? Only if it decompresses Brotli data an attacker can control: Express 5.0-5.3 or body-parser 2.0-2.3 accepting Brotli bodies, fetch() reading Brotli from an untrusted server, or direct use of zlib. A bare HTTP server does not decode Brotli on its own. Update to 22.23.4, 24.22.1 or 26.12.1 either way; Node.js 20 and older get no fix. ### Are PHP2Shell and Node2Shell being exploited? PHP and Node.js have not reported exploitation in the wild, and none of the three CVEs was in CISA's known exploited vulnerabilities catalogue on 23 October 2026\. Rapid7 reports it has not observed exploitation in the wild for PHP, but has seen reports of exploitation attempts. ### Is there a workaround if I cannot update PHP right away? PHP lists settings that reduce the risk, such as session.upload\_progress.enabled=0, which it also recommends for the follow-up CVE-2026-115560, with every worker restarted afterwards. PHP says there is no complete mitigation and updating is the only safe choice. Node.js gives no workaround for its flaw. ### Who is responsible for my website's security after launch? Whoever your contract names. Without a maintenance contract it is often nobody: the agency delivered a project, the host keeps the server running, and the PHP or Node.js version in between belongs to no one. A maintenance contract names a person and a written reaction time. [Still have questions? Write to us](https://murarum.ro/en/contact) ## Related - [Product Development](https://murarum.ro/en/services/product-development) - [All case studies](https://murarum.ro/en/work) [A reference-grade website for a white-collar defense firm](https://murarum.ro/en/work/georgescu-gont-website): Georgescu & Gonț · Criminal defense law · 2023 [A speaker management platform for Eventer.NET](https://murarum.ro/en/work/eventer-app): Eventer.NET · Medical congresses and events · 2026 ## Who would have patched your site on Wednesday? If your site was delivered as a project and you do not know who would have patched it on Wednesday, give us 20 minutes and we will tell you which versions it runs. [Let’s talk](https://murarum.ro/en/contact) [office@murarum.ro](mailto:office@murarum.ro) ## Contact - Email: office@murarum.ro - Phone: +40 761 339 149 - Let’s talk: https://murarum.ro/en/contact