PHP2Shell and the Node.js Brotli Flaw: A Practical Response Guide for Organizations

On October 21, 2026, PHP and Node.js each released emergency security fixes. Many organizations run one or both. This guide explains the fixes in plain terms and sets out what to do, in order.

What was fixed

PHP: two critical flaws, together called PHP2Shell

• CVE-2026–109618 and CVE-2026–109619, each rated 9.2 on the CVSS v4.0 scale (critical).
• Both can allow remote code execution without logging in. An attacker sends specially built web requests, and their commands run on your server.
• CVE-2026–109618 comes from out-of-memory handling. When a request pushes PHP out of memory at the wrong moment, PHP leaves internal data half-prepared and later treats it as valid.
• CVE-2026–109619 comes from leftover state. Data from one request survives after its memory is freed, and a later request handled by the same worker uses it.
• PHP states that updating is the only complete fix.

Node.js: ten flaws, four rated high

• CVE-2026–111497: an out-of-bounds write in the Brotli decoder that permits remote code execution.
• CVE-2026–105483 and CVE-2026–106069: TLS certificate hostname verification bypasses.
• CVE-2026–105482: dns.resolve truncates names that contain a NUL character.
• The release also updated bundled components, including c-ares, Undici and OpenSSL.

Check whether you are affected

1. List every place PHP and Node.js run. Include web servers, container images, build servers, staging systems, internal tools, and any third-party product that bundles either runtime, such as a CMS or shop platform.

2. Compare your versions with the fixed ones.

• PHP fixed versions: 8.2.35, 8.3.36, 8.4.27, 8.5.12.
• PHP with no official fix: 8.1 and earlier, which are end of life.
• Node.js fixed versions: 22.23.4, 24.22.1, 26.12.1.
• Node.js with no official fix: Node.js 20 and earlier, which are end of life.

3. Know where the risk is highest.

• Any PHP installation that serves web requests is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Apache with mod_php is the highest risk. Full code execution has been validated there on default settings, so patch those servers first.
• For Node.js, the Brotli flaw matters wherever your code decompresses Brotli data from a source you do not control. That includes servers that accept Brotli-compressed request bodies, and any application using the built-in fetch() to call outside services, because it decodes Brotli responses automatically. You can be exposed without ever writing "Brotli" in your code.

4. Do not trust version numbers alone. Linux distributions often fix PHP and Node.js without changing the upstream version number. For PHP, confirm the fix in the package changelog:

apt changelog php8.3-cli | grep -E "CVE-2026-109618|CVE-2026-109619"
rpm -q php-cli --changelog | grep -E "CVE-2026-109618|CVE-2026-109619"

apt changelog php8.3-cli | grep -E "CVE-2026-109618|CVE-2026-109619"
rpm -q php-cli --changelog | grep -E "CVE-2026-109618|CVE-2026-109619"

For Node.js packages from a distribution, follow that distribution's own security notice.

What to do in the first 24 hours

1. Patch internet-facing systems first, starting with Apache servers running mod_php.
2. Restart after updating. PHP workers, Apache and every Node.js process keep running the old code until they are restarted.
3. Rebuild and redeploy container images. Updating the host does not change the runtime inside an image.
4. Verify the result: run the changelog check for PHP, and compare node -v on each host and inside each container with the fixed versions above.
5. If a hosting provider or vendor manages the server, ask in writing whether the fix has been applied and when.

If you cannot patch yet

Unsupported versions. PHP 8.1 and earlier and Node.js 20 and earlier get no official fix. In order of preference:

1. Upgrade to a supported version.
2. Use a fix backported by your Linux distribution or a long-term support vendor, and confirm the CVE numbers appear in the package changelog.
3. Reduce exposure and plan the upgrade. Some advisories recommend taking unpatched internet-facing systems offline.

PHP temporary measures. These reduce exposure to specific attack paths. They do not make a system safe.

For CVE-2026–109618:

• If the application does not use multipart form data, block multipart/form-data requests at the front end, before they reach PHP. This breaks file uploads and any form sent as multipart, so test checkout and login flows.
• Set memory_limit=-1 in a way applications cannot override, such as php_admin_value in the FPM pool or the Apache configuration. Restart every worker, and check that no pool, directory or application setting restores a finite limit. A single request can then use all available memory, so enforce a limit at the server or container level.

