PHP2Shell: Find Hidden PHP Installs, Verify the Fix

On October 21, 2026, PHP released emergency fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell. Both carry a CVSS v4.0 score of 9.2 and can enable unauthenticated remote code execution. Exploitation attempts were observed as early as October 17, four days before public disclosure. On October 26, CISA added both CVEs to its Known Exploited Vulnerabilities catalog.

The PHP security release identifies corrected versions, but determining which enterprise systems need those updates is harder. PHP can run through Apache modules, PHP-FPM pools, vendor applications, containers, and embedded server binaries that ordinary package scans may miss.

This analysis draws on official PHP security advisories and practitioner expertise contributed by Kyle Burk, Vice President at Cloudaware and former Chief Information Security Officer, and Anna Maeva, Vulnerability Management Expert at Cloudaware. Their experience informs our approach to uncovering overlooked PHP installations, coordinating remediation across infrastructure and application owners, and verifying that production services are running corrected code.

PHP2Shell status (November 11, 2026)

What is PHP2Shell? PHP2Shell refers to two critical vulnerabilities in PHP's memory management and request handling that can allow unauthenticated remote code execution. Supported PHP branches have corrected releases, while older versions require vendor-supported fixes or upgrades. Remediation must be verified against the PHP runtime actually serving application requests.

What PHP2Shell changes for enterprise vulnerability response

PHP2Shell exposes weaknesses in PHP's internal request lifecycle. Their impact depends on how the affected runtime is deployed and whether an attacker can reach the vulnerable execution path.

CVE-2026-109618 involves out-of-memory handling that can leave internal structures in an unsafe state. CVE-2026-109619 involves stale state retained across requests, creating use-after-free conditions.

The PHP security team identifies Apache mod_php as particularly exposed, with remote code execution demonstrated under default settings. PHP-FPM and other web-serving configurations also require assessment.

This creates an inventory problem for enterprises operating across AWS, Azure, GCP, VMware, and on-premises infrastructure. A scanner may identify an outdated PHP package without establishing which application uses it. Another application may serve requests through PHP embedded in software that does not appear in the host's package database.

The initial response must therefore establish which running services load affected PHP code and which deployment components can reintroduce it.

Which PHP versions are affected, and which releases contain the fix?

The PHP project shipped corrected releases for all supported branches on October 21, 2026. Older branches receive no new upstream releases, although certain operating system distributions and long-term support vendors provide security backports.

PHP 8.2 reaches the end of upstream security support on December 31, 2026. The PHP security team has also provided limited source patches for PHP 7.4, 8.0, and 8.1, but these do not constitute new supported upstream releases.

Upstream version comparisons alone can misclassify vendor-maintained packages.

For example, Ubuntu USN-8948-1 identifies 8.3.6-0ubuntu0.24.04.13 as a corrected package release for Ubuntu 24.04 LTS. The upstream-looking version remains 8.3.6, below PHP's fixed upstream release of 8.3.36.

A version-only scanner may continue reporting this package as vulnerable. Security teams must compare the complete installed package release with the relevant distribution or vendor advisory before determining whether a fix is present.

Windows builds need a separate check. On October 26, PHP published updated Windows builds (8.5.12-1, 8.4.27-1, 8.3.36-1, and 8.2.35-1) that fix a Brotli vulnerability, CVE-2026-111497, which CISA added to the KEV catalog on October 27.

Where PHP hides across enterprise infrastructure

PHP can enter an environment through a package manager, an application installer, a container image, or a server build that embeds the interpreter. Those installation sources do not necessarily produce the same software inventory records.

The following matrix maps six common sources to the evidence needed for discovery and the team responsible for updates.

“PHP arrives through package managers, dev stacks, control panels and vendor software, sometimes renamed, sometimes running as a separate process. A search that only looks for php.exe reports a clean environment and is wrong.”

— Kyle B., Vice President at Cloudaware (ex-Chief Information Security Officer)

