php2shell: what it is and how to fix PHP now

On October 21, 2026 the PHP project shipped emergency fixes for two critical unauthenticated remote code execution flaws. They are tracked as CVE-2026-109618 and CVE-2026-109619 and widely called php2shell. The risk does not hinge on a fragile plugin or a poorly written theme. It sits in the runtime that handles the HTTP request. That raises the priority of the response for anyone who runs a site, an API, or hosting infrastructure.

If you maintain WordPress, Laravel, Drupal, a control panel, or a container based on the official PHP image, start with inventory. The same applies to any app behind PHP-FPM or Apache with mod_php. Find the version that actually serves traffic and plan the upgrade. This guide stays on the defense and operations side. It covers what open sources confirm, where they diverge, how to find exposure, how to remediate, and what to reduce while the PHP RCE patch is still pending.

The text does not teach exploitation. It helps you decide what to do tomorrow in inventory, in the pipeline, and in the maintenance window, with risks and limits next to each recommendation.

What php2shell is and why it matters now#

php2shell is the informal name for CVE-2026-109618 and CVE-2026-109619. Both are memory-safety issues in the PHP core. Under the right conditions, an unauthenticated attacker can run code with the privileges of the web worker. That is why operators treat php2shell as a runtime emergency rather than a CMS cleanup ticket.

The security notice in the php.net archive describes the first issue as corruption tied to out-of-memory handling. It describes the second as reuse of stale global state across requests on the same worker. The PHP Foundation stressed the same day that both touch memory management and error handling. Those paths are hit by almost every request, so php2shell exposure is not limited to exotic plugins.

How severity scoring for php2shell should be read#

The official note and the government alerts that repeat it assign CVSS v4.0 9.2 to each CVE. Before the full announcement finished circulating, a score of 10.0 also spread in informal channels. Treat 9.2 as the published reference from the project and from agencies that cite the CNA assessment. Treat the inflated score as rumor until an official record backs it. For planning, the operational label of php2shell already justifies urgent patching even when the rumor score is ignored.

Where sources diverge on real-world php2shell exploitation#

The practical impact is wide because the attack targets the interpreter, not your application logic. On Apache with mod_php, the PHP team and the Foundation report demonstrated exploitation in which the request hits the vulnerable path before any application code runs. On PHP-FPM, remote code execution was also confirmed through application-level paths. Sensitive process memory disclosure also appears in the technical descriptions, which can expose secrets from other requests on the same worker.

On real-world exploitation, the sources do not speak with one voice. The CISA alert dated October 21, 2026 states that, at publication time, the agency had not observed exploitation. Commercial sensors and same-day reporting describe attack traffic and probing after earlier detail leakage. Attempts exist according to several sensors. Large-scale successful compromise is not a fact that every authority confirmed at the same moment. Operational risk from php2shell, however, does not wait for consensus.

In practice, what I see most often is a team treating php2shell as a CMS bug when the problem sits in the PHP binary under that CMS. Teams that are slow to separate runtime from application lose the window where the patch is still cheap.

Who is affected by the PHP flaws behind php2shell#

According to the official advisory, every PHP install that serves web requests is at risk under php2shell. That includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. Risk is considered highest for mod_php, because a demonstrated trigger exists without authentication before application code runs. That covers a large share of classic shared hosting and many legacy stacks where php2shell can land first.

Fixed versions and unsupported lines after php2shell#

The fixed versions published on October 21, 2026 are PHP 8.5.12, PHP 8.4.27, 8.3.36, and 8.2.35. Earlier releases in each supported branch are listed as affected in the php-src GHSA advisories. The PHP project is clear that 8.1 and older no longer receive official updates on the main line. Distributions and LTS vendors may ship backports. For people building from source without an LTS path, the security team published minimal source backports for 7.4, 8.0, and 8.1. When your plan is to update PHP 8.5.12 on that branch, keep the sibling targets for 8.4, 8.3, and 8.2 in the same change window.

There is an important split on how far back the bug class reaches. Researcher reports and Cloudflare assert impact back to PHP 5.4, meaning a decade or more of releases. The official php.net notice, as read for this piece, does not use that phrase as a single vendor confirmation. It focuses on the lines with a published patch, on the end-of-life status of 8.1, and on backports. In responsible editorial writing, say that Cloudflare and the research groups cited in the disclosure claim coverage since 5.4. Also say that what the vendor confirms operationally is the need to move to 8.2.35, 8.3.36, PHP 8.4.27, or 8.5.12, or to obtain a backported package from your vendor.

