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

Hi Mike Hudgell - Lead Volunteer & thx for join me at Q&A platform,

really useful investigation, especially bc u've already confirmed the actual PHP version running in production and successfully deployed a patched Microsoft image.

The most concerning detail isn't simply that PHP 8.4.27 was available before the managed channel picked it up. It's that the managed :8.4 configuration was still resolving to an image dated January 13, 2026, on October 21. That's a significant gap for a service customers reasonably expect to receive security maintenance through.

Your findings also suggest that publishing a new image to MCR and updating the App Service managed image mapping are separate operations. The manifest unknown response for the public :8.4 tag supports that interpretation, although Microsoft would need to confirm how the internal mapping and rollout actually work.

I'd ask the Azure App Service / WordPress engineering team to investigate why 8.4_20260113.8.tuxprod was still selected for ur application. In particular, was this an intentionally pinned managed image, a delayed regional rollout, or a failure in the image-channel update process? Those scenarios have very different implications.

Regarding the patching schedule, I'm not aware of a publicly documented SLA guaranteeing that the managed WordPress PHP image will advance within a specific number of hours after an upstream PHP security release. That's exactly the kind of commitment Microsoft should clarify, particularly for critical vulnerabilities.

For checking the current image, az webapp config show can report the configured linuxFxVersion, but that doesn't necessarily reveal the dated image actually selected by the managed channel. Your container startup logs are more useful for that. I also wouldn't assume that a newer tag appearing in MCR means the managed channel has been updated.

For now, I'd stay on the explicitly pinned PHP 8.4.27 image, given that u've already validated it in production. The tradeoff is that you'll need to monitor future image releases and update the pinned version manually. Before switching back to :8.4, I'd want confirmation that the managed channel actually resolves to a patched image in ur region.

I'd also request that Microsoft provide a supported way to monitor the resolved image version, ideally through an API or published release history, along with notifications when the managed channel advances. Without that visibility, customers can't easily verify whether they're receiving security updates.

This deserves an engineering response rather than another generic recommendation to restart or redeploy the App Service. You've already demonstrated that a newer Microsoft image works and that the managed configuration was selecting an older one.

One detail that would help the investigation: which Azure region is the App Service running in? It would be interesting to know whether the same :8.4 configuration resolves to the January image in other regions too, or whether this is a regional rollout issue.

rgds,

Alex

p.s. if my answer is help - pls mark it as an answer

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.

 Please do not forget to click "Accept the answer” and Yes, this can be beneficial to other community members.

If you have any other questions, let me know in the "comments" and I would be happy to help you