For CVE-2026–109619:

• Set session.upload_progress.enabled=0 in php.ini, the FPM pool or the server configuration, and restart every worker. Do not rely on ini_set() or .user.ini. This blocks the confirmed session paths, not every variant.
• On PHP 8.5, set fatal_error_backtraces=0 and restart every worker.
• Remove invalid or deprecated settings applied per request that produce warnings. Hiding warnings with error_reporting, display_errors or @ does not help.

Some mitigation lists shared on social media recommended turning off upload progress alone. That setting blocks only some attack paths, so treat it as one step and keep working toward the update.

Node.js. The advisory lists no workaround. The fix is the update.

Check whether you were already hit

• The PHP2Shell details leaked on October 20, a day before the fix. On October 21, CISA said it had not observed exploitation. By October 22, several security companies were reporting exploitation attempts in the wild. Treat unpatched systems as actively targeted.
• The University of Toronto advisory recommends treating any internet-facing system that stayed unpatched from October 20 onward as potentially compromised until it is checked.
• Review web server and PHP error logs for unusual multipart requests, out-of-memory errors and worker crashes.
• Check web roots and upload directories for new or modified files.
• Look for unexpected outbound connections and new scheduled tasks from application hosts.
• If you find signs of compromise, rotate the credentials and secrets stored on that system and rebuild it from a known-good image.

Practical advice for organizations

• Rank by exposure, not by CVSS alone. Two systems on the same vulnerable version are not equally urgent. Internet-facing systems, systems handling untrusted uploads, and systems holding sensitive data go first.
• Agree a patch time limit before you need one. For a critical remote code execution flaw on an internet-facing system, many teams set a target of hours, not weeks. Decide in advance who can approve an emergency change.
• Test temporary controls before relying on them. Blocking multipart requests at the edge can quietly break checkout or login. Run one test transaction after every change.
• Limit what a compromised web server can do. Run PHP and Node.js under unprivileged accounts, restrict outbound connections from application hosts, and keep secrets out of web-accessible directories. If code does run, the damage then has a ceiling.
• Use immutable, rebuildable images. Teams that can rebuild and redeploy a container in minutes recover faster than teams patching hosts by hand.
• Ask your vendors. Software you buy often bundles PHP or Node.js. Ask each vendor which version it ships and when a fix will arrive.
• Treat end-of-life runtimes as a recorded business risk. Put them in the risk register with an owner and a retirement date.
• Keep a record. Write down what was affected, when it was patched, who approved the change, and what temporary measures remain, with a date to remove them.

Hear about the next one early

Both projects gave advance notice. The Node.js project typically publishes a notice before a security release, stating the affected release lines and the highest severity. On October 20, PHP announced that two critical vulnerabilities would be fixed on October 21 at 14:00 UTC. The details leaked the same day, so the time between the warning and the first attacks was short.

A small, defined watch function closes that gap. It can be one person, a small team, or a service you pay for.

• Keep a living inventory of the languages, runtimes, frameworks, libraries and vendors you depend on, with versions. Without it, a headline cannot be matched to your systems.
• Follow primary sources: the official security pages and mailing lists of what you run (for example, nodejs-sec for Node.js and php.announce for PHP), your distribution's security notices, national CERT advisories, and the CISA Known Exploited Vulnerabilities catalog.
• Triage within hours: does this affect a component we run, how exposed is it, and who must act?
• Define the path to action: who approves an emergency change, who rebuilds and deploys, and how success is verified.
• Rehearse. Pick a past advisory and test how fast your team could have responded.

Response checklist

1. Inventory PHP and Node.js, including containers and bundled copies.
2. Patch internet-facing systems first.
3. Restart services and rebuild container images.
4. Verify the fix through the changelog or version check.
5. Upgrade, backport or isolate end-of-life systems.
6. Review logs and web roots from October 20 onward.
7. Record every temporary measure with a removal date.
8. Name an owner for watching security advisories.

Glossary

• CVE: a public ID for one specific vulnerability.
• CVSS: a 0 to 10 severity score; 9.0 and above is critical.
• Remote code execution (RCE): an attacker runs commands on your server over the network.
• End of life (EOL): a version its maintainers no longer fix.
• WAF: a web application firewall that filters requests before they reach your application.