PHP2Shell on Windows IIS: am I affected?

As of 29 October 2026, PHP's advisory includes PHP-CGI among the web runtimes affected by PHP2Shell. If IIS serves your application through an unpatched PHP-CGI build, Windows does not put it outside the advisory's scope. Start with the executable in the IIS handler mapping, then check the PHP version used by a web request. PHP advisory

On 28 October, Morphisec described a Windows IIS/PHP-CGI post-exploitation chain that it attributes to PHP2Shell. Its report describes blocking a later payload, not detecting the initial PHP exploit. That report is a reason to investigate Windows hosts, not proof that your server was compromised. Morphisec report

Find the PHP-CGI executable IIS uses

In IIS Manager, inspect the PHP handler mapping for the site or application you are checking. Record its executable path and the matching FastCGI configuration. PHP's IIS instructions map PHP requests to php-cgi.exe, not php.exe. They also show a PHPRC environment variable pointing to a configuration file. PHP IIS manual

Use this diagnosis order:

Record the site's PHP handler and its full php-cgi.exe path.
Record the associated FastCGI settings, including PHPRC if present.
Confirm the runtime and loaded configuration through that site's web request.
Update the installation identified by those checks, then verify it again.

This is our diagnosis order based on the PHP documentation. Changing the PHP found by a command prompt is not enough evidence that you changed the installation named in IIS.

Do not paste the IIS manual's complete setup script into an existing server. It includes commands that clear FastCGI configuration. Inspect the existing mapping and plan a targeted change instead. PHP IIS manual

Confirm the web runtime and configuration

Have the server administrator run the following temporary diagnostic through the affected site's PHP handler, behind server-enforced access restrictions. Do not expose it publicly. Remove it after recording the results.

<?php
header('Content-Type: text/plain; charset=utf-8');
echo 'PHP Version: ', phpversion(), "\n";
echo 'SAPI: ', php_sapi_name(), "\n";
echo 'Loaded php.ini: ', var_export(php_ini_loaded_file(), true), "\n";
echo 'Additional ini files: ', var_export(php_ini_scanned_files(), true), "\n";

phpversion() reports the running parser's version. php_sapi_name() reports the interface PHP is using. The manual lists cli and cgi-fcgi among its possible return values. Because you run this diagnostic through the site's IIS handler, its output describes the runtime serving that request. The SAPI string alone does not establish that a diagnostic ran through the site. The other functions report the loaded primary configuration path and additional scanned configuration files. A false result from php_ini_loaded_file() means no primary file was loaded. Version, SAPI, loaded configuration, scanned configuration

Keep this output with the IIS mapping. PHP can find configuration through PHPRC, Windows registry entries and other locations; it can also scan additional files through PHP_INI_SCAN_DIR. Do not assume the configuration beside a newly downloaded executable is the configuration the site loaded. PHP configuration manual

If you use phpinfo() for a fuller inventory, restrict access and remove it afterward. Its output can include environment, request and configuration data. phpinfo manual

Choose the patched runtime and Windows build

PHP's 21 October advisory identifies these fixed releases:

PHP branch	PHP2Shell fixed runtime
8.2	8.2.35
8.3	8.3.36
8.4	8.4.27
8.5	8.5.12

These releases fix CVE-2026-109618 and CVE-2026-109619. PHP 8.1 and older no longer receive updates from the PHP project. It supplied minimal source backports for 7.4, 8.0 and 8.1; those are not a promise of a ready-made Windows package. Obtain evidence for a vendor-maintained build or plan an upgrade to a supported branch. PHP advisory

For IIS FastCGI, PHP specifies a Non-Thread Safe (NTS) build. Record the intended x86 or x64 build and check its Windows and Visual C runtime requirements before replacement. PHP's installation manual requires the Visual C runtime architecture to match the PHP build. IIS installation, Windows binary installation

The Windows -1 rebuild is a separate check

On 26 October, PHP released Windows packages 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1 with Brotli 1.2.1 for CVE-2026-111497. PHP says the source releases and runtime versions stayed unchanged. The notice explains that the vulnerable Brotli decoder can be reached through the cURL extension when automatic HTTP response decompression is enabled. cURL leaves that feature off by default, but applications and HTTP client libraries can enable it. PHP Windows rebuild notice

Record the downloaded Windows package identity separately from the PHP runtime version. A web response showing 8.4.27, for example, does not establish whether the installation includes the -1 dependency rebuild. The PHP2Shell runtime fix and the Brotli dependency fix answer different questions.

Update the mapped installation, restart, then recheck

Use the handler path and configuration inventory as the change record. Our recommended sequence is:

Preserve the existing IIS mapping, FastCGI settings and PHP configuration for reference.
Prepare the patched NTS installation and review the application's configuration and extension requirements before switching it into use.
Apply the targeted IIS/FastCGI mapping change if the installation path changes. Verify it still points to php-cgi.exe.
Restart every PHP worker using the updated installation. Have the IIS administrator handle this through the server's operating procedure.
Run the restricted web diagnostic again for each affected site or application. Compare the version and configuration paths with the intended installation, then check the application's normal functions and remove the diagnostic.

The handler and build requirements come from the PHP manuals; restarting every PHP worker after an update comes from watchTowr's FAQ. The before-and-after record and application checks are our recommended verification sequence, not a reproduced IIS deployment.

If patching cannot happen immediately, restrict internet access to the PHP system as watchTowr advises. Use host or network controls that prevent public requests reaching PHP, including direct access to the origin. Do not treat an application's maintenance page as that restriction. Configuration workarounds are not a complete replacement for updating. watchTowr FAQ, PHP advisory

Check Windows activity separately from the version

Morphisec describes this process chain in its report:

w3wp.exe → php-cgi.exe → cmd.exe → packed payload

It says the payload attempted a reverse-shell connection to an external server. Use that reported chain to guide a review of retained endpoint process and network telemetry. Investigate unexpected command shells beneath PHP-CGI and correlate them with outbound connections. Morphisec's report also lists new files in web-accessible directories and PHP worker crashes or restarts as things to look for. These are investigation leads, not a standalone verdict on your host. Morphisec report

Record the patch check and the incident investigation as separate results. This guide does not reproduce the exploit or establish whether a particular server was breached.

Check the version you found

Run the PHP2Shell version checker with the version from the web diagnostic. Paste only the version line, not your configuration paths or a full diagnostic dump.

The checker compares supplied text with fixed versions. It does not inspect IIS, verify the active executable, establish the Windows dependency rebuild, validate a vendor backport or check for compromise. Those checks remain with the server administrator. Checker information

For help, read the existing PHP2Shell check & patch page and confirm that its listed service applies to your environment before requesting work.

How we checked this
We read PHP's security and Windows rebuild notices, IIS and Windows installation manuals, configuration and diagnostic-function manuals, watchTowr's FAQ, and Morphisec's report on 29 October 2026. The notices are dated 21 and 26 October; watchTowr's FAQ was updated 26 October; Morphisec's report is dated 28 October. Manual publication dates are not stated.
The fix sequence comes from vendor documentation with our diagnosis order. We did not reproduce it on Windows IIS, run an exploit probe or use an Enviera client incident. The Windows activity is attributed to Morphisec's report.