Web App for Containers: PHP Version Mismatch — Live Site Shows Older PHP Version

Question

Web App for Containers: PHP Version Mismatch — Live Site Shows Older PHP Version

Mike Hudgell - Lead Volunteer 0

Microsoft WordPress on Azure App Service — Managed PHP 8.4 image channel not receiving security updates

Problem description

We identified that our WordPress on Azure App Service installation was running PHP 8.4.16 despite being configured to use Microsoft's managed PHP 8.4 WordPress image.

This became a particular concern following the disclosure of the critical PHP2Shell vulnerabilities on 21 October 2026.

Although Microsoft had published an updated WordPress container containing PHP 8.4.27, the managed :8.4 channel continued to resolve to an image built in January 2026.

We have now successfully deployed the patched version manually, but this has raised concerns about the security-update mechanism for Microsoft's managed WordPress offering.

Environment

Azure App Service for Linux
Official Microsoft WordPress on App Service container
Image: mcr.microsoft.com/appsvc/wordpress-debian-php
PHP version: 8.4
No custom Dockerfile or startup command
Persistent App Service storage enabled
Azure Database for MySQL Flexible Server

Investigation

The App Service was originally configured with:

docker|mcr.microsoft.com/appsvc/wordpress-debian-php:8.4

However, the Azure container startup logs from 21 October 2026 showed App Service resolving this to:

appsvc/wordpress-debian-php:8.4_20260113.8.tuxprod

The production website returned:

X-Powered-By: PHP/8.4.16

Attempts to pull the floating :8.4 image directly from the public Microsoft Container Registry failed with:

manifest unknown: manifest tagged by "8.4" is not found

This suggests the managed :8.4 channel uses an internal Azure image mapping rather than a publicly accessible mutable Docker tag.

Resolution

We identified and tested the following Microsoft image:

mcr.microsoft.com/appsvc/wordpress-debian-php:8.4_20261021.5.tuxprod

Running the image locally confirmed:

PHP 8.4.27 (cli) (built: Oct 21 2026 14:18:04)

We then explicitly changed the App Service linuxFxVersion to reference this dated image and restarted the application.

Following the restart, the production website reported:

X-Powered-By: PHP/8.4.27

The immediate PHP version issue is therefore resolved.

Outstanding concern — managed security updates

Microsoft Support confirmed that explicitly pinning a dated image is supported, but doing so disables automatic advancement to subsequent WordPress/PHP container images.

We therefore face two options:

Remain on the Microsoft-managed :8.4 channel, which was still resolving to an outdated PHP version when we investigated.
Pin to a patched image, taking responsibility for identifying and deploying future security updates ourselves.

Neither is ideal for customers expecting Microsoft-managed security maintenance.

Questions for the Azure WordPress engineering team

Why was the managed PHP 8.4 channel still resolving to 8.4_20260113.8.tuxprod on 21 October 2026 when newer images were available?
What is Microsoft's expected security-patching schedule for the managed WordPress PHP images, particularly for critical vulnerabilities?
Is there a supported API, CLI command or published endpoint to determine which dated image the managed :8.4 channel currently resolves to?
Is there a supported notification mechanism when the managed channel advances to a newer image?
Can Microsoft confirm when the managed :8.4 channel will include PHP 8.4.27 or later, allowing us to return to automatic image updates?

We would prefer to remain on Microsoft's supported, automatically maintained WordPress image channel rather than permanently manage dated image versions ourselves.

The immediate security issue has been addressed, but clarification of the managed update mechanism would be valuable to other WordPress on Azure App Service customers.

Praneeth Maddali 12,670 Reputation points Microsoft External Staff Moderator

2026-10-21T19:54:30.06+00:00

Hi @Mike Hudgell - Lead Volunteer

Thank you for contacting us about the issue. We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this.
David 0 Reputation points

2026-10-21T20:02:36.8266667+00:00
Same issue here, and adding one finding that may help others: switching the Platform Release Channel to Latest delivered the patched image without pinning a dated tag.

