PHP2Shell: What It Is and What to Do Today

PHP has been one of the workhorses of the web for a long time. Nearly 75% of websites run on it, and that number doesn't count the intranets, storefronts, and vendor products running PHP behind the scenes in most enterprises. That reach is what makes this week's news so serious.

Today, the PHP team disclosed and patched two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, known together as PHP2Shell. Both can allow attackers to execute code remotely without authentication. Patches are available, and you should treat this as urgent. In this post, we're going to look at what PHP2Shell is, what it means for an enterprise environment, and the steps your team can take today.

What PHP2Shell is

PHP2Shell is a pair of memory-safety bugs in the PHP engine itself. PHP rates both 9.2 on CVSSv4, and the vulnerable code has been sitting in PHP for more than a decade.

The first, CVE-2026-109618, lives in PHP's out-of-memory handling. The engine can be interrupted while internal request data is only partly set up, and cleanup then treats that half-built data as valid. The second, CVE-2026-109619, lets state owned by one request outlive the memory behind it, so a later request on the same worker can pick up that stale state before it gets reset.

The timing is what makes this pair so dangerous. Both bugs trigger while PHP parses an incoming HTTP request, before any application code runs, so frameworks like Laravel and Symfony (or your own input validation) never get a chance to step in. A single unauthenticated request can be enough to run code as the web server user.

Every PHP setup that serves web requests is in scope, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. CERT-EU says versions going back to PHP 5 could be affected.

The disclosure didn't go according to plan, either. The embargo was set to lift on October 22, but CVE details leaked on Hacker News on October 20, and the PHP team pulled its release forward to today. Mass scanning started within hours of the leak, and Cloudflare reported early exploit attempts before the patch even shipped. As of this writing, no one has confirmed a successful break-in, and neither CVE is on CISA's Known Exploited Vulnerabilities list. We wouldn't count on that lasting.

What PHP2Shell means for your environment

If PHP2Shell only touched your main website, patching it would make for a busy afternoon. The challenge is that in most enterprises, PHP runs in far more places than anyone has written down. Could you list every system running PHP in your environment right now, along with who owns it? In most organizations, building that list is a project of its own.

Beyond the obvious candidates, like WordPress and Drupal sites or Magento and WooCommerce storefronts, PHP tends to show up in internal tools such as intranets, time-tracking systems, and older CRM packages. Those apps are often reachable through routing mistakes or supplier connections. PHP also ships inside third-party software and appliances that bundle their own runtime. It sits in container images that haven't been rebuilt in a while, and it keeps running on end-of-life branches like 8.1 and 7.x that won't get official packages.

Once attackers have code execution, they can follow a familiar playbook. They drop a web shell or cryptominer, grab the database and cloud credentials stored on the box, and move laterally from there. PHP2Shell also lets attackers read live worker memory, which can expose passwords, tokens, and API keys from other users' requests without needing code execution first.

As a result, scoping your exposure can take longer than the patch itself. Updating an application like WordPress or Laravel leaves the PHP runtime underneath it untouched. Linux distributions also backported fixes ahead of the release, so a patched package can still report an old version string. Simple version scans will both miss real exposure and flag systems that are already fixed. And tracking down the owner of a ten-year-old intranet app often takes longer than updating it.

The cost of not knowing is already showing up. BambooHR and several Dutch government and education sites took services offline as a precaution while they worked out where they stood.

What to do today

Let's take a look at what your team can do today. Our guidance breaks the response into three steps.

Step 1: Find where PHP runs

Start by finding every place PHP runs, including inside third-party software and appliances, container images, and end-of-life systems. It works a lot like a product recall. The fix itself is simple, but only once you know where every affected unit is. As you build the list, attach an owner to each system, because you'll need them for the next step.

Step 2: Prioritize, coordinate, and verify

Prioritize internet-facing systems first, then work inward. Patching the PHP runtime is the only complete fix, and the PHP team has been clear that no configuration setting fully protects you. Here are the fixed versions for each branch:

Coordinating updates with application owners is usually the hardest part, especially for systems that need a maintenance window or a vendor's sign-off. Once an update lands, restart Apache, PHP-FPM, and any long-running workers, since running processes keep the old code in memory.

Then verify the fixes are actually deployed. Because distribution packages may carry backported fixes under older version numbers, check the package changelog for the CVE IDs instead of trusting the version string.

If you're running PHP 8.1 or older, no official packages are coming. The PHP team published source-only backports for 7.4, 8.0, and 8.1, but the longer-term answer is a move to a supported branch or backports from a commercial LTS vendor.

Step 3: Reduce exposure where you can't patch yet

If you can't patch a system immediately, reduce its exposure by restricting public access. Take the app offline or put it behind a VPN or authenticated edge access, and confirm that attackers can't reach the origin server directly. WAF rules from providers like Cloudflare can help in the meantime. However, they only see traffic routed through them and can miss new variants.

You can also apply the PHP team's recommended temporary mitigations:

• For CVE-2026-109618, set memory_limit=-1, keep post_max_size low, and enforce request-size limits at the web server or proxy.

• For CVE-2026-109619, set session.upload_progress.enabled=0 (plus fatal_error_backtraces=0 on PHP 8.5), then restart all workers.

These reduce risk and buy you some time, but they don't replace patching.

Beyond these three steps, look back for activity from before your fixes went in. Researchers suggest watching for unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses. Oversized PHPSESSID cookies and unexplained worker restarts are also worth a look. On any server that was exposed before patching, rotate the secrets it held, and take the chance to move stored credentials and cloud roles off your web servers.

How Cogent can help

PHP2Shell is a fixable problem once you know where PHP runs, and every step above depends on that first one. You can't prioritize, coordinate, or verify fixes for systems you don't know about. Today, answering "are we affected?" usually means stitching together scanner exports and asset lists, then chasing owners one at a time.

That's where Cogent comes in. When a vulnerability like PHP2Shell lands, Cogent tells you right away whether you're affected, where the vulnerable PHP runs, and who owns each system. Your team can move straight to coordinating and verifying fixes, even before scanners have added coverage.

If your team needs help assessing exposure or planning remediation, reach out to anyone on the Cogent team. We're offering free PHP exposure assessments and remediation consultations to help us all get through this. This will get you in touch with our team and we’ll respond quickly.