A host-level package inventory can identify PHP installed through the operating system's package manager. It may not reveal PHP shipped within a vendor application's private directory.

Containers introduce another inventory boundary. A Kubernetes worker node can have no PHP package installed while multiple application containers use vulnerable PHP images. Scanning the node's operating system cannot establish the contents of those images.

Embedded runtimes require different checks. FrankenPHP incorporates PHP into a server executable, so searching only for a separate php or php-fpm process may miss it.

These differences also affect remediation ownership. The team patching Linux hosts may have no authority to rebuild application images or replace a vendor-managed runtime.

Discovery should cover every plausible installation source. Exposure assessment then determines which installations actually serve reachable requests.

How to find PHP installs across servers, containers, and vendor applications

PHP discovery requires correlation between software records and the services using them. Package inventory identifies potential installations; service and deployment evidence establish whether those installations are active.

Cross-check package inventory against running services

Start with Linux package records and Windows installed-program inventories. Search for PHP packages, versioned components, PHP-FPM packages, and applications known to distribute PHP.

For each candidate, determine which services load the runtime.

On Apache, inspect loaded modules and request-handler configuration. On nginx deployments, identify FastCGI endpoints and the PHP-FPM pools serving them. Hosting panels may maintain separate PHP installations for different sites or versions.

For containerized applications, collect the image identifier and digest from each deployed workload. Inspect image contents rather than relying on node-level package inventory.

Vendor applications require application manifests, installation paths, or vendor documentation where PHP is not registered as an ordinary operating system package.

Search executable names and loaded Apache modules

Executable names provide discovery leads, but they cannot establish complete PHP coverage.

Common candidates include php, versioned binaries such as php8.4, php-fpm, php-cgi, lsphp, and frankenphp. Names and locations vary by operating system and installation source.

Initial checks on an authorized Linux host may include:

php -v
php-fpm -v
apachectl -M | grep -i php

These commands depend on the installed components. A missing command does not establish that PHP is absent.

In particular, php -v reports the CLI interpreter selected through the current shell environment. Apache may load a different PHP module, while another application uses a separate FPM pool.

A search limited to PHP process or executable names may also overlook mod_php because the interpreter is loaded into Apache as a module.

For third-party applications, inspect documented runtime paths and package manifests. Avoid executing unfamiliar vendor binaries simply to determine their versions.

Count discovery coverage before classifying unaffected hosts

A software inventory report should identify the systems it could not inspect.

Reconcile the infrastructure inventory against installed discovery agents, vulnerability scanner coverage, and successful collection timestamps. Include cloud instances, on-premises servers, and container workloads within the response scope.

For example, an EC2 instance may appear in infrastructure inventory without a functioning software inventory agent. If its package records are missing, the absence of a PHP finding cannot support an unaffected classification.

The same applies to stale scans and container workloads whose images have not been inspected.

Effective software inventory requires source and freshness information alongside discovered applications. Hosts with insufficient evidence should remain Unknown until another discovery method establishes their status.

Missing scan coverage by OS, account, and application

Cloudaware scan coverage reporting highlights infrastructure without current vulnerability scan evidence, helping teams identify assets that require additional PHP discovery checks.

How to prioritize and remediate PHP2Shell across different ownership models

PHP2Shell remediation should run through two parallel workstreams: self-managed PHP and vendor-managed PHP. Priority within each depends on the runtime's exposure and execution context.

Separate self-managed from vendor-managed PHP

For self-managed installations, the platform team identifies the appropriate corrected upstream release or vendor-maintained package, applies the update, and restarts the affected services.

The supported package source matters. Distribution-maintained packages may contain backported security fixes without adopting the newest upstream version number.

Bundled PHP requires vendor coordination.

Hosting panels and packaged enterprise applications can depend on specific PHP builds, extensions, and configurations. Replacing the interpreter independently may break application compatibility or move the installation outside the vendor's supported configuration.

