PHP2Shell Vulnerability: What IT Teams Must Do Now

If your organization runs a website, a customer portal, an intranet, or any web application built on WordPress, Drupal, Magento, Laravel or custom PHP, you have a patching job this week that cannot wait for the next maintenance window. On October 21, 2026, the PHP project shipped emergency fixes for two critical flaws now known as PHP2Shell, and attackers were already testing them before the patches existed.

This post covers what PHP2Shell is, which systems are exposed, how to confirm you are actually patched (the version number alone will not tell you), and what to do today if you cannot patch yet.

The short answer: PHP2Shell (CVE-2026-109618 and CVE-2026-109619) lets an attacker with no login run code on any server that uses PHP to serve web pages. Update to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, restart every PHP worker, and confirm the fix with your host or vendor. If you are on PHP 8.1 or older, you need a vendor backport or an upgrade, because the PHP project no longer ships fixes for those versions.

What is the PHP2Shell vulnerability?

PHP2Shell is a pair of flaws in PHP itself, not in any one application. Both carry a CVSS v4.0 score of 9.2 and can be exploited by a remote attacker who has no account and no password. Because the problem sits in how PHP handles a request before your code runs, application-level logins, plugins and security settings cannot block it.

• CVE-2026-109618 (out-of-memory corruption): if PHP runs out of memory while it is still setting up a request, the cleanup step later treats half-built data as valid. An attacker can shape that data.
• CVE-2026-109619 (stale global state): leftover state from one request points to memory that has already been freed, and a later request on the same worker can use it. The PHP advisory lists memory disclosure as a confirmed impact, which means passwords, tokens and API keys from other users’ requests can leak.

The code behind these flaws is old. Researchers traced the affected code path back to PHP 5.4, and the researchers say AI models helped turn the long-known weakness into a working exploit in about a week. That speed is the real story: the gap between “bug exists” and “bug is weaponized” is now measured in days.

Which PHP versions and servers are affected?

Every PHP branch before the October 21 releases is affected, and so is every common way of running PHP on a web server. If PHP answers web requests on a machine, assume that machine is in scope until you have confirmed otherwise.

On the server side, Datadog Security Labs lists Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed as in scope. PHP rates mod_php as the highest risk, because a single unauthenticated request can trigger the attack before any application code runs. Researchers also confirmed pre-authentication code execution against specific versions of WordPress, Drupal, Joomla and Magento.

Is PHP2Shell being exploited right now?

Yes. Exploitation attempts began before the patch was public, and they increased on release day. As of October 21, no confirmed break-ins had been publicly reported, but that tends to lag the attacks by weeks.

• October 17: Amazon Threat Intelligence saw an attempt against its honeypot, four days before disclosure. Amazon recommends starting investigations from this date.
• October 20: a working proof of concept video was mistakenly posted, and the PHP project moved its release up a day.
• October 21: Cloudflare reported early attacks and pushed emergency firewall rules; watchTowr reported “active exploitation attempts” against both CVEs; PHP released the fixes at 14:00 UTC.

Canadian organizations felt it on day one. BambooHR took its service offline in the US, Canada and Ireland as a precaution, interrupting payroll for its customers. That is worth sitting with: even if your own servers are clean, the SaaS tools your HR, finance and operations teams depend on may be running PHP too. If you want the background on why pre-patch attacks like this are so dangerous, our explainer on zero-day exploits covers it.

How do you check if you are patched?

Check the PHP version your web server actually runs, then confirm the fix with whoever supplies that PHP build. The version string can mislead you in both directions, so a version number on its own is not proof.

This is the step we see trip teams up most. The PHP version shown on the command line is often not the one the web server uses, and many servers run several versions side by side. Linux distributions and control panels such as cPanel often apply the fix without changing the displayed version number. A server showing PHP 7.4 may be patched by its vendor; a server showing 8.3 may still be on an unpatched build in a forgotten container.

• WordPress sites: in the dashboard, go to Tools, then Site Health, then the Info tab, and open the Server section. Then ask your host in writing whether the October 21 fix is applied.
• Linux packages: check the package changelog for CVE-2026-109618 and CVE-2026-109619, not the version number.
• Containers: rebuild images from patched base images and redeploy. A patched host does not patch a container that bundles its own PHP.
• Vulnerability scanners: Tenable has published Nessus plugin 369483 for this issue; most major scanners have added checks.

