PHP2Shell: the fix is a runtime upgrade, not a code change

On October 21, 2026, PHP released 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to close two critical remote code execution flaws in the PHP runtime. Both are rated CVSS v4.0 9.2. Together they go by the name “PHP2Shell.”

The flaws sit in PHP itself, not in any application built on it. A secure codebase running on an affected PHP build is still exposed. That makes this an inventory problem first and a patching problem second.

What happened

The first flaw is CVE-2026-109618, remote code execution via out-of-memory corruption. The second is CVE-2026-109619, remote code execution via stale global state. Both let an unauthenticated attacker run code as the web worker account. PHP’s advisories also describe memory disclosure from the worker process. That can expose tokens, keys, and session data from other requests.

PHP had scheduled the release for October 22. Details leaked on October 20, and the project pulled the release forward a day, per The Hacker News. Researchers at Wiz, Calif, and OpenAI reported the flaws. The vulnerable code had been in PHP for more than a decade.

Exploitation has already started. watchTowr reports attempts observed through its honeypot network as of October 21, and Cloudflare’s CTO said early attacks were emerging. No confirmed compromise has been reported. Neither CVE is in the CISA Known Exploited Vulnerabilities catalog as of this writing. Some organizations, including BambooHR and several Dutch government services, took systems offline as a precaution, per The Hacker News.

Who is exposed

According to the PHP security advisory, every PHP installation that serves web requests is affected. That covers PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. PHP rates mod_php as the highest risk. There, a demonstrated exploit runs from a single unauthenticated request before any application code executes.

Affected versions are everything below 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP 8.1 and older no longer receive releases from the PHP project. The security team published minimal source backports for PHP 7.4, 8.0, and 8.1 instead. PHP 8.2 reaches end of life on December 31, 2026.

One detail matters for anyone running distribution packages. Linux distributions and LTS vendors received the patches in advance, so a fixed package can carry an old-looking version number. Check the package changelog for the CVE IDs rather than the version string.

Why this is an inventory problem

The fix is a new PHP runtime, not a code change. Updating an application such as WordPress or Laravel does nothing for the PHP underneath it. The runtime comes from the server package, the hosting provider, or the container base image. In most organizations, a different team owns each of those.

Container images are where PHP hides best. An official php:8.3-fpm base image, a distribution package in a custom image, or a vendor appliance image all carry PHP. Nobody lists that build as a dependency. Most AppSec programs inventory application packages well and base-image runtimes less well. This week that gap is the exposure.

How to find it and fix it

• Inventory every PHP runtime. Scan container images for PHP packages and base-image tags. Check hosts and virtual machines for installed PHP packages. Ask hosting and PaaS providers which version they run. Include internal tools and admin panels, not only customer-facing applications.
• Upgrade to a fixed version. Move to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or to a distribution package with the fix. Rebuild container images from a patched base image rather than patching running containers.
• Restart everything that runs PHP. The advisory calls for restarting Apache, PHP-FPM, and any long-running PHP workers after the update.
• Treat mitigations as a stopgap only. PHP lists configuration changes that reduce exposure to specific attack paths. It states plainly that they do not make an installation safe. Use them while you schedule the upgrade, not instead of it.
• Review memory settings after patching. The fix adds a new hard memory limit that ends the process when reached, per The Hacker News. Confirm memory_limit and post_max_size still match what your applications need.
• Check for earlier exposure. If a system was exposed before you patched, review the logs. The researchers point to unusual multipart requests followed by memory-limit errors, repeated HTTP 500 responses, and unexplained PHP worker restarts.

Where Mend.io covers it

Our container scanning checks the images in your registries and pipelines and reports the operating system packages inside them. That includes the PHP packages in a base image. You get the list of images carrying an affected build without opening each Dockerfile.

Mend SCA flags the two CVEs where PHP appears as a scanned component in your projects. The finding lands in the same prioritization and remediation workflow as the rest of your open source risk.

Mend Renovate opens pull requests to update Dockerfile base-image tags when a new image version publishes. The move from an affected PHP tag to a patched one arrives as a reviewable PR in the repositories that own those images.

Mend.io answers the first question every team is asking this week. Which of our images and hosts run an affected PHP build, and where do we fix them?