Securing PHP on Windows and IIS

In short: On Windows with IIS, PHP usually runs as php-cgi.exe via FastCGI, an operating mode that PHP2Shell explicitly affects. A PHP IIS update consists of three steps: find all PHP installations, replace them with a fixed version and recycle the application pools. Package management and backports as on Linux generally do not exist here.

How PHP runs under IIS

On Windows servers, IIS connects PHP through the FastCGI module. For each PHP version there is a FastCGI entry that points to a php-cgi.exe, and a handler mapping that routes files ending in .php there. IIS starts several php-cgi processes as needed and keeps them active for further requests.

Unlike on Linux, PHP here usually does not come from a package manager but as a ZIP archive of the PHP project's Windows builds, as part of a business application or through older installers. That means updates do not happen automatically, and there are no backports from a distributor. The version number of the installed files is what counts.

What PHP2Shell means for Windows servers

PHP2Shell covers CVE-2026-109618 and CVE-2026-109619 in PHP itself, each with CVSS v4.0 9.2. Both allow code execution without logging in. The PHP project explicitly names php-cgi among the affected operating modes. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

For PHP 8.1 and older there are no more official updates. In our experience, Windows servers with business applications often run on such versions because the application requires a particular version. Here, besides the interim measures, clarification with the application's manufacturer is needed. Background on this operating mode is under php-cgi: Legacy with risk.

PHP IIS update: finding installations

The following PowerShell commands only read. They show which PHP installations IIS uses and which version they have. Paths are examples.

# FastCGI entries in IIS: which php-cgi.exe is used?
& "$env:windir\system32\inetsrv\appcmd.exe" list config -section:system.webServer/fastCgi

# Version of each installation found (path as an example)
& "C:\PHP\8.3\php.exe" -v

# Running php-cgi processes with start time
Get-Process php-cgi -ErrorAction SilentlyContinue | Select-Object Id, StartTime, Path

Also search all drives for further php-cgi.exe files, because business applications sometimes bring their own copies. For each installation, note the version, the variant (Thread Safe or Non Thread Safe) and the architecture.

Apply the update and recycle application pools

Download the fixed version from the PHP project's official Windows builds linked from php.net, in the same variant and architecture. It has proven useful to unpack the new version into a new folder, carry over the existing php.ini and the required extensions, and then switch the FastCGI entry to the new path. That way the old state is kept for a way back.

# Recycle an application pool (name as an example)
Import-Module WebAdministration
Restart-WebAppPool -Name "Intranet"

# Alternatively, restart all IIS services
iisreset

# Check: were all php-cgi processes started after the update?
Get-Process php-cgi -ErrorAction SilentlyContinue | Select-Object Id, StartTime, Path

Every php-cgi process must have a start time after the update and point to the new path. Test the websites afterwards. Remove the old PHP folder as soon as the new state runs stably, so that it is not linked in again by accident.

Interim measures in php.ini

If an installation cannot be updated immediately, php.net recommends interim measures without complete protection. Under IIS, you set the values in the central php.ini of the respective installation. According to php.net, .user.ini files and ini_set() are not sufficient.

; php.ini of the affected installation
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M

With an upload function, php.net gives post_max_size = 32M. On PHP 8.5, fatal_error_backtraces=0 is added. So that websites cannot change the values through their own .user.ini files, user_ini.filename can be set to empty in the central php.ini; check beforehand whether applications depend on it. Then recycle the pools. The BSI recommends taking web servers off the network temporarily if the update is not possible immediately. Further settings are explained in Configuring php.ini securely.

After the update

A patch does not remove malware that was planted earlier. Keep the IIS logs from 20 October 2026 onward, check web directories for new script files and check scheduled tasks and local user accounts for anything unknown. If the server runs in a domain, a look at logons is part of it too.

Also pay attention to the permissions of the application pool identities. If a pool runs with an account that has write permissions on the entire web directory or even administrative rights, an attacker can do considerably more damage after a successful break-in. A separate, restricted identity per pool makes sense, with write permissions only where the application really needs them, for example in the upload or cache folder. In these folders, IIS should not execute PHP files; this can be controlled through the handler mappings of the respective folder. Also check whether old test and installation files such as phpinfo outputs are in the web directory, and remove them.

How does PHP SOS help?

• We find all PHP installations on your Windows servers, including copies inside business applications.
• Through the PHP patch service, we swap PHP, recycle the pools and document version and process times.
• For old versions, we work out with you and the application manufacturer the path to migration to a supported PHP version.
• We check the servers for traces of an attack and preserve the logs.

Frequently asked questions

Sources

• php.net: Security announcements
• PHP 8 ChangeLog
• php.net: Supported versions
• BSI (German Federal Office for Information Security)