Environment

Azure App Service for Linux, single instance

Microsoft WordPress on App Service container

linuxFxVersion: DOCKER|mcr.microsoft.com/appsvc/wordpress-debian-php:8.4

No custom Dockerfile or startup command

Platform Release Channel: Standard (default) until today

What we saw

WordPress Site Health and php-fpm -v both reported PHP 8.4.16 (fpm-fcgi, built Jan 12 2026). Nothing had updated since January, including the July and September PHP security releases.

What we did (21 Oct 2026, times UTC)

~19:20: changed Platform Release Channel from Standard to Latest and restarted. php -v reported PHP 8.4.27 (built Oct 21 2026 14:18:04), which matches the 8.4_20261021.5.tuxprod image you identified.

Switched back to Standard, on the basis that Latest isn't recommended for production. The app restarted and the new container's php-fpm (started 19:27) was back on 8.4.16, built Jan 12 2026. So as of this evening, Standard still maps :8.4 to the January build.

Switched back to Latest. Site Health now reports PHP 8.4.27.

So for anyone on the managed :8.4 image: the Latest channel gets you 8.4.27 today while keeping the managed tag and automatic updates, rather than pinning to a dated image and taking on patching yourself.

This makes the core question more pressing. Why has the Standard channel, the default and the one Microsoft recommends for production, been mapping :8.4 to a January 2026 build for nine months, and when will Standard move to 8.4.27? We're staying on Latest until Microsoft can confirm this.
Hemant Bharadwaj 0 Reputation points Microsoft Employee

2026-10-21T20:52:59.9+00:00
Your testing indicates that this is a Platform Release Channel mapping issue, rather than App Service pulling a public mutable :8.4 tag from MCR.

The relevant evidence is:

Standard resolved the managed PHP 8.4 channel to 8.4_20260113.8.tuxprod.

Latest resolved the same managed channel to 8.4_20261021.5.tuxprod, containing PHP 8.4.27.

Switching back to Standard returned the app to PHP 8.4.16.

Pulling mcr.microsoft.com/appsvc/wordpress-debian-php:8.4 directly failed because the managed channel is not exposed as a normal public mutable tag.

This means changing linuxFxVersion to a dated image and changing the Platform Release Channel solve different problems:

Pinning the dated image gives deterministic deployment of the patched build, but you must monitor and deploy subsequent images yourself.

Using Latest retains the managed image reference and currently delivers the patched image, but it also adopts platform updates earlier than Standard. It should be tested in a staging slot before production use.There does not appear to be a documented public API that returns the dated image currently selected by the internal Standard or Latest channel mapping. The effective version should therefore be verified after a restart by checking the container-start logs and the PHP version inside the running container.

Because Standard was still selecting the January image while Latest selected the October image, the remaining questions—why Standard had not advanced, its expected patching schedule, and when it will receive PHP 8.4.27—require confirmation from the App Service/WordPress product team. They cannot be determined from the public MCR catalog.

Recommended production approach:

Keep the known patched dated image, or use Latest after staging validation.

Record the current linuxFxVersion and Platform Release Channel setting.

Add an automated check of php -v or the container digest after deployments and restarts.

Open an Azure support request referencing the region, App Service stamp, both resolved dated-image names, and the timestamps of the Standard/Latest tests.

Return to Standard only after confirming that a newly started Standard-channel instance receives the patched build.

References:

Configure a custom container for Azure App Service

Create WordPress on App Service
Praneeth Maddali 12,670 Reputation points Microsoft External Staff Moderator

2026-10-21T21:32:45.6133333+00:00

HI @Mike Hudgell - Lead Volunteer

Thank you for your continued patience while we worked with our internal Product Group regarding your concerns.

We have now received final confirmation that the WordPress channel rollout has been completed across all Azure regions, stamps, and deployment stages.

You can therefore safely move back to the Microsoft platform-managed WordPress PHP 8.4 version by removing the explicit dated image/version pin and selecting the platform-provided PHP 8.4 version. This will allow your application to return to the normal Microsoft-managed image servicing mechanism.

