Does a Windows Azure API based on .Net have any PHP inside it?

Question

Does a Windows Azure API based on .Net have any PHP inside it?

Glyn Forster 0

I have not managed to find a definitive answer to this, could you confirm there is no PHP running inside a Windows OS Azure API App Service running either .Net or .Net Core stack?

If there is what is the timeline for the PHP patch issued yesterday to be applied?

Thanks

Glyn

0 comments

2 answers

Your answer

Answer 1

Hi @Glyn Forster

For a Windows Azure App Service running a .NET Framework or .NET (Core/.NET 6+) API, your application code does not execute PHP unless you have explicitly configured PHP handlers or deployed a PHP runtime yourself. The selected runtime stack determines how your application is hosted.

A few important distinctions:

If your App Service is configured as a**.NET / ASP.NET Core** application, requests are processed by the .NET runtime, not PHP.
Microsoft states that PHP on Windows App Service reached end of support in November 2022 and that PHP is now supported only on App Service for Linux.
Historically, Windows App Service could host PHP applications, but that required the site to be configured for PHP or a custom PHP runtime. It was not automatically involved in the execution path of a .NET application.

Regarding the PHP security patch released yesterday:

If your application is a Windows App Service running only a .NET stack, there is generally no PHP runtime involved in servicing your API, so a PHP patch would not normally be applicable to the application runtime.
Microsoft's App Service runtime policy states that the platform updates supported language stacks, but it does not guarantee specific patch deployment timelines for managed runtimes.
I could not find an official Microsoft statement specifying when a particular PHP patch would be rolled out across Azure App Service infrastructure.

If you need evidence for an audit or vulnerability assessment, you can verify the exact stack configured for the App Service:

az webapp config show \
 --resource-group <resource-group> \
 --name <app-name>

Check values such as:

"netFrameworkVersion": "v8.0" // example
"linuxFxVersion": null
"phpVersion": null

If phpVersion is not configured and the application is a .NET App Service, that is strong evidence that PHP is not part of the application's runtime configuration.

Thanks.

Glyn Forster 0 Reputation points

2026-10-22T09:09:32.6633333+00:00

Hi Senthil,

The Kudu checks the AI response listed below show that there is a install of PHP on the instance, but the 'tasklist' command produces no output (even if issued without the PHP filter).
Running the Kudu powershell and 'get-process' only returns cmd, powershell, tasklist, w3wp, w3wp so i take it this is evidence that PHP isn't running on the OS instance? My ASP.Net API doesn't make any use of it.
The PHP version is really old so i guess it is legacy from back when the Windows OS versions could run PHP stacks.

Regards

Glyn
Senthil kumar 2,915 Reputation points

2026-10-22T15:45:15.42+00:00

For additional confirmation, you can check:

PowerShell

where php

and

PowerShell

Get-ChildItem D:\home\site\wwwroot -Recurse -Filter *.php

Also inspect your App Service configuration:

Azure Portal → App Service → Configuration → General Settings

If the stack is set to**.NET / ASP.NET** and you have no .php files deployed, then the presence of the PHP binary is simply a platform artifact and not part of your application's execution path.

So based on the evidence you've provided:

PHP is installed on the underlying App Service environment.

PHP does not appear to be running.

Your ASP.NET API is being served by the IIS worker process (w3wp.exe).

The old PHP version visible in Kudu is very likely a legacy platform component rather than something your application is using

Answer 2

A Windows App Service configured for .NET does not use PHP to execute the .NET application, but the Windows worker can still contain PHP binaries, so verify binary presence and active use separately rather than asserting that no PHP exists anywhere on the worker.

Check whether PHP is present or used

In the Azure portal, open App Service → Development Tools → Advanced Tools → Go.
In Kudu, select Debug console → CMD and run:

php --version
where php
tasklist | findstr /i php

Microsoft documents php --version as the way to query the PHP runtime on a Windows App Service instance.^1^

Interpret the results as follows:

php is not recognized: PHP is not available through the worker's command path.
A version is returned, but no PHP process exists: PHP binaries are present, but this does not show that your application is executing PHP.
php-cgi.exe or another PHP process exists: determine what started it and whether it handles requests.

Also inspect:

App Service → Configuration/Stack settings: confirm the selected stack is .NET or .NET Core.
Kudu → Debug console → site\wwwroot: look for .php files.
The deployed web.config: look for PHP/FastCGI handler mappings or commands that start PHP.
Application startup scripts and any site extensions.
If using a custom Windows container, inspect its Dockerfile and image packages; Microsoft does not update custom runtimes that customers upload.^1^

Windows App Service supports multiple framework components in its platform baseline, and application code can start child processes. Therefore, selecting .NET identifies the application stack but is not proof that no PHP binary exists on the underlying worker.^2^

Applicability of CVE-2026-109618 and CVE-2026-109619

Microsoft describes these as critical PHP remote-code-execution issues and advises upgrading PHP; Azure network protections complement patching rather than replacing it.^3^

For your application, the important distinction is:

PHP merely installed: this alone does not establish that the vulnerable PHP request-processing path is reachable.
PHP configured as an IIS/FastCGI handler or launched by the application: treat the CVEs as potentially applicable and compare php --version with the fixed versions identified by the PHP advisory.
Pure .NET deployment with no PHP files, handler mappings, startup commands, or PHP processes: PHP is not part of the application’s execution path, although platform binaries may still be installed.

PHP on Windows App Service reached end of support in November 2022; Microsoft supports PHP on App Service only on Linux.^4^ Consequently, an old Windows PHP installation should not be assumed to receive a current PHP security fix.

Patch timing

No public completion date or rollout ETA is identified for these CVEs on Windows App Service. For supported built-in runtimes, App Service normally applies PHP patch updates automatically by overwriting the existing installation. Significant vulnerabilities are handled case by case, and deployments can be slowed or paused to prevent outages.^1^

If the checks show that your application actually depends on PHP:

Windows built-in PHP: migrate to a supported Linux PHP App Service or a maintained custom container; do not rely on an unsupported Windows PHP runtime.
Linux built-in PHP: check the effective version and, if available for the app, select Stack settings → Platform Release Channel → Latest for the fastest platform runtime updates. This release-channel setting applies only to Linux.^1^
Custom container: rebuild it with a fixed PHP release and redeploy. App Service does not patch customer-supplied runtimes.
Need formal confirmation for a specific worker or ASE: open an Azure support request with the app resource ID, region, OS, Kudu php --version output, and whether it is multitenant or ASE. The hosting model can be identified from the App Service plan: ASE plans use the Isolated v2/v4 tiers, while public multitenant App Service uses Free through Premium tiers.^5^

References