--- title: "Is PHP Quietly Running on Your ColdFusion Server? How to Check, and Remove It" slug: is-php-quietly-running-on-your-coldfusion-server-how-to-check-and-remove-it url: https://listedarticles.com/articles/is-php-quietly-running-on-your-coldfusion-server-how-to-check-and-remove-it canonical_url: https://www.gregoryalexander.com/blog/2026/10/23/is-php-quietly-running-on-your-coldfusion-server-how-to-check-and-remove-it content_type: tutorial language: en published_at: 2026-10-23T23:39:00.000Z updated_at: 2026-10-27T02:09:56.628Z author: "Gregory Alexander" authored_by: human publisher: "Gregory Alexander" publisher_url: https://www.gregoryalexander.com/blog/ topics: ["Security", "Web Development"] license: all-rights-reserved word_count: 1906 reading_minutes: 8 citation: "Gregory Alexander, Gregory Alexander. \"Is PHP Quietly Running on Your ColdFusion Server? How to Check, and Remove It.\" 23 Oct 2026. https://www.gregoryalexander.com/blog/2026/10/23/is-php-quietly-running-on-your-coldfusion-server-how-to-check-and-remove-it (all-rights-reserved)" # The full text follows. The web page shows an extract and sends readers # to the source above; quote the citation and link the canonical URL. --- # Is PHP Quietly Running on Your ColdFusion Server? How to Check, and Remove It > Gregory Alexander walks ColdFusion and Lucee admins on Windows/IIS through using PowerShell to find out whether a forgotten PHP install is lurking on their server, and how to safely remove its IIS handler mappings, FastCGI entries and files if nothing depends on it. # Is PHP Quietly Running on Your ColdFusion Server? How to Check, and Remove It by [Gregory Alexander](https://www.gregoryalexander.com/blog/postedby/Gregory_Alexander) ![](https://www.gregoryalexander.com/blog/enclosures/phpBug.jpg) If you run ColdFusion or Lucee on a Windows server with IIS, and you've never installed PHP on purpose, this one's for you. There's a good chance PHP is on your server. It may be left behind by a control panel, a phpMyAdmin install from years ago, or your host's setup image. Here's how to find out in a few minutes with PowerShell, and how to remove it safely if nothing uses it. I remember when I could go years without applying a security fix. Now it feels like I'm chasing something down every few weeks: a patch here, a mitigation there, a bot hammering a page that shouldn't exist. Such is life in the AI era, sigh. While I was signing in to my test blog the other day, the admin page refused me with a plain IIS error: **403 Forbidden**, and a message saying multipart form-data requests were blocked by a PHP mitigation. My blogs are ColdFusion. They don't run a single line of PHP. So why was a PHP security rule stopping me from signing in? ## Table of Contents - [What happened](#what-happened) - [Check 1: is IIS sending .php files to PHP?](#check-1-is-iis-sending-php-files-to-php) - [Check 2: are there any PHP files in your sites?](#check-2-are-there-any-php-files-in-your-sites) - [Check 3: is PHP installed or running?](#check-3-is-php-installed-or-running) - [Check 4: what can the internet see?](#check-4-what-can-the-internet-see) - [Removing it safely](#removing-it-safely) - [1. Back up IIS's configuration](#1-back-up-iis-s-configuration) - [2. Move phpMyAdmin (and any other PHP app) out of the web folders](#2-move-phpmyadmin-and-any-other-php-app-out-of-the-web-folders) - [3. Block .php at the door](#3-block-php-at-the-door) - [4. Remove the handler and the FastCGI entry](#4-remove-the-handler-and-the-fastcgi-entry) - [5. Uninstall PHP, last](#5-uninstall-php-last) - [If you need to keep a rule like this](#if-you-need-to-keep-a-rule-like-this) - [Lucee on Linux and Apache](#lucee-on-linux-and-apache) - [Gotchas](#gotchas) - [Further Reading](#further-reading) --- ## What happened --- The timing wasn't a coincidence. On October 21, 2026, PHP shipped emergency patches for two critical flaws that let an unauthenticated request run code on the server, nicknamed **PHP2Shell**. 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 a new version of PHP (8.5.12, 8.4.27, 8.3.36 or 8.2.35). My hosting company responded the same week with a web server security rule. The rule lived in IIS's server-wide URL Rewrite rules, so it applied to every site on the server and blocked every request whose content type was multipart/form-data, regardless of the address. That's the encoding a browser uses for any form that can upload a file, and plenty of forms use it even when they don't. PHP's own advice doesn't include blocking those requests. It's to patch, and until then to turn off `session.upload_progress.enabled` and lower `post_max_size`. Several of the official mitigations concern how PHP handles uploads, so I can see why a host would reach for the biggest hammer. For a PHP site that's a blunt but understandable shield. For my ColdFusion sites it meant the admin sign-in form, every image upload and every file upload failed on all four sites at once. The rule matched *every* address, not just `.php` ones. Once I'd scoped the rule to `.php` addresses (more on that below), everything worked again. Then I asked the obvious question: why is PHP on this server at all? The answer was a phpMyAdmin install I had asked for years ago to manage one MySQL database. It was still there, still in a site folder, and its login page was open to the whole internet. The host turned the blanket rule off once I told them PHP was no longer in use, and I went looking for anything else PHP had left behind. --- ## Check 1: is IIS sending .php files to PHP? --- IIS only runs PHP if a handler mapping tells it to. Open PowerShell **as Administrator** on the server: ``` Import-Module WebAdministration Get-WebHandler -PSPath 'IIS:\Sites' | Where-Object { $_.path -like '*.php' } | Select-Object name, path, scriptProcessor ``` If it prints nothing, IIS doesn't run PHP. If it prints something like this, it does, for every site that inherits the server's settings: ``` name path scriptProcessor ---- ---- --------------- FastCGI *.php C:\php\php-cgi.exe ``` Note the handler's `name` and the `scriptProcessor` path. You'll need both if you remove it. --- ## Check 2: are there any PHP files in your sites? --- PowerShell's `Get-ChildItem -Recurse` works, but on a server with years of uploaded images it can crawl for minutes. Windows' own `dir` is much faster. This counts the PHP files under your web root: ``` cmd /c "dir C:\inetpub\wwwroot\*.php /s /b" 2>$null | Measure-Object | Select-Object Count ``` If the count isn't zero, this shows which folders they're in, busiest first: ``` cmd /c "dir C:\inetpub\wwwroot\*.php /s /b" 2>$null | ForEach-Object { Split-Path $_ -Parent } | Group-Object | Sort-Object Count -Descending | Select-Object -First 25 Count, Name | Format-Table -AutoSize ``` Mine found about 4,500 files in two folders, both phpMyAdmin: one inside a site, and a second copy at the web root, which IIS's Default Web Site served to anyone who visited the server's bare IP address. If you find PHP files you *don't* recognize, especially scattered through image or upload folders, or changed recently, stop and treat it as a possible break-in. Attackers love dropping small PHP "web shells" into upload folders. This lists the most recently changed ones: ``` cmd /c "dir C:\inetpub\wwwroot\*.php /s /b" 2>$null | Get-Item | Sort-Object LastWriteTime -Descending | Select-Object -First 15 LastWriteTime, Length, FullName | Format-Table -AutoSize ``` --- ## Check 3: is PHP installed or running? --- ``` Get-Process php* -ErrorAction SilentlyContinue | Select-Object Name, Id, StartTime Test-Path C:\php ``` No `php-cgi.exe` process just means nothing has asked for a PHP page recently. IIS starts it on demand. The handler from Check 1 is what matters. --- ## Check 4: what can the internet see? --- From any computer, try the usual addresses on **your own** sites: ``` foreach ($path in "phpmyadmin/", "phpMyAdmin/", "pma/", "info.php") { $url = "https://www.mysite.com/$path" try { $r = Invoke-WebRequest $url -UseBasicParsing -TimeoutSec 15; "$($r.StatusCode) $url" } catch { "$($_.Exception.Response.StatusCode.value__) $url" } } ``` Anything that answers 200 deserves a look. A phpMyAdmin login page facing the internet is a standing invitation: bots try passwords on it all day, and every attempt starts PHP and talks to your database. --- ## Removing it safely --- Do these in order, and back up first. Every step is reversible. ### 1. Back up IIS's configuration IIS can snapshot its own configuration and restore it in one command: ``` & "$env:windir\System32\inetsrv\appcmd.exe" add backup "before-php-removal" ``` To undo everything below: `appcmd.exe restore backup "before-php-removal"`. ### 2. Move phpMyAdmin (and any other PHP app) out of the web folders Move, don't delete. Its configuration file may hold a database password, so keep it somewhere private for a few weeks in case something turns out to need it: ``` New-Item -ItemType Directory -Force C:\Temp\removed-php | Out-Null Move-Item C:\inetpub\wwwroot\mysite\phpmyadmin C:\Temp\removed-php\phpmyadmin-mysite ``` If `Move-Item` complains that a file is in use, PHP has it open. `iisreset /stop`, move it, then `iisreset /start`. (Your sites are down for a few seconds.) And if it says *"Could not find a part of the path"*, it's the destination folder that's missing, not the source. That one fooled me. For managing MySQL afterwards, a desktop tool on the server over Remote Desktop, like HeidiSQL or MySQL Workbench, does everything phpMyAdmin did without a public login page. ### 3. Block .php at the door IIS's request filtering can turn away a file extension before any handler sees it. Added at the server level, it covers every site: ``` Add-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter 'system.webServer/security/requestFiltering/fileExtensions' -Name '.' -Value @{ fileExtension = '.php'; allowed = 'false' } ``` Now any `.php` address gets *"404 - the request filtering module is configured to deny the file extension"*, whether the file exists or not. ### 4. Remove the handler and the FastCGI entry Use the handler name from Check 1 (mine was `FastCGI`) and the `php-cgi.exe` path: ``` Remove-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter 'system.webServer/handlers' -Name '.' -AtElement @{ name = 'FastCGI' } Remove-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter 'system.webServer/fastCgi' -Name '.' -AtElement @{ fullPath = 'C:\php\php-cgi.exe' } ``` Run Check 1 again. It should print nothing. ### 5. Uninstall PHP, last If PHP came from an installer, remove it under Apps > Installed apps. If it's just a folder like `C:\php`, rename it to `C:\php-removed` for a few weeks before deleting it. If anything complains, you'll know right away, and it's one rename to put back. If PHP was installed by your host, ask them before step 5. Their own monitoring scripts are unlikely to need it, but it's their install. --- ## If you need to keep a rule like this --- Maybe you do run PHP somewhere, or your host wants their rule. Then scope it to PHP addresses instead of every address. The rule's `` was the whole problem. This changes it to `.php` addresses only, leaving ColdFusion's forms alone (use the rule's own name): ``` Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter "system.webServer/rewrite/globalRules/rule[@name='PHP Mitigation']/match" -Name url -Value '\.php($|/)' ``` Note the single quotes around the pattern. I first tried the same change with `appcmd.exe`, and PowerShell quietly mangled the quoting: no error, and no change either. `Set-WebConfigurationProperty` with single quotes did it on the first try. Check the result with `Select-String` on `C:\Windows\System32\inetsrv\config\applicationHost.config`. --- ## Lucee on Linux and Apache --- The same questions, different commands: ``` php -v ## is the PHP command-line installed? apachectl -M | grep -i php ## is Apache running PHP (php_module, proxy_fcgi to php-fpm)? find /var/www /home -name "*.php" 2>/dev/null | head -50 ``` On Debian and Ubuntu, `sudo a2dismod php8.3` (your version) and `sudo systemctl restart apache2` stop Apache from running PHP. Then remove the packages with your package manager once you're sure nothing needs them. Control panels such as Virtualmin often install PHP for their own tools, so check before uninstalling. --- ## Gotchas --- - **A server-wide rule catches every site.** A rule written for PHP blocked my ColdFusion sign-ins and uploads. If a 403 appears out of nowhere, read the full IIS error page; mine named the rule. - **Hosts re-run their scripts.** Mine recreated its rule on every run, so a local fix could have been undone silently. Tell your host what you changed and why. - **A config edit can land in the wrong `web.config`.** My first fix went into a site's `web.config`, and nothing changed. A quick `Select-String` on the file IIS actually reads would have saved me ten minutes. - **Trusted Cache hides your fixes.** If you replace a `.cfm` by hand while diagnosing, ColdFusion keeps running the old compiled copy until you clear it. A brand-new file name is the quick workaround. - **Removing PHP isn't a substitute for patching.** If you do run PHP, update it now to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or newer), and set `session.upload_progress.enabled = 0` in `php.ini` until you can. PHP 8.1 and older no longer get updates from the PHP project. Removing PHP is only the right answer when nothing uses it. --- ## Further Reading --- - PHP's announcements for October 2026, including the October 21 security releases and their mitigations: [php.net news archive, 2026](https://www.php.net/archive/2026.php) - BleepingComputer: [PHP ships emergency patches for critical PHP2Shell flaws](https://bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws) - PHP on Windows has been here before. DEVCORE's alert for the 2024 PHP-CGI flaw: [Security Alert: CVE-2024-4577, PHP CGI Argument Injection Vulnerability](https://devco.re/blog/2024/06/06/security-alert-cve-2024-4577-php-cgi-argument-injection-vulnerability-en/) - Charlie Arehart: [ColdFusion Lockdown/Security guides - there are several, and some you may have missed](https://www.carehart.org/blog/2014/6/24/ColdFusion_Lockdown_Security_guides). Old, but still the best map of the lockdown guides, and it points at IIS request filtering. - Adobe's lockdown guides: [ColdFusion 2025 Lockdown Guide](https://helpx.adobe.com/content/dam/help/en/coldfusion/coldfusion-2025-lockdown-guide-v1.0.pdf) and [ColdFusion 2023 Lockdown Guide](https://www.adobe.com/go/cf2023_lockdown_guide) (PDFs) - Microsoft's IIS reference: [File Name Extensions (request filtering)](https://learn.microsoft.com/en-us/iis/configuration/system.webserver/security/requestfiltering/fileextensions/), [Handlers](https://learn.microsoft.com/en-us/iis/configuration/system.webserver/handlers/) and [FastCGI](https://learn.microsoft.com/en-us/iis/configuration/system.webserver/fastcgi/)