Once you have switched back, please verify the PHP version directly from the App Service console by running:

php`` ``--version

This will confirm the actual PHP version being used by the running container.

Regarding your previous questions about monitoring the underlying managed image, our Product Group has confirmed that there is currently no supported API, CLI mapping endpoint, or notification mechanism that exposes which dated image the managed channel resolves to. The recommended method is to verify the PHP version directly from the running application using php`` ``--version.

For additional information regarding this security update, please refer to:

Critical PHP Security Release: What It Means for Azure App Service on Linux - Azure App Service

Once you have reverted to the managed PHP 8.4 version, please share the php`` ``--version output with us so that we can confirm everything is working as expected.

Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.

Your answer

Praneeth Maddali 12,670 Reputation points Microsoft External Staff Moderator

2026-10-21T19:54:30.06+00:00

Hi @Mike Hudgell - Lead Volunteer

Thank you for contacting us about the issue. We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this.
David 0 Reputation points

2026-10-21T20:02:36.8266667+00:00

Same issue here, and adding one finding that may help others: switching the Platform Release Channel to Latest delivered the patched image without pinning a dated tag.

Environment

Azure App Service for Linux, single instance

Microsoft WordPress on App Service container

linuxFxVersion: DOCKER|mcr.microsoft.com/appsvc/wordpress-debian-php:8.4

No custom Dockerfile or startup command

Platform Release Channel: Standard (default) until today

What we saw

WordPress Site Health and php-fpm -v both reported PHP 8.4.16 (fpm-fcgi, built Jan 12 2026). Nothing had updated since January, including the July and September PHP security releases.

What we did (21 Oct 2026, times UTC)

~19:20: changed Platform Release Channel from Standard to Latest and restarted. php -v reported PHP 8.4.27 (built Oct 21 2026 14:18:04), which matches the 8.4_20261021.5.tuxprod image you identified.

Switched back to Standard, on the basis that Latest isn't recommended for production. The app restarted and the new container's php-fpm (started 19:27) was back on 8.4.16, built Jan 12 2026. So as of this evening, Standard still maps :8.4 to the January build.

Switched back to Latest. Site Health now reports PHP 8.4.27.

So for anyone on the managed :8.4 image: the Latest channel gets you 8.4.27 today while keeping the managed tag and automatic updates, rather than pinning to a dated image and taking on patching yourself.

This makes the core question more pressing. Why has the Standard channel, the default and the one Microsoft recommends for production, been mapping :8.4 to a January 2026 build for nine months, and when will Standard move to 8.4.27? We're staying on Latest until Microsoft can confirm this.
Praneeth Maddali 12,670 Reputation points Microsoft External Staff Moderator

2026-10-21T21:32:45.6133333+00:00

HI @Mike Hudgell - Lead Volunteer

Thank you for your continued patience while we worked with our internal Product Group regarding your concerns.

We have now received final confirmation that the WordPress channel rollout has been completed across all Azure regions, stamps, and deployment stages.

You can therefore safely move back to the Microsoft platform-managed WordPress PHP 8.4 version by removing the explicit dated image/version pin and selecting the platform-provided PHP 8.4 version. This will allow your application to return to the normal Microsoft-managed image servicing mechanism.

Once you have switched back, please verify the PHP version directly from the App Service console by running:

php`` ``--version

This will confirm the actual PHP version being used by the running container.

Regarding your previous questions about monitoring the underlying managed image, our Product Group has confirmed that there is currently no supported API, CLI mapping endpoint, or notification mechanism that exposes which dated image the managed channel resolves to. The recommended method is to verify the PHP version directly from the running application using php`` ``--version.

For additional information regarding this security update, please refer to:

Critical PHP Security Release: What It Means for Azure App Service on Linux - Azure App Service

Once you have reverted to the managed PHP 8.4 version, please share the php`` ``--version output with us so that we can confirm everything is working as expected.

Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.