What should IT teams do in the next 48 hours?

Find every PHP system, patch the internet-facing ones first, restart the workers, and look back to October 17 for signs of compromise. This is the order we work in with clients, because it closes the most exposure in the least time.

Rotating secrets is the step most teams skip, and it matters here. Because CVE-2026-109619 can leak memory without running any code, an attacker may have read credentials without leaving the usual traces. The same patch-under-pressure problem shows up with firewalls; we wrote about it in FortiGate CVEs and the patch management problem.

What if you cannot patch PHP yet?

Apply the interim settings, put a web application firewall in front of the site, and isolate anything you cannot protect. None of these is a fix. The PHP security team is clear that only updating PHP fully closes the hole.

• For CVE-2026-109619: set session.upload_progress.enabled=0 (and on PHP 8.5, fatal_error_backtraces=0), then restart all workers. WordPress does not use upload progress, so a typical site should not notice.
• For CVE-2026-109618: set memory_limit=-1 at the administrator level so applications cannot override it, keep post_max_size low, and enforce request-size limits at the web server or proxy.
• Web application firewall: Cloudflare has deployed rules for known attack patterns to all customers, including free plans. Set managed rules to block, not just log. Attackers have already changed payloads to get around them.
• Isolation: CERT-EU recommends taking internet-facing applications off public networks until a fix is applied and verified.

What are the signs your server was already hit?

Look for unusual request patterns, early memory errors, crashing workers and, most of all, a web process starting a shell. A successful attack does not necessarily crash anything or change the page, so a site that “looks fine” is not evidence of anything.

• POST requests with an unusually long field name (one documented example was about 3.5 MB) or binary data in a field with no name
• Errors like Allowed memory size ... exhausted with the location Unknown on line 0, meaning the failure happened before any script ran
• Repeated HTTP 500 responses, segmentation faults or unexplained PHP worker restarts
• Unusually large PHPSESSID cookies
• A web server process (for example apache2 or php-fpm) spawning sh or bash, which is the most direct evidence of exploitation

That last signal is why endpoint and server monitoring matters more than log review alone. A managed detection and response service watching process behaviour on your servers will flag a web worker opening a shell within minutes, whether or not anyone knew the vulnerability existed yet.

Does PHP2Shell trigger PIPEDA breach reporting?

It can. If an exposed server held personal information and you find evidence it was accessed, PIPEDA requires you to assess whether the breach creates a “real risk of significant harm.” If it does, you must report it to the Office of the Privacy Commissioner of Canada and notify affected individuals as soon as feasible.

Two details catch Canadian organizations out. First, you must keep a record of every breach for two years, even ones that fall below the reporting threshold. Second, the memory-disclosure side of CVE-2026-109619 means “no code ran” is not the same as “no data left.” If you cannot rule out exposure on a server handling customer, patient or employee data, document your assessment now, while the facts are fresh. Our guide to building an incident response plan walks through how to structure that work.

What this means for your patching process

PHP2Shell is a test of whether your organization knows what it runs. The teams that close this out in a day are the ones with a current inventory of every web-facing system, a named owner for each, and an agreed emergency patch path that does not wait for a monthly window.

Expect more of these. The researchers behind PHP2Shell say AI cut weeks of exploit work down to days, and Fortinet gave its customers the same warning this week about its own security release. A 30-day patch cycle for internet-facing systems was already risky; it no longer matches how fast attackers move.

If you are not sure how many PHP systems you have, or who is responsible for patching the ones your vendors host, that is exactly the kind of gap our cybersecurity team closes. We can help you inventory exposed systems, confirm patch status, and check for signs of compromise, so you have a clear answer instead of a guess.

Sources

• PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws as Exploit Attempts Emerge, The Hacker News, 2026
• php2shell (CVE-2026-109618, CVE-2026-109619): Frequently Asked Questions, Tenable, 2026
• PHP2Shell: Critical vulnerabilities in PHP, detection, analysis, and remediation, Datadog Security Labs, 2026
• PHP Security Release on 21 October 2026: What WordPress Site Owners Need to Do, Codeable, 2026
• What you need to know about mandatory reporting of breaches of security safeguards, Office of the Privacy Commissioner of Canada
• Fortinet Releases Security Hardening Release for Multiple Products, Fortinet, 2026