Application owners should request corrected releases immediately, establish expected delivery dates, and document interim treatment where a fix is unavailable.

Prioritize internet-facing web runtimes

Internet-facing Apache mod_php should receive the highest initial priority because the PHP security team confirmed a direct remote code execution path under default settings.

Other exposed web-serving PHP configurations remain urgent. Internal applications require assessment based on their reachable inputs and network access.

PHP2Shell remediation decision tree

PHP2Shell remediation follows runtime exposure and update authority, with separate correction paths for self-managed and vendor-managed PHP.

Severity alone cannot distinguish these deployment contexts. Existing risk-based vulnerability management processes should incorporate the actual application exposure and update authority when setting deadlines.

Handle unsupported branches and temporary containment

For PHP 8.1 and older, remediation may require a distribution backport, commercial long-term support package, or migration to a maintained PHP branch.

CISA advises taking PHP-based systems offline if they cannot be updated immediately or run PHP 8.1 or older.

Where a corrected build cannot be deployed immediately, the PHP security team documents interim measures for specific exploitation paths.

These include administratively configuring memory_limit=-1, limiting request sizes, disabling session.upload_progress.enabled, and setting fatal_error_backtraces=0 on PHP 8.5 where applicable. Appropriate worker restarts are required for configuration changes to take effect.

On October 23, PHP published an informational advisory recommending session.upload_progress.enabled=0 ahead of a full advisory for CVE-2026-115560, expected with the next release.

Resource boundaries such as cgroup memory limits can help constrain affected processes, although they require testing against normal application behavior.

These controls do not provide complete PHP2Shell mitigation. The PHP security team identifies updating as the necessary correction. WAF rules may reduce exposure to known request patterns but cannot substitute for a fixed runtime.

Unpatched services require an accountable owner, documented temporary controls, and a correction deadline. The same principles apply to other time-bound vulnerability mitigation decisions.

How to verify the running PHP version and prove remediation

Remediation verification must establish which PHP build the application is actually executing. Installed package records, process state, and deployment configuration provide different pieces of that evidence.

Verify the PHP build serving application requests

After applying the fix, restart affected Apache workers, PHP-FPM pools, and other long-running processes using the updated PHP runtime.

Check the executable or module used by the application, then confirm its corrected version or vendor package build.

For PHP-FPM, identify the pool serving the application. For Apache mod_php, inspect the loaded module and its associated build. An access-restricted application-level version check may help confirm the runtime handling requests, but temporary diagnostic endpoints must be removed immediately after verification.

Run a follow-up vulnerability scan after the service restart. Its results should be reconciled with the runtime evidence rather than treated as the only proof of closure.

Validate vendor backports and deployment sources

For vendor-maintained packages, compare the complete installed package release with the applicable security advisory.

Then check the source from which the service can be recreated. A patched VM can still deploy a container built from a vulnerable PHP image. A VM template, autoscaling configuration, or application build pipeline may also reintroduce the old runtime.

Rebuild affected images, verify running image digests, and confirm that deployment sources reference corrected artifacts.PHP2Shell scope-to-closure worksheet:

Each service should have one of five applicability states:

Consider a production application whose VM packages have been updated while its deployed container still uses an older PHP image. The host update cannot close the application finding.

Conversely, an Ubuntu host using a verified security backport may be fixed even if a version-only scanner continues reporting an older upstream release. Its running service must still be checked.

A complete vulnerability and patch management record should preserve this evidence. A closed ticket without service-level verification leaves the actual runtime status unresolved.

Check exposed PHP hosts for signs of compromise

Patching an affected runtime does not establish whether attackers accessed it before the update.

Amazon Threat Intelligence reported an exploitation attempt on October 17. Investigation windows should account for activity before the October 21 public disclosure.