Embedded PHP and managed hosting in a php2shell inventory#

Products that embed PHP without an obvious label also belong in the php2shell inventory. That includes panels, appliances, old Docker images, and managed environments. The Swiss NCSC and CISA ask for inventory beyond the public site. Managed hosting can feel out of your hands, yet the account remains yours until the provider confirms the fixed package. On Linux, the Swiss NCSC also warns that a matching major version number does not prove a patch is present, because a backport can keep the apparent number while changing the package contents.

The mistake that costs the most here is inventorying only the WordPress on the storefront and forgetting the second PHP on an internal panel, a web cron, or an exposed staging container. Attackers chasing php2shell do not respect your org chart.

How to tell whether your PHP install is still exposed to php2shell#

You discover php2shell exposure by crossing three facts. Use the runtime version that serves HTTP, the package origin, and the SAPI in use. Running php -v in a shell helps, yet it is not enough when the site uses another binary through FPM or an Apache module. Check the version reported by the application in a controlled environment. Use phpinfo() only on an administrative network. Also check the distribution package and the container image tag before you clear a php2shell ticket.

Suggested practical order.

1. List hosts and services that return dynamic PHP content, both public and internal, as candidates for php2shell review.
2. Identify the SAPI, whether mod_php, PHP-FPM, cgi, FrankenPHP, or LiteSpeed, because patch priority rises when mod_php is exposed.
3. Record the exact version and package. On Debian and Ubuntu, the package number and security changelog matter as much as PHP_VERSION. On RHEL and clones, the vendor advisory leads.
4. In containers, read the running image and the build date. A php:8.4 image pulled weeks ago may still sit below PHP 8.4.27.
5. On managed hosting, ask for written confirmation of the fixed version or security ticket. Until confirmation arrives, treat the stack as vulnerable to php2shell.
6. If you are on 8.1 or below without a vendor backport, treat the install as vulnerable and without an official PHP project path, aside from the minimal source backport or a migration.

Version thresholds that place you in the php2shell remediation zone#

If the version is lower than 8.5.12 on the 8.5 line, lower than PHP 8.4.27 on 8.4, lower than 8.3.36 on 8.3, or lower than 8.2.35 on 8.2, and there is no evidence of a backport, you are in the immediate remediation zone for php2shell. For 8.1 and older, the question shifts from which php.net patch to which vendor package or which migration date.

A lot of people trust only the php -v from SSH, and they are usually wrong, because the site worker can be a different file. Confirm the FPM pool binary or the Apache module before you mark the php2shell item resolved.

How to fix php2shell with official versions and backports#

The only complete remediation for php2shell, in the PHP project’s own words and repeated by CISA, the UK NCSC, and European CERTs, is to update the runtime. Official targets on October 21, 2026 include the releases below. Teams that need to update PHP 8.5.12 should treat that target as the minimum on the 8.5 line, not as a marketing label.

Patch order and validation after a php2shell update#

The priority order most operations should follow puts internet-facing services with mod_php first. Next come internet-facing PHP-FPM hosts, then internal systems with sensitive data, and finally the rest of the inventory. After you install the package, restart Apache, PHP-FPM, or the equivalent. Confirm the version on the process that actually serves traffic. Containers need an image rebuild and redeploy, not only a restart of an old tag. The GHSA advisory for CVE-2026-109618 states clearly that only a release with the patch is a complete mitigation. That is the durable PHP RCE patch path for php2shell.

If you depend on rpms.remirepo.net, the php.net notice on that date asked for a move to distribution packages or a build from source, because that volunteer repository would not ship updates the same day. Anyone on 7.4, 8.0, or 8.1 without LTS must choose among a minimal source backport, a vendor package, or a jump to a supported line. None of those options is free of regression risk. Test the application, especially native extensions and pecl modules, after any php2shell fix.

Updating the runtime does not clean prior compromise. If you see signs of a shell, odd downloads from the worker, or unexpected file changes, open the incident response playbook. Treat the case as an incident, not as a patch ticket alone. A vulnerability management program helps you avoid the same surprise on the next runtime CVE after php2shell.

Teams that leave the php2shell patch for next sprint often learn that the upgrade regression was smaller than the cost of isolating the site in the middle of the workday. Schedule a short window and measure afterward.

What to do while you still cannot update after php2shell#

While the php2shell patch is not in place, shrink the attack surface. Accept that no partial mitigation makes the install safe. The UK NCSC asked organizations to prepare for an immediate update. If remediation is not viable, it asked them to consider taking the system offline until a real fix lands. CISA repeats the offline logic for those who cannot update and still run 8.1 or earlier without a fix for php2shell.

