Azure App Service Windows .NET Framework 4.8 returns phpVersion 5.6 although PHP is not configured – security exposure and supported remediation?

The supported action is to leave the platform PHP files and phpVersion value unchanged, verify whether IIS has an effective *.php handler, and restrict the SCM/Kudu endpoint; the public documentation does not establish that clearing the property or deleting the managed binary is supported.

What the observations establish

• phpVersion remains a defined Microsoft.Web/sites configuration property whose documented meaning is “Version of PHP.” The resource contract does not explain why 5.6 is returned for newly created .NET-only Windows apps, whether it is a legacy default, or whether it automatically installs a handler. ^1^
• Running php -v in Kudu proves that the executable is reachable from the privileged Kudu command environment. Microsoft explicitly documents Kudu as an authenticated companion application that can run commands and manage IIS processes; this does not by itself prove that the public IIS site routes *.php requests to that executable. ^2^
• IIS can process PHP only when a request path is mapped to FastCgiModule with a PHP CGI executable as its script processor. A FastCGI application definition alone does not automatically add that handler mapping. ^3^

Consequently, the property value and Kudu binary are not sufficient evidence of public PHP execution. The decisive control is the effective IIS handler mapping.

Verify public request handling without changing the runtime

1. In the Azure portal, open App Service → Settings → Configuration → Path mappings.
2. Inspect Handler mappings for an entry whose extension is *.php and whose script processor points to php-cgi.exe or another PHP executable. App Service documents these mappings as the mechanism that assigns extensions such as *.php to a script processor. ^4^
3. Inspect the deployed site/wwwroot/web.config, including any child application or directory web.config files, for:
   • <handlers> entries matching *.php
   • FastCgiModule
   • a scriptProcessor containing php-cgi.exe
   • <fastCgi> PHP application definitions
4. Check deployment scripts and site extensions for explicit PHP invocation. This matters because Kudu deployment automation can execute PHP tools such as Composer when configured to do so. ^5^
5. If configuration inspection is inconclusive, reproduce the app in a non-production slot and request a uniquely named .php test resource. Use IIS Failed Request Tracing to identify the module that handled it; a trace attributed to FastCgiModule establishes PHP/FastCGI dispatch. ^6^

Do not place a diagnostic PHP script in production. A missing PHP handler should result in PHP code not being executed, although the exact response can depend on other IIS/application routing rules.

Kudu/SCM exposure

Kudu command execution is a privileged management operation, not an anonymous application feature. Browser access through Microsoft Entra authentication requires a role containing Microsoft.Web/sites/publish/Action. ^2^

Apply these controls:

1. Disable SCM basic publishing authentication, retaining Microsoft Entra authentication:

      az resource update \
        --resource-group <resource-group> \
        --name scm \
        --namespace Microsoft.Web \
        --resource-type basicPublishingCredentialsPolicies \
        --parent sites/<app-name> \
        --set properties.allow=false
   

   Microsoft documents this as limiting SCM access to users registered with Microsoft Entra ID. ^7^
2. Use least-privilege RBAC for Kudu access; avoid broad Owner or Contributor assignments where a narrower role suffices. ^2^
3. Under App Service → Networking → Access restrictions, configure separate SCM site restrictions or select Use main site rules. App Service supports controlling Kudu/SCM independently from the public application. ^8^

Removal, clearing, and servicing status

PHP on Windows App Service reached end of support in November 2022; PHP is currently supported only on App Service Linux. ^9^

However, the public documentation supplied here does not document:

• phpVersion: "5.6" as a harmless legacy/default sentinel;
• a supported “clear PHP” value for Windows App Service;
• customer removal of the platform PHP binary;
• whether that remaining PHP 5.6.40 binary receives security backports after Windows PHP support ended.

App Service manages its OS and built-in application stacks and applies platform/runtime updates, but its patching documentation discusses automatic patching of supported language runtimes and does not specifically promise PHP 5.6 backports on Windows after retirement. ^10^

Therefore:

• Do not delete or replace files under the managed runtime directories.
• Do not set an invented PHP version or use the obsolete Windows PHP configuration examples as remediation.
• Remove only customer-controlled PHP handlers, PHP files, deployment scripts, or site extensions if discovered.
• Open an Azure support request for a Product Group statement covering the unexplained default/property semantics, platform-level removal, and post-EOL binary servicing. Include the app resource IDs, regions, OS/plan details, configuration JSON, effective handler mappings, and a staging-slot request trace.

References

1. Microsoft.Web sites 2023-12-01 (deployment-language-arm-template)
2. Kudu service overview
3. FastCGI <fastCgi>
4. Configure an App Service app
5. Configure a PHP app in Azure App Service (platform-windows)
6. Troubleshoot PHP errors with Failed Request Tracing
7. Tutorial: Create a secure N-tier app in Azure App Service
8. Set up Azure App Service access restrictions
9. Create a PHP web app in Azure App Service (platform-windows)
10. Azure App Service OS and runtime patching