PHP Site AuditHosting and runtime checks
How should Windows and IIS sites update PHP for PHP2Shell?
Identify the PHP build and handler assigned to each IIS site, install a vendor-supported fixed build, then recycle the applicable application pools and verify the web runtime. The PHP CLI binary may be a different build from the FastCGI binary serving IIS requests.
Map IIS sites to PHP builds
A Windows server can host multiple sites and PHP installations. IIS may route requests through FastCGI to a selected executable, while a terminal's php.exe comes from the system or user PATH. Ask the administrator to map each public hostname to its IIS application, FastCGI configuration, executable path, package source and worker pool. Include staging and any secondary site bindings that execute PHP.
PHP's Windows downloads are published through the PHP project, but Windows hosting providers may package or manage their own runtime. Use the matching vendor's release guidance, architecture and build type. PHP's downloads page explains Thread Safe and Non Thread Safe distinctions; it recommends NTS for IIS FastCGI and TS for Apache module use. Do not swap builds without checking the configured handler and extension compatibility.
Apply the fix through the supported channel
Use PHP's October 21 release notice and the related fixed-version guide for the upstream release list. A vendor may provide a backport or provider-specific package; ask for the Windows build or advisory that addresses both CVEs. Do not assume an older-looking version is vulnerable or fixed until the vendor confirms the package contents.
Have the administrator schedule the package change, update the IIS FastCGI mapping as required, recycle the relevant application pools, and confirm every web node received the same build. A file copy to one server or a CLI update can leave production traffic on an older FastCGI executable. Keep the prior package and configuration available for a controlled rollback, but make a risk decision before returning to an unpatched build.
Verify requests and compatibility
Use a controlled request to verify the web runtime through an access-restricted method, then remove temporary diagnostics. Check application logs, extensions, background tasks and representative user journeys after the pool recycle. For a farm or load-balanced service, verify each node or use deployment evidence that proves the rollout reached all nodes.
A public response header may be customized or hidden and cannot identify the executable path or patch contents. Keep the exact vendor advisory, package/build number, IIS mapping and recycle timestamp in the change record. This record is stronger than a screenshot of php -v from an administrator's workstation.
Common questions
Does IIS automatically use the newest PHP in PATH?
Not necessarily. FastCGI uses the executable configured for the site or handler.
Can I rely on a banner after the update?
Treat it as a response clue, not package-level proof or evidence for every node.
Does an IIS application-pool recycle patch PHP?
No. It activates a change already installed; it does not install the security update itself.