Partial config controls while php2shell remains unpatched#

Transitional measures described by the php.net notice and the GHSA advisory for CVE-2026-109618 include forcing memory_limit=-1 in an administrative way. Use php_admin_value in the FPM pool or in Apache so the application cannot reinstate a finite limit. They also recommend a low post_max_size, 8M without uploads or 32M when uploads are required, with upload_max_filesize below that ceiling. Add proxy limits on decoded size, fields, multipart parts, and depth, including when useful Content-Length is missing. A cgroup or container limit can act as an availability boundary if it kills only the affected worker. Do not use RLIMIT_AS or RLIMIT_DATA as a substitute, because that can trigger the allocation failure on the vulnerable path tied to php2shell.

For CVE-2026-109619, the notice asks for session.upload_progress.enabled=0 in configuration applied before request parsing, with a restart of every worker. Do not rely on ini_set() or .user.ini. On PHP 8.5, also set fatal_error_backtraces=0 with a restart. Remove invalid or deprecated settings that emit diagnostics too early. Hiding errors with display_errors does not solve php2shell.

Why a WAF alone is not a php2shell closure#

A WAF helps as an extra layer against php2shell probing. Cloudflare reported WAF protections deployed before public disclosure and still asked for a patch. CISA and the Swiss NCSC say the same. A WAF alone is not enough. Restricting access with VPN or allowlists, removing internet from systems that do not need it, and isolating uploads are containment controls, not a cure for php2shell.

The hidden cost of these mitigations is broken uploads, large forms, and session progress features. Measure the effect in staging. If the business cannot absorb the side effect and the patch slips, the honest NCSC alternative remains. Take offline what you cannot fix after php2shell.

Anyone who applies only a WAF rule and closes the php2shell ticket swaps technical risk for false confidence. Use mitigations to buy hours, not weeks.

Hardening that shrinks blast radius after a php2shell patch#

After you update for php2shell, harden the surroundings so the next worker flaw does not become a full host compromise. Per-site FPM pool isolation, a distinct Linux user, a code filesystem that is as read-only as practical, and secrets kept outside the document root remain sound. Body limits at the proxy and in PHP reduce memory pressure even after the php2shell patch. CERT-EU and CISA ask for monitoring of abnormal worker restarts, multipart spikes, and unexpected PHP child processes, including workers that launch a shell or a download.

Observability does not replace a php2shell patch, yet it keeps you from learning about an incident only through defacement. Forward access logs, FPM error logs, and host audit trails into the same stream you use for incident log review. If you suspect earlier access, persistence hunting becomes its own step, because updating PHP does not remove a webshell already written to disk after a php2shell hit.

There is a clear limit. Hardening shrinks radius and speeds response. It does not cancel a critical runtime CVE while a vulnerable version still faces the internet under the php2shell label.

In day-to-day operations, what separates “package installed” from “environment under control” after php2shell is checking the live process and behavior after restart, not only the package in dpkg. Without that check, the inventory lies politely.

Developer checklist for php2shell remediation#

Developers close php2shell exposure when the web SAPI version in every environment matches a fixed release, not when a local CLI bump looks green. Use the steps below as the product-side half of the PHP RCE patch work.

1. Learn which PHP version each build, CI, staging, and production environment actually uses on the web SAPI, not only on the CLI, before you claim php2shell is gone.
2. Update base images, Dockerfile files, and runtime locks so you can update PHP 8.5.12, PHP 8.4.27, 8.3.36, or 8.2.35, matching the line your project supports.
3. Run the test suite and a smoke path for upload, session, and multipart forms, because transitional mitigations and limit changes break legitimate flows during php2shell response.
4. Remove dependence on session.upload_progress if it still exists in the UX, since that path appears in the mitigations for CVE-2026-109619.
5. Treat user-reachable fatal errors and timeouts as security debt, not only UX debt, because the notice links residual state to poorly cleaned fatal errors that php2shell can abuse.
6. Do not publish an exploit, a working PoC, or a payload. The product team’s job is to close exposure and document the fixed version in the service runbook after the php2shell change.
7. Ask the platform team for confirmation of the managed hosting package before you mark the php2shell story done.

A developer who only bumps the local image and forgets the production worker leaves the php2shell risk exactly where an attacker looks first. Close the loop with evidence of the version on the remote process.

Operations and hosting checklist after php2shell#

Operations owns the live worker that answers on port 443, so the php2shell checklist ends only when that process shows a fixed package. Hosting tickets without a version string do not count as closure.