Review available web server, WAF, application, PHP, and endpoint telemetry for suspicious child processes launched by PHP workers, unusual multipart requests, abnormal session activity, and unexpected memory or fatal errors.

CISA's alert includes a SIGMA detection rule for suspicious PHP worker activity.

These are investigation leads rather than standalone confirmation of exploitation. Correlate suspicious events with process activity, request history, and applicable detection guidance. Datadog Security Labs provides additional technical detection context.

The stale-state vulnerability can also expose process memory. If exploitation or memory disclosure is suspected, identify credentials, tokens, and other secrets accessible to the affected PHP process. Preserve relevant forensic evidence and rotate potentially exposed secrets according to the investigation's findings.

How can Cloudaware help find PHP installations and coordinate remediation?

Kyle Burk, Vice President at Cloudaware and former CISO, recommends starting with broad PHP discovery, then splitting installations the infrastructure team can patch from those that depend on a vendor update.

Step 1. Build a PHP candidate list from Breeze software inventory

Cloudaware Breeze Agent collects installed Linux packages and Windows programs into the CMDB.

Search those records for PHP-related package and program names, such as php, php-cli, php-fpm, and version-suffixed packages like php8.1. Record each candidate’s asset, package version, application association, and collection timestamp.

The difficult cases are third-party installations. PHP may be bundled inside an application, installed outside a package manager, or renamed, and these copies do not necessarily appear as a PHP package or program in inventory.

For Log4j, Cloudaware added a Breeze Java discovery fact to identify vulnerable library files. For PHP, package inventory is a starting point: bundled and renamed installations require evidence from the application, the vendor, or a targeted check on the host.

Step 2. Patch self-managed PHP while vendor fixes are requested

Use CMDB relationships to identify the application and team that owns each candidate host.

Start the self-managed workstream immediately, since corrected upstream releases and distribution security updates are available. Run it in parallel with vendor escalation rather than ahead of it, and order the work by exposure, starting with internet-facing web runtimes.

A dedicated remediation Initiative helps group this work, with Remediation Tasks assigned by application owner or organizational unit. After the update, application owners still need to restart affected services and verify the loaded PHP build.

EC2 instance with related application and owner

Cloudaware CMDB connects infrastructure assets to related applications and responsible teams, providing context for PHP remediation assignments.

Step 3. Coordinate third-party PHP updates with application owners

For PHP bundled inside vendor applications, check whether the provider has published a corrected release. Record the vendor, affected application, available fix, responsible owner, and expected update date.

NCSC-NL maintains a public list of software with a PHP dependency and its fix status, covering 968 products as of November 9.

Cloudaware Remediation Tasks can group findings, for example by CVE and application, and synchronize the work with Jira or ServiceNow queues aligned to the owning team. Vendor-dependent fixes can be tracked in a separate Initiative from internal patching.

Remediation tasks by owner and Jira status

A Remediation Task links the vulnerable CI, its application, the owning team, and the Jira issue used to track the fix.

Where no corrected release exists yet, a Vulnerability Exception documents the owner, justification, compensating controls, and start and expiry dates. Findings covered by an active exception are excluded from standard SLA calculations and most remediation queues, so review vendor-pending exceptions in exception reports until the update ships.

Step 4. Repeat discovery and verify the fix

Run the same PHP discovery checks used during scoping and compare the results with the original candidate list. The same method gives a comparable result but also keeps the same blind spots, so bundled and embedded runtimes still need their own evidence.

Cloudaware ingests follow-up vulnerability scan results and can update or resolve related tickets when findings are no longer detected. The responsible team still needs to confirm the active PHP runtime, including service restarts, vendor backports, and container image updates where applicable.

One CVE from three scanners on one asset

Findings from Tenable, AWS Inspector, and Qualys for the same CVE link to one CMDB asset and its application.

Keep installations without sufficient evidence in Unknown status. A successful package update or a closed ticket does not prove that the vulnerable PHP runtime has been replaced.