Azure App Service PHP2Shell status: what Microsoft says

Microsoft's own notice, dated 21 October 2026, says the built-in PHP images on Azure App Service for Linux were updated to PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, with the rollout complete on the Latest and Standard channels. Extended trails, Windows built-in PHP gets no patch, and custom containers are yours. Open an SSH session and run php --version.

What did Microsoft say about PHP2Shell, and when?

Microsoft published one App Service notice, titled "Critical PHP security release: what it means for Azure App Service", on 21 October 2026. We read it on 26 October 2026. It gives the four updated PHP versions above, describes the rollout by channel, and lists actions for Linux, Windows, WordPress and custom containers.

The sentence that matters is this one: "We have completed the rollout of the updated built-in PHP images with the security fixes to both the Latest and Standard Platform Release Channels for Azure App Service on Linux." It carries an update line dated 21 October 2026. Microsoft's 22 October post about Node.js and Python links to the PHP notice as a separate release.

Our host-matrix research on 22 October recorded Azure as "unknown". That was before we found this notice. The status changed from unknown to a vendor statement, and a vendor statement about a platform is still not evidence about your app.

At our check, the Azure status history showed no PHP incident. An empty status page tells you nothing about patch state, so we do not read it as either answer.

Which App Service setups does the notice cover?

Not all of them. The table lists each setup, what Microsoft's notice says, and what is left for you.

For the Windows row, Microsoft's PHP configuration page already says PHP on Windows reached end of support in November 2022 and that PHP is supported only for App Service on Linux.

Why can an App Service app still be unpatched?

Four reasons come from Microsoft's own pages.

The Extended channel. App Service lets Linux apps choose how fast runtime patches arrive. The Platform Release Channel has three settings, and Standard is the default. Extended "typically stays one release behind Standard", and the PHP notice tells Extended customers to move. If someone chose Extended for stability, the app may still run the old build.

End-of-life PHP. A built-in 8.1 or older runtime gets no fix from Microsoft. The PHP project shipped source backports for 7.4, 8.0 and 8.1 on GitHub, and the PHP notice names them, but a built-in image is whatever Microsoft ships. See PHP 8.1 and older after PHP2Shell.

Custom runtimes and containers. Microsoft's patching page says a custom runtime you upload "remains unchanged unless you manually upgrade it". A container built last month still has last month's PHP. The Docker official php image lists the fixed tags for Debian and Alpine, and the rebuild steps are in PHP2Shell and Docker images.

Mixed environments. Microsoft's SSH page says the CLI connects to one instance by default. A scaled-out app has several instances, and each deployment slot is separate.

How do I check my App Service app?

A passive look from outside cannot do this, because the PHP version is rarely exposed and the serving runtime is hidden behind the platform. The check happens inside the app container.

How do I read the PHP version?

Microsoft's instruction in the PHP notice is to open an SSH session to the app and run php --version. The SSH page gives the path: in the Azure portal, open the app, go to Development Tools, select SSH, then Go. The patching page also lists the Kudu console at https://<appname>.scm.azurewebsites.net/DebugConsole for the same command.

On a built-in image, Microsoft's table lists the upstream numbers as the updated versions. A version at or above 8.2.35, 8.3.36, 8.4.27 or 8.5.12 on its branch is therefore useful evidence, which is not true on a Debian or Ubuntu server where backports keep the old number. That reasoning stops at the built-in image. A custom container built on a distribution package can show an older number and still carry a backport, so read its package changelog instead.

The command-line php is the binary you run in the shell. The notice does not say it is the binary behind the web server, and it does not mention a restart or recycle after the update. Those two gaps are why the strongest evidence comes from Microsoft in writing.

What does az webapp config show tell me?

Less than people expect. Microsoft's PHP page shows az webapp config show --resource-group <group> --name <app> --query linuxFxVersion. It returns the runtime line you configured, such as PHP|8.3. That is the branch. It does not name a build or a fix date.

Which Platform Release Channel is my app on?

In the Azure portal, open the app, select Stack settings, and read Platform Release Channel. The channel can be changed there. The channel announcement gives the CLI form az webapp update --platform-release-channel Standard. The channel setting is Linux only.

Checklist for App Service owners

• Note whether each app runs on Linux or Windows
• For Linux built-in apps, read the Platform Release Channel under Stack settings
• If it says Extended, move to Standard or Latest
• Run php --version over SSH on every instance and write down the result with the date
• Repeat for every deployment slot, including staging
• Compare the result with 8.2.35, 8.3.36, 8.4.27 or 8.5.12 for built-in images
• For custom containers, rebuild from a base image that carries the fix and redeploy
• Send the question below if you need written confirmation

What do I ask Microsoft support?

For [app name, subscription, region], is the PHP runtime that serves web requests patched for CVE-2026-109618 and CVE-2026-109619? Please give the built-in image or build identifier on each instance, say which Platform Release Channel the app is on, confirm that the PHP worker processes serving it were restarted or replaced after the fix, and tell me whether I need to restart, redeploy or change a setting.

Microsoft's patching page says that for security reasons certain specific security information is not published. Support may not give a build identifier. Keep whatever it does give you, with the date.

What does the rollout look like in time?

Was anything exploited on Azure App Service?

We found no statement from Microsoft about exploitation of App Service apps. The notice we read does not address it.

Across the internet, AWS reported attempts against its honeypots from 17 October, four days before disclosure, and says it is unclear whether those early attempts would have worked on real systems. It reports further attempts from several sources on 21 October after proof-of-concept code appeared (AWS Security Blog). At our check on 24 October, we could not see either CVE in the first page of the CISA catalog view; search it by CVE id before relying on that.

If your app ran an unpatched PHP between 17 October and its fix, look for PHP files you did not upload under the app's content folder, scheduled jobs you did not create, new administrator accounts, and unexpected outbound connections. A patch does not remove anything planted before it. The full compromise check for a PHP2Shell hit walks through the steps.

Does a firewall in front of App Service fix it?

It can lower exposure. It does not change the PHP in the container. We found no Microsoft rule published for these CVEs, so we cannot say one exists. Our page on whether a WAF stops PHP2Shell covers what a rule can and cannot see.

What is the bug, without the exploit?

Both CVEs are memory-safety problems in the PHP engine, reachable by an unauthenticated web request. The advisory for CVE-2026-109618 describes an out-of-memory condition that leaves request memory in an invalid state, with remote code execution validated over HTTP against mod_php. CVE-2026-109619 is state left over between requests handled by the same worker. The PHP project says all installations serving web requests are in scope, so a PHP app on App Service is in scope until its runtime is fixed. We do not reproduce exploit material.

Is there another PHP issue to watch?

Yes, a separate one. On 23 October 2026 the PHP project posted a follow-up notice for CVE-2026-115560, recommending session.upload_progress.enabled=0 until the next bugfix release, with a full advisory to follow. It is a different issue from the two PHP2Shell CVEs. Microsoft's PHP page describes setting php.ini directives on Linux through a custom .ini file and the PHP_INI_SCAN_DIR app setting; the PHP notice says to set this one in php.ini or pool configuration, never with ini_set(). We will update this page when the PHP advisory is published.

The wider October picture is in the October 2026 security meltdown tracker. If you run PHP on other clouds too, the same question for Google Cloud and AWS Lightsail is answered separately, and the other host status checks are collected in one place. Then inventory every PHP runtime serving your business, and see who is responsible for patching your website when it is unclear whether the platform or you own a step.