1. Inventory every PHP instance that serves HTTP, including appliances, panels, containers, and self-managed SaaS that may still carry php2shell.
2. Prioritize internet-facing mod_php, then public FPM, then the rest of the php2shell backlog.
3. Apply the vendor package or the official release, restart workers, and validate the version on the active process after the php2shell change.
4. If you cannot patch immediately, evaluate offline status as NCSC and CISA recommend, apply the partial mitigations from the php.net notice, and keep the WAF current without treating that as php2shell closure.
5. Monitor workers that launch shells, curl, or downloads, serial crashes, and anomalous multipart uploads that may follow php2shell probing.
6. Require the hosting provider to state the fixed version in writing and the date it was applied for php2shell.
7. After the patch, review indicators of prior compromise before you declare victory on php2shell.

Ops teams that close the ticket on “package installed” without validating the pool binary often reopen the same php2shell ticket under another name. The evidence is the version of the process answering on port 443.

Frequently asked questions about php2shell#

Operators and developers keep asking the same practical questions after the October 21, 2026 disclosure, usually because the informal name sounds like a CMS issue and because hosting, containers, and unsupported branches blur who owns the fix. The answers below stay aligned with the PHP project notice, CISA guidance, and the national CERT advisories cited in this article, and they focus on decisions you can make in inventory and maintenance without turning the page into an attack guide for php2shell.

Is php2shell a WordPress flaw or a PHP flaw?#

It is a flaw in the PHP runtime, not a WordPress plugin bug. WordPress, Drupal, Joomla, and similar platforms enter the picture because they run on that runtime. A well written application does not immunize you when the PHP version remains vulnerable, which is why CVE-2026-109618 and CVE-2026-109619 show up in CMS environments even when plugins look current and the php2shell label keeps circulating in ops channels.

Does updating the CMS fix this without updating PHP?#

No. You need the fixed interpreter version or an equivalent vendor backport before php2shell risk drops. Updating only CMS plugins and core does not close CVE-2026-109618 or CVE-2026-109619, so a green plugin dashboard can coexist with an exposed worker until the runtime moves to 8.5.12, PHP 8.4.27, 8.3.36, 8.2.35, or a confirmed backported package that completes the PHP RCE patch.

Does a WAF alone protect me from php2shell?#

Not completely. Cloudflare, CISA, and the Swiss NCSC treat a WAF as a temporary layer against php2shell traffic. The PHP notice states that only the update is a complete solution. Keep the WAF enabled while you prioritize the patch, and do not close the risk ticket on WAF rules alone when the worker version is still below the fixed releases that address php2shell.

Do PHP 7.4 or 8.1 have an official php.net fix for php2shell?#

The project no longer maintains official releases on those lines for php2shell. There is mention of minimal source backports for 7.4, 8.0, and 8.1, and possible fixes through LTS distributions. Without one of those paths, the exit is a migration to a supported line that already includes the fix, with regression testing for extensions and application behavior after the php2shell change.

How do I know whether my host already applied the php2shell patch?#

Ask for the exact PHP version on the web SAPI and for the package reference or provider advisory that names the php2shell fix. If the answer is vague, treat the environment as unpatched until you have evidence, because a marketing claim of “latest PHP” can still mean a build below PHP 8.4.27 or 8.5.12 on the line you use.

Do I need to take the site offline because of php2shell?#

Only if you cannot apply the patch on a short timeline and internet exposure is unacceptable for your risk posture under php2shell. That is exactly the scenario in which NCSC and CISA ask organizations to consider offline status. Make the call with the service owner and security, not in the dark, and document the return criteria once a fixed runtime is verified after php2shell remediation.

Conclusion#

php2shell, in the operational sense of October 21, 2026, is a runtime event. Anyone who operates PHP needs to treat inventory, patching, and validation of the live process as one chain. Most teams should update now to 8.5.12, PHP 8.4.27, 8.3.36, or 8.2.35, or to the vendor’s backported package, starting with what faces the internet and especially with mod_php.

The answer changes when you are stuck on a dead line without LTS, when a vendor embeds PHP without transparency, or when there is already a sign of compromise. In those cases the order becomes containment, evidence, and only then return to service. The first concrete step is to list every SAPI and every version that serves HTTP today and to assign a date and an owner for the php2shell patch.

This article is informational and educational material about php2shell and about CVE-2026-109618 and CVE-2026-109619. It does not replace an assessment from your hosting provider, your security team, or a professional responsible for the environment under review.