Unwanted PHP on ColdFusion and Lucee servers: a PowerShell guide to finding and removing it

A blocked login with an unlikely culprit

On October 21, 2026, PHP shipped emergency fixes for two critical flaws that let an unauthenticated request run code on a server, flaws nicknamed PHP2Shell. According to a blog post by Gregory Alexander that reached the front page of Hacker News, every PHP configuration serving web requests was affected, including PHP-FPM, Apache's mod_php, php-cgi, FrankenPHP and LiteSpeed, with patched releases in 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Alexander's sites run on ColdFusion, not PHP. Yet when he tried to sign in to a test blog's admin panel, IIS answered with 403 Forbidden, explaining that multipart form-data requests had been blocked by a PHP mitigation. His hosting provider had reacted to the flaws with a server-wide URL Rewrite rule that rejected every request using that content type, the encoding browsers use for any form capable of uploading a file, across every site on the box regardless of what it ran. On his four ColdFusion sites, admin sign-ins and every image and file upload failed at once.

Blocking multipart requests was not PHP's own guidance, Alexander notes. The official advice was to install the patched versions and, until then, to disable session.upload_progress.enabled and lower post_max_size. Several of those mitigations concern upload handling, which likely explains the host's choice, but for non-PHP tenants the rule was pure collateral damage.

After he narrowed the rule to .php addresses, everything worked again. That raised the obvious question: why was PHP on the server at all? The answer was a phpMyAdmin install requested years earlier to manage one MySQL database, still present in a site folder with its login page open to the internet. A file sweep later found roughly 4,500 PHP files across two phpMyAdmin copies, including one at the web root that IIS's Default Web Site served to anyone visiting the server's bare IP address.

Four checks to audit a server

The post's detection procedure takes a few minutes with PowerShell:

First, check whether IIS hands .php files to PHP at all, by listing handler mappings filtered on the *.php path. IIS only runs PHP when a handler mapping such as FastCGI points to php-cgi.exe.

Second, sweep the web root for PHP files. Windows' own dir with /s /b is far faster than recursive PowerShell on servers full of uploaded images, and grouping results by folder reveals clusters quickly.

Third, don't trust a quiet process list. The absence of a running php-cgi.exe only means nobody has requested a PHP page recently, because IIS launches it on demand. The handler mapping is what matters.

Fourth, probe from outside. Requesting common paths such as phpmyadmin/, pma/ or info.php against your own domains shows what attackers see. Anything answering 200 deserves inspection, since bots work phpMyAdmin logins all day, and every attempt starts PHP and reaches the database.

He adds an important caveat: PHP files you don't recognize, especially ones sitting in upload or image folders or modified recently, should be treated as a possible intrusion. Attackers routinely drop small PHP web shells into upload directories, and listing the most recently changed files is part of the audit.

Removing PHP safely

The cleanup is ordered so every step can be undone:

• Snapshot the IIS configuration first with appcmd's backup command, which restores in a single line if anything goes wrong.
• Move phpMyAdmin and any other PHP application out of the web folders rather than deleting it, since its configuration may hold a database password. A desktop client over Remote Desktop, such as HeidiSQL or MySQL Workbench, replaces it without a public login page.
• Block the .php extension at the server level through request filtering, so such requests are rejected before any handler runs.
• Remove the handler mapping and its FastCGI entry.
• Uninstall PHP last, once nothing depends on it.

Once Alexander confirmed PHP was no longer in use, the host switched the blanket rule off. The post also covers how to keep a mitigation rule properly scoped if you must retain PHP, notes for Lucee on Linux under Apache, and a list of gotchas encountered along the way.

Why it matters

The story is a neat illustration of why unknown software is a liability even when nobody uses it. PHP that the administrator had forgotten about dictated the host's emergency response, and that response then broke four ColdFusion sites that run no PHP at all. Server-wide mitigations on shared infrastructure hit every tenant, whatever stack they actually run.

The underlying lesson is basic hygiene: know your handler mappings, sweep for stray files, and probe your own servers from the outside. Unused software cannot be patched on schedule, an internet-facing phpMyAdmin login is a permanent target for credential-stuffing bots, and removing what you don't need remains the cheapest security fix available.