PHP2Shell: host's IIS rule blocked ColdFusion uploads, and how to find hidden PHP

A blogger who runs ColdFusion sites on a Windows server with IIS at a hosting company describes how a PHP security rule broke sites that contain no PHP. While signing in to his test blog, he got a plain IIS 403 Forbidden page saying multipart form-data requests were blocked by a PHP mitigation. His blogs are ColdFusion and run no PHP code, so the rule made no obvious sense.

The timing explained it. On October 21, 2026, PHP shipped emergency patches for two critical flaws, nicknamed PHP2Shell, that let an unauthenticated request run code on the server. The author says every PHP setup that serves web requests was affected: PHP-FPM, Apache's mod_php, php-cgi, FrankenPHP and LiteSpeed. The fix is to install PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35.

His host responded the same week with a rule in IIS's server-wide URL Rewrite settings. It applied to every site on the server and blocked every request whose content type was multipart/form-data, whatever the address. That is the encoding browsers use for any form that can upload a file. The author notes that PHP's own advice does not include blocking such requests: it is to patch, and until then to turn off session.upload_progress.enabled and lower post_max_size. He can see why a host would reach for the biggest hammer, but on his four ColdFusion sites the admin sign-in form, every image upload and every file upload failed at once, because the rule matched every address, not just .php ones.

Once he had scoped the rule to .php addresses, everything worked again. Then he asked why PHP was on the server at all. The answer was a phpMyAdmin install he had requested years earlier to manage one MySQL database. It was still in a site folder, and its login page was open to the whole internet. The host turned the blanket rule off after he told them PHP was no longer in use.

The rest of the post is a how-to. Check 1: in an Administrator PowerShell, list IIS handler mappings for *.php with Get-WebHandler; no output means IIS does not run PHP, while a FastCGI entry pointing at php-cgi.exe means it does, for every site that inherits the server settings. Check 2: count and group PHP files under the web root using the Windows dir command, which is much faster than Get-ChildItem on a server with years of uploaded images. His check found about 4,500 files in two folders, both phpMyAdmin: one inside a site, and a second copy at the web root that IIS's Default Web Site served to anyone visiting the server's bare IP address. Unrecognised PHP files, especially in image or upload folders or changed recently, should be treated as a possible break-in, since attackers drop small PHP web shells into upload folders. Check 3: look for php processes and a C:\php folder; the lack of a php-cgi.exe process proves nothing, because IIS starts it on demand. Check 4: from another computer, request addresses such as phpmyadmin/, pma/ and info.php on your own sites; anything answering 200 deserves a look.

For removal he says to work in order, back up first, and notes that every step is reversible. Step 1: snapshot IIS configuration with appcmd.exe add backup, restorable with appcmd.exe restore backup. Step 2: move, not delete, phpMyAdmin and other PHP apps out of the web folders, keeping the configuration file privately for a few weeks because it may hold a database password; for MySQL afterwards he suggests a desktop tool such as HeidiSQL or MySQL Workbench over Remote Desktop. Step 3: add a server-level request filtering rule denying the .php extension. Step 4: remove the PHP handler and the FastCGI entry, then rerun Check 1, which should print nothing. Step 5: uninstall PHP last, or rename its folder for a few weeks first; if the host installed it, ask the host before this step.

If you need to keep a rule like this, he says to scope it to PHP addresses, because the rule's match url of .* was the whole problem. He changed it with Set-WebConfigurationProperty and a single-quoted pattern; an appcmd.exe attempt failed silently because PowerShell mangled the quoting. For Lucee on Linux and Apache he gives equivalents: php -v, apachectl -M, a find for *.php files, and a2dismod on Debian and Ubuntu, with a warning that control panels such as Virtualmin often install PHP for their own tools.

His gotchas: a server-wide rule catches every site, and the full IIS error page named the rule; hosts re-run their scripts, and his recreated the rule on every run, so a local fix could have been silently undone; a config edit can land in the wrong web.config, as his first fix did; and ColdFusion's Trusted Cache keeps running the old compiled copy of a hand-replaced .cfm file until cleared. Finally, removing PHP is not a substitute for patching. If you do run PHP, update to the fixed versions or newer, set session.upload_progress.enabled to 0 until you can, and note that PHP 8.1 and older no longer get updates from the PHP project.

Key facts

• PHP shipped emergency patches on October 21, 2026 for two critical flaws, nicknamed PHP2Shell, that allow unauthenticated code execution; fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• A host's server-wide IIS rule blocked every multipart/form-data request on every site, so sign-in and uploads failed on all four of the author's ColdFusion sites with a 403 Forbidden.
• The cause was a phpMyAdmin install requested years earlier, still present with a login page open to the internet; the author's check found about 4,500 PHP files in two phpMyAdmin folders.
• The post gives PowerShell checks (handler mapping, PHP files, processes, public addresses) and five reversible removal steps, plus Linux and Apache equivalents.
• The author stresses that removing PHP is no substitute for patching if PHP is actually in use.

Why it matters

An emergency fix for one platform can reach sites that never ran it. Here a host's blanket response to PHP2Shell broke form submissions on ColdFusion sites, and the same exercise showed that a forgotten phpMyAdmin install was still sitting on the server with its login page exposed. The author frames it as part of a wider pattern of constant patches and mitigations.

Who it affects

The post is aimed at people who run ColdFusion or Lucee on Windows with IIS and never installed PHP on purpose, since PHP may have arrived with a control panel, an old phpMyAdmin install or the host's setup image. It also covers Lucee on Linux and Apache. Anyone who does run PHP is told to patch, and sites on shared hosts may be hit by a server-wide rule they did not choose.

How to use it

Run the four checks: IIS handler mappings for *.php, a count of PHP files under the web root, PHP processes and a C:\php folder, and requests to common addresses such as phpmyadmin/ and info.php. If nothing uses PHP, follow the order: back up IIS configuration with appcmd.exe, move PHP apps out of the web folders, deny .php in request filtering, remove the handler and FastCGI entry, and uninstall PHP last. If a rule must stay, scope its match to .php addresses. On Debian and Ubuntu, a2dismod stops Apache from running PHP. Tell your host what you changed.

How solid is it

This is a first-person practitioner account from a ColdFusion blog, based on the author's own server, not an independent investigation. The commands and the sequence come from his experience, and he says he tested the scoped rule change and had to correct a quoting problem along the way. The post does not name the two CVEs or explain how PHP2Shell works beyond unauthenticated code execution, and it does not name the hosting company.

Risks and caveats

Unrecognised or recently changed PHP files, especially in upload folders, should be treated as a possible break-in, and the author says to stop and investigate. Removal steps can take sites down briefly if iisreset is needed, and PHP installed by the host should be discussed with them first. A host may recreate its own rule on every script run, undoing local fixes. Removing PHP is only right when nothing uses it; otherwise patch, and note that PHP 8.1 and older no longer receive updates. The post does not say whether the host later restored or replaced its rule.

“Removing PHP isn't a substitute for patching.”

— The post's author, on the ColdFusion blog gregoryalexander.com