Update (27 October 2026): Rollout of the updated built-in .NET images is complete on both the Latest and Standard Platform Release Channels for Azure App Service on Linux. Completion across all deployment stages and clouds was confirmed on 27 October 2026.
Following the out-of-band .NET security releases on 25 October 2026, Azure App Service has updated the built-in Linux images for .NET 8, 9, and 10. The primary fix addresses a vulnerability in the Brotli decoder used by .NET and ASP.NET Core.
The official .NET release notes describe CVE-2026-111497, a Brotli decoder out-of-bounds write. Processing maliciously crafted compressed data could result in denial of service, information disclosure, or elevation of privilege.
Applications can be affected when they use Brotli decompression through:
HttpClient automatic response decompression.System.IO.Compression Brotli APIs.Automatic request and response decompression are not enabled by default. .NET Framework is not affected by this issue.
The following upstream releases were published on 25 October 2026 and are included in this App Service Linux image update:
| .NET release line | Patched runtime version | Official release notes |
|---|---|---|
| .NET 8 | 8.0.33 | .NET 8.0.33 |
| .NET 9 | 9.0.22 | .NET 9.0.22 |
| .NET 10 | 10.0.14 | .NET 10.0.14 |
These releases include additional security fixes. See the official release notes for the complete scope, applicability, and any application-package updates required separately from the platform runtime.
The table identifies the patched versions, not confirmation that your app already runs them. Verify your application’s running runtime as described below.
Rollout of the updated built-in Linux images through the Platform Release Channels is complete:
| Channel | Availability of the updates |
|---|---|
| Latest | Rollout complete for the release lines listed above. |
| Standard (default) | Rollout complete for the release lines listed above. |
The updated images are available on both channels; a channel change is not required to receive this update. Verify your app’s running runtime version as described below.
Changing your Platform Release Channel does not change your app’s configured .NET release line. End-of-life runtimes do not receive these updates; move to a supported release line and test your app.
This post covers App Service for Linux. Its Platform Release Channel settings and rollout status do not apply to App Service for Windows.
Use az webapp exec (currently in preview) with Azure CLI 2.90.0 or later to open an interactive shell in your running app:
az webapp exec --resource-group <resource-group> --name <app-name>
For a deployment slot, add --slot <slot-name>. Use --instance <instance-id> to check other instances as needed.
In the interactive shell, list the installed shared runtimes:
dotnet --list-runtimes
For framework-dependent ASP.NET Core apps, check the relevant Microsoft.NETCore.App and Microsoft.AspNetCore.App entries against the patched version for your release line.
Installed runtimes do not by themselves prove which runtime your app process uses. Use existing startup logging or diagnostics to inspect System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription from the running application. For scaled-out apps, verify across instances. Avoid exposing runtime diagnostics through an unauthenticated public endpoint.
dotnet --version reports the SDK version, not the runtime used by your app. For self-contained deployments, inspect the application process and rebuild the deployment with a patched runtime; the platform’s shared-runtime list does not verify your bundled runtime.
Thank you for helping us keep your .NET apps on Azure App Service secure.
]]>Update (27 October 2026): Rollout of the updated built-in .NET runtimes on Azure App Service for Windows is complete through Safe Deployment Practices (SDP).
Following the out-of-band .NET security releases on 25 October 2026, Azure App Service has rolled out updated .NET runtimes for Windows apps. The primary fix addresses a vulnerability in the Brotli decoder used by .NET and ASP.NET Core.
The official .NET release notes describe CVE-2026-111497, a Brotli decoder out-of-bounds write. Processing maliciously crafted compressed data could result in denial of service, information disclosure, or elevation of privilege.
Applications can be affected when they use Brotli decompression through:
HttpClient automatic response decompression.System.IO.Compression Brotli APIs.Automatic request and response decompression are not enabled by default. .NET Framework is not affected by this issue.
The following upstream releases were published on 25 October 2026:
| .NET release line | Patched runtime version | Official release notes |
|---|---|---|
| .NET 8 | 8.0.33 | .NET 8.0.33 |
| .NET 9 | 9.0.22 | .NET 9.0.22 |
| .NET 10 | 10.0.14 | .NET 10.0.14 |
These releases include additional security fixes. See the official release notes for the complete scope, platform applicability, and any application-package updates required separately from the platform runtime.
The table identifies upstream patched versions, not confirmation that your app already runs them. Verify your application’s running runtime as described below.
Rollout of the updated built-in .NET runtimes across App Service for Windows through SDP is complete. Verify the runtime used by your running application as described below, particularly if your app pins a runtime version or bundles its own runtime.
Platform Release Channels do not apply to App Service for Windows. There is no Latest or Standard channel to select for this rollout. Linux channel settings and rollout status do not apply to Windows apps.
The platform manages updates to its built-in runtimes. This rollout does not change your app’s configured .NET release line.
For more information, see OS and runtime patching in Azure App Service.
Use existing startup logging or diagnostics to inspect System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription from the running application. For example, log the runtime during application startup:
Console.WriteLine(
$"Runtime: {System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription}");
Review that output in your application’s logs after deployment or the next application startup. Compare it with the patched version for your release line. For scaled-out apps, verify across instances. Avoid exposing runtime diagnostics through an unauthenticated public endpoint.
The configured release line or a runtime reported by a separate console process does not by itself prove which runtime your application process uses. dotnet --version reports the SDK version, not the running application’s runtime.
For self-contained deployments, inspect the application process and rebuild with a patched runtime; a platform shared-runtime update does not replace your bundled runtime.
Thank you for helping us keep your .NET apps on Azure App Service secure.
]]>Update (27 October 2026): The platform-managed .NET security update rollout is complete for Linux Azure Functions, Azure Static Web Apps managed functions, and Windows function apps on Consumption, App Service plans, and Elastic Premium.
The out-of-band .NET releases published on 25 October 2026 address a Brotli decoder vulnerability and additional security issues. The patching process for function apps depends on their operating system, hosting plan, and deployment model.
| Hosting plan or offering | Windows | Linux |
|---|---|---|
| Consumption | App Service Windows runtime rollout complete. | Azure Functions rollout complete. |
| App Service plan (Dedicated) | App Service Windows runtime rollout complete. | Azure Functions rollout complete. |
| Elastic Premium | App Service Windows runtime rollout complete. | Azure Functions rollout complete. |
| Flex Consumption | Not available on Windows. | Azure Functions rollout complete. |
| Static Web Apps managed functions | Not applicable. | Applicable update complete; aligned with the Azure Functions Linux rollout. |
These statuses describe platform-managed updates. Verify the runtime used by your running function process on either OS. Application-managed packages, self-contained deployments, and custom containers require separate review.
The Azure Functions team has completed rollout of the applicable .NET updates for Linux function apps on the hosting plans listed above.
The App Service Linux .NET post provides background on the upstream releases. Its Platform Release Channel rollout statuses, runtime-version table, and channel guidance are not Azure Functions rollout or support guidance, including for Linux functions hosted on App Service plans.
The applicable .NET update for Azure Static Web Apps managed functions is complete, aligned with the Azure Functions Linux rollout.
This status applies to managed functions, not a separately linked Azure Functions app. For a linked function app, use its hosting plan and OS to identify the rollout that applies. This update does not add support for a new language or runtime version in Static Web Apps managed functions.
Windows function apps on Consumption, App Service plans, and Elastic Premium receive the applicable platform runtime updates through the App Service Windows patching process.
The App Service Windows .NET rollout is complete, reaching Stage 5 on 27 October 2026 through SDP.
The primary fix addresses CVE-2026-111497, a Brotli decoder out-of-bounds write in the Brotli library used by .NET and ASP.NET Core. Processing maliciously crafted compressed data could result in denial of service, information disclosure, or elevation of privilege.
Affected code paths include ASP.NET Core request decompression, HttpClient automatic response decompression, and the System.IO.Compression Brotli APIs. Automatic request and response decompression are not enabled by default. Review the decompression paths your functions and dependencies actually use; this does not imply that every HTTP-triggered function enables Brotli request decompression.
.NET Framework is not affected by this issue.
These releases include additional security fixes. See the official release notes below for applicability and any separate application-package updates.
The following upstream releases were published on 25 October 2026:
| .NET release line | Upstream patched runtime | Official release notes |
|---|---|---|
| .NET 8 | 8.0.33 | .NET 8.0.33 |
| .NET 9 | 9.0.22 | .NET 9.0.22 |
| .NET 10 | 10.0.14 | .NET 10.0.14 |
This is an upstream reference table, not an Azure Functions support or availability matrix. An upstream release or its availability in App Service does not establish support for your Functions hosting plan or execution model.
Use a .NET version supported by Azure Functions for your OS, plan, and execution model. Review the isolated worker supported versions and in-process supported versions. This update does not change your configured release line, migrate your execution model, or add support for .NET 11 RC3.
Use existing application logging or diagnostics to record System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription from your executing function code. With an existing ILogger instance named logger, for example:
logger.LogInformation(
"Function runtime: {Runtime}",
System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription);
For isolated worker apps, verify the .NET worker process, not just the Functions host. For in-process apps, function code runs within the host process. Inspect logs across active instances; avoid exposing runtime diagnostics through an unauthenticated public endpoint.
dotnet --version reports the SDK version, and a shared-runtime list only identifies installed runtimes. Neither proves which runtime your function process uses. Self-contained deployments must be verified and updated separately.
Thank you for helping us keep your .NET function apps secure.
]]>Update (26 October 2026): The applicable time-zone, Node.js, and eMudhra / emSign certificate update rollouts are now complete for Windows Azure Functions on Consumption, App Service plans, and Elastic Premium through the App Service Windows patching process. The applicable time-zone, Node.js, Python, and certificate updates remain complete for Linux Azure Functions on Consumption, App Service plans, Elastic Premium, and Flex Consumption, and for Azure Static Web Apps managed functions.
The patching process depends on your function app’s operating system and hosting plan.
| Hosting plan or offering | Windows | Linux |
|---|---|---|
| Consumption | App Service Windows rollout complete. | Azure Functions rollout complete. |
| App Service plan (Dedicated) | App Service Windows rollout complete. | Azure Functions rollout complete. |
| Elastic Premium | App Service Windows rollout complete. | Azure Functions rollout complete. |
| Flex Consumption | Not available on Windows. | Azure Functions rollout complete. |
| Static Web Apps managed functions | Not applicable. | Managed functions update rollout complete. |
Completion applies to the platform-managed updates covered here; application-managed dependencies, trust stores, and time-zone data require separate review. Python functions run on Linux; the Python runtime updates below do not apply to Windows function apps.
The separate .NET Brotli security update rollout is not covered by this completion notice.
Function apps on these Windows hosting plans receive the applicable platform updates through the App Service Windows patching process. Follow the corresponding posts for update details and rollout status:
These are separate OS and runtime updates. Their completion does not replace application-managed dependencies, trust stores, or time-zone data.
The Azure Functions team has completed its separate rollout for Linux function apps on all four hosting plans.
This work covers the applicable time-zone, Node.js, Python, and certificate fixes. Completion does not change your app’s configured language release line or replace application-managed data and dependencies.
The App Service Linux posts provide background on the time-zone changes, Node.js and Python releases, and certificate issue. Their App Service completion statuses, runtime-version tables, and Platform Release Channel instructions are not Azure Functions rollout or support guidance, including for Linux functions hosted on App Service plans.
The rollout of the applicable fixes for Azure Static Web Apps managed functions is also complete. These managed API backends are included in this Linux update guidance.
This status applies to managed functions, not a separately linked Azure Functions app. For a linked function app, use its hosting plan and OS to identify the rollout that applies.
Current time-zone data is needed to convert UTC timestamps to local time and calculate schedules correctly when governments change local timekeeping rules. UTC itself does not change.
Test the locations your app depends on using timestamps before and after the relevant rule change. Verify both local times and UTC offsets, and check the next execution times of recurring jobs. For timer-triggered functions, review the Azure Functions timer trigger documentation for the time-zone settings supported by your OS and hosting plan; this patch does not add support for a previously unsupported setting.
An OS update does not replace time-zone databases bundled with your application or libraries. Test through the APIs and scheduling code your function actually uses.
The updates address the recent Node.js security releases described in the linked App Service posts. Use a Node.js version supported by Azure Functions and verify the actual runtime in your running function worker.
An upstream patched version or its availability in App Service does not, by itself, establish availability for your Functions hosting plan or configured release line.
The Python updates address the recent Python releases and related certificate-bundle changes described in the linked runtime post. Use a Python version supported by Azure Functions for your hosting plan.
A platform runtime update does not update packages already deployed with your app, including packages in an existing virtual environment. Review application-managed certificate bundles and affected dependencies, update them through your trusted package source, and rebuild and redeploy as needed.
The certificate updates address trust associated with the eMudhra / emSign CA incident. Applications can use OS certificate stores, runtime-specific trust stores, or CA bundles supplied by dependencies.
An updated platform trust store does not prove that every TLS client in your function app uses updated trust data. Review custom trust stores and bundled CA data separately. Test outbound TLS connections after updating, and work with endpoint owners to resolve certificate-chain failures rather than disabling certificate validation.
process.version for Node.js or sys.version for Python inside the function worker. Verify across instances; avoid exposing diagnostics through an unauthenticated public endpoint.Update (26 October 2026): The rollout of Windows operating-system time-zone updates on Azure App Service for Windows is complete, following accelerated Safe Deployment Practices (SDP). Application-managed time-zone data still requires separate review as described below.
Time-zone rules change when governments update local timekeeping policies. Apps need current time-zone data to convert UTC timestamps to local time and calculate schedules correctly.
Older time-zone data can apply a clock change that no longer occurs, producing incorrect local-time displays, job schedules, deadlines, and date-based calculations. Apps using different data versions can also disagree about the same timestamp.
We have completed the rollout of an OS-level time-zone update across App Service for Windows through accelerated SDP. This is a platform operating-system update, not a language-specific runtime release.
The platform manages this OS update. Customers do not need to install an OS patch manually on App Service workers. For more information, see OS and runtime patching in Azure App Service.
An app can use Windows time-zone rules, runtime-bundled data, or a database supplied by a library. An OS time-zone update alone is not proof that every date/time API or scheduler in your application uses the updated rules.
Review the data source used by your runtime and dependencies. Update application-managed time-zone data separately through the relevant maintainers’ supported update process, then test and redeploy as needed.
Update (25 October 2026): The Java rollout is now complete on Standard. Rollout of patched built-in Linux images for the eMudhra / emSign CA certificate security incident is complete on Latest and Standard for all runtimes listed below, including Java. No channel change is needed. The PHP 8.2 and EOL exclusions described below remain unchanged.
The eMudhra / emSign incident affects certificate trust used by TLS clients. The Ubuntu Security Team’s incident and patch guidance explains the CA trust-store changes needed to mitigate the risk of man-in-the-middle attacks.
This is not limited to a single language runtime. Applications can use operating-system certificates, runtime-managed trust stores, or certificate bundles supplied by dependencies. Updating the platform image does not replace certificate bundles managed by your application.
Patched built-in Linux images are available on Latest and Standard for all non-EOL runtimes, with the PHP 8.2 exception described below. Java is available on both Latest and Standard; its rollout is complete.
The following runtime versions are listed by az webapp list-runtimes -o table --os linux as of 22 October 2026 and are included in the completed rollout to Latest and Standard. For Java, the table summarizes Java SE versions rather than listing individual application-server combinations.
| Runtime | Versions included in the image updates |
|---|---|
| .NET | 8, 9, 10, 11 |
| Node.js | 22, 24 |
| Python | 3.10, 3.11, 3.12, 3.13, 3.14 |
| PHP | 8.3, 8.4, 8.5 |
| Java SE | 8, 11, 17, 21, 25 |
Runtimes approaching EOL are included while they remain supported. EOL runtimes do not receive these image updates.
WordPress on App Service is also updated. The supported images for apps deployed using the official WordPress on App Service offering in Microsoft Marketplace include the certificate security updates.
The built-in PHP 8.2 image is not included in this initial patch payload. Although PHP 8.2 itself has not yet reached EOL, its underlying Debian 11 (Bullseye) operating system is beyond Debian’s standard/LTS support period and is not providing the patch for this image.
We are investigating options to provide a patch for PHP 8.2. No availability date is confirmed.
If your app uses PHP 8.2, update and test your app on PHP 8.3 or a later supported version, then configure your app to use that runtime. Moving a PHP 8.2 app to Latest alone does not address this exception.
| Channel | Availability of the updates |
|---|---|
| Latest | Rollout complete. |
| Standard (default) | Rollout complete for the included runtimes, including Java. |
The updated images are available on both Latest and Standard for all included runtimes, including Java.
Changing your Platform Release Channel does not upgrade your app to a different runtime version or make an EOL runtime supported.
Azure portal
Azure CLI
Use az webapp update to move your app to Standard:
az webapp update \
--resource-group <resource-group> \
--name <app-name> \
--platform-release-channel Standard
Replace the placeholders with your app’s resource group and name. For a deployment slot, add --slot <slot-name>.
Eligible apps, including Java apps, already on Standard or Latest do not need a channel change.
Use az webapp exec (currently in preview) with Azure CLI 2.90.0 or later to open an interactive shell in your running app:
az webapp exec --resource-group <resource-group> --name <app-name>
Replace the placeholders with your app’s resource group and name. For a deployment slot, add --slot <slot-name>.
Inside the container, identify the OS and installed certificate-package version:
cat /etc/os-release
dpkg-query -W -f='${Package} ${Version}\n' ca-certificates
For Ubuntu-based images, compare the installed version with the fixed version for the same Ubuntu release in the Ubuntu incident and patch guidance. For example:
| Ubuntu release | Fixed ca-certificates version |
|---|---|
| 24.04 | 20260816ubuntu0.24.04.1 |
| 26.04 | 20260816ubuntu0.26.04.1 |
The listed version or a subsequent version containing the fix is the expected result. Do not compare package versions across different OS releases. For Debian-based images, use the corresponding Debian package guidance rather than the Ubuntu versions.
This check inspects the OS certificate package on one running instance, not every trust store used by your app. Use --instance <instance-id> to connect to other instances as needed. Application-managed CA bundles and runtime-specific trust stores require separate checks. A successful HTTPS request alone is not proof that the issue is mitigated.
The platform update covers the built-in images, not certificate bundles or trust stores that your app supplies. Review your app’s libraries, dependencies, and custom trust-store configuration, and follow their maintainers’ incident guidance. Update affected dependencies through your trusted package source, then rebuild, test, and redeploy as needed.
As the Ubuntu guidance notes, removing affected trust anchors can also cause connections to legitimate endpoints that rely on those anchors to fail. Test outbound TLS connections and work with the endpoint owner to resolve affected certificate chains rather than disabling certificate validation.
We share further updates here as needed, including any changes to the PHP 8.2 patch plan.
Thank you for helping us keep your apps on Azure App Service secure.
]]>Update (25 October 2026): The rollout of Windows operating-system certificate updates for the eMudhra / emSign CA certificate security incident is complete on Azure App Service for Windows. Application-managed certificate bundles and trust stores still require separate review as described below.
The eMudhra / emSign incident affects certificate trust used by TLS clients. Compromised certificate authorities can allow an attacker to impersonate TLS endpoints when a client continues to trust the affected certificate chains.
For background on the incident, see the Ubuntu Security Team’s incident explanation. That article describes the cross-platform certificate issue; its Linux package versions and installation commands do not apply to Windows.
We have completed the rollout of an OS-level certificate trust update to App Service for Windows. This is a platform operating-system update, not a language-specific runtime release.
Platform Release Channels do not apply to App Service for Windows. There is no Latest or Standard channel to select for this rollout. The Linux channel instructions in our related posts do not apply to Windows apps.
The platform manages this OS update. Customers do not need to install an OS patch manually on App Service workers. For more information, see OS and runtime patching in Azure App Service.
An app can use the Windows certificate store, a runtime-specific trust store, or a CA bundle supplied by a library. An OS certificate update alone is not proof that every TLS client in your application is protected.
Review custom trust-store configuration, bundled certificates, and dependencies that maintain their own CA data. Update affected components through your trusted sources and test the application after redeployment.
Thank you for helping us keep your apps on Azure App Service secure.
]]>Update (26 October 2026): The rollout of updated built-in Node.js runtimes on Azure App Service for Windows is complete, following accelerated Safe Deployment Practices (SDP). Verify your app’s running version and review pinned runtime settings as described below.
Following the emergency Node.js releases on 21 October 2026, the Azure App Service team has rolled out updated Node.js runtimes for Windows apps.
For the 22.x and 24.x release lines covered in this article, the official Node.js security announcement lists fixes with a highest severity of High, including fixes for a Brotli decoder out-of-bounds write that permits remote code execution, DNS name handling, and TLS certificate hostname validation. The release also includes dependency updates and a CA-certificate update related to the eMudhra intermediate CA compromise.
| Node.js release line | Patched version | Official release notes |
|---|---|---|
| 22.x | 22.23.4 | Node.js 22.23.4 |
| 24.x | 24.22.1 | Node.js 24.22.1 |
These are the upstream patched versions for the release lines covered here, not confirmation that your app already runs them. See the official security announcement for the complete vulnerability list and affected release lines.
We have completed the rollout of the updated built-in Node.js runtimes across App Service for Windows through accelerated SDP.
Platform Release Channels do not apply to App Service for Windows. There is no Latest or Standard channel to select for this rollout. The Linux channel instructions in our related posts do not apply to Windows apps.
For more information about platform-managed runtime updates, see OS and runtime patching in Azure App Service.
Use your application’s existing startup logging or diagnostics to inspect process.version in the running Node.js application process. For example, log the version during application startup:
console.log(`Node.js runtime: ${process.version}`);
Review that output in your application’s logs after deployment or the next application startup. Avoid exposing runtime diagnostics through an unauthenticated public endpoint.
The version selected in configuration or reported by a separate console process does not by itself prove which Node.js binary your application process uses. For scaled-out apps, check the application logs across instances.
Thank you for helping us keep your Node.js apps on Azure App Service secure.
]]>Update (22 October 2026): Rollout of the updated built-in Node.js and Python images is complete on both the Latest and Standard Platform Release Channels for Azure App Service on Linux.
Following the emergency Node.js and Python releases on 21 October 2026, the Azure App Service team has updated the built-in Linux images with the newly released runtime versions.
The following versions were published by the Node.js and Python projects on 21 October 2026. These are upstream release versions; verify the runtime version in your running App Service app using the instructions below.
For the 22.x and 24.x release lines covered in this article, the official Node.js security announcement lists fixes with a highest severity of High, including fixes for a Brotli decoder out-of-bounds write that permits remote code execution, DNS name handling, and TLS certificate hostname validation. The release also includes dependency updates and a CA-certificate update related to the eMudhra intermediate CA compromise.
| Node.js release line | Patched version | Official release notes |
|---|---|---|
| 22.x | 22.23.4 | Node.js 22.23.4 |
| 24.x | 24.22.1 | Node.js 24.22.1 |
See the official security announcement for the complete vulnerability list and affected release lines. End-of-life Node.js versions do not receive these fixes; move to a supported release line if your app is using an EOL version.
The official Python release announcement describes an expedited security release for 3.14 and a special security release for 3.13. Both update bundled pip to 26.2.2, including certifi 2026.10.19, to address the eMudhra / emSign CA certificate security incident.
| Python release line | Updated version | Official release notes |
|---|---|---|
| 3.13 | 3.13.17 | Python 3.13.17 |
| 3.14 | 3.14.9 | Python 3.14.9 |
Updating the platform runtime does not update packages in your app’s existing virtual environments. The Python team also recommends updating pip and uv in existing virtual environments. Review the official incident guidance, update affected app-managed dependencies through your trusted package source, and rebuild and redeploy your app as needed.
The updated images roll out through the Platform Release Channels as follows:
| Channel | Availability of the updates |
|---|---|
| Latest | Rollout complete. |
| Standard (default) | Rollout complete through Safe Deployment Practices (SDP). |
The updated images are available on both Latest and Standard for the release lines covered here.
Changing your Platform Release Channel does not change your app’s configured Node.js or Python release line. If your app needs a different supported release line, update and test the app and change its runtime configuration separately.
az webapp exec to open an interactive shell in the app and check its running runtime version.Azure portal
Azure CLI
Use az webapp update to move your app to Standard:
az webapp update \
--resource-group <resource-group> \
--name <app-name> \
--platform-release-channel Standard
Replace the placeholders with your app’s resource group and name. For a deployment slot, add --slot <slot-name>.
If your app is already on Standard or Latest, no channel change is needed for these updates.
For more information, see OS and runtime patching in Azure App Service.
Use az webapp exec (currently in preview) with Azure CLI 2.90.0 or later to open an interactive shell in your running app:
az webapp exec --resource-group <resource-group> --name <app-name>
Replace the placeholders with your app’s resource group and name. For a deployment slot, add --slot <slot-name>.
In the interactive shell, run the command for your runtime.
For Node.js:
node --version
For Python:
python --version
Verify the version in your running app rather than relying only on the selected Platform Release Channel.
Use the interactive shell for these checks rather than detached execute mode, which does not return command output or an exit code.
We will share further updates here as needed.
Thank you for helping us keep your Node.js and Python apps on Azure App Service secure.
]]>Update (25 October 2026): The Java rollout is now complete on Standard. Rollout of updated built-in Linux images for the time-zone rule changes in IANA time zone database 2026e is complete on Latest and Standard for all supported runtimes covered below, including Java. No channel change is needed. The PHP 8.2, PHP 8.3, and EOL exclusions described below remain unchanged.
Time-zone rules change when governments update local timekeeping policies. Apps need current time-zone data to convert UTC timestamps to local time and calculate schedules correctly.
The upstream time zone database release notes describe changes affecting several Canadian regions around the 1 November 2026 clock transition, as well as an earlier change affecting Morocco and Western Sahara. UTC itself does not change.
The updates are cumulative. 2026e includes the following rule changes from releases 2026b through 2026e:
| Region | Updated behavior | First included |
|---|---|---|
British Columbia (including America/Vancouver) |
Remains on UTC-07 instead of falling back on 1 November. | 2026b |
Alberta (including America/Edmonton) |
Remains on UTC-06 instead of falling back on 1 November. | 2026c |
| Morocco and Western Sahara | Move to permanent UTC+00 on 20 September 2026. | 2026c |
| Northwest Territories | Remains on UTC-06 instead of falling back on 1 November. | 2026d |
Manitoba (including America/Winnipeg) |
Remains on UTC-05 instead of falling back on 1 November. | 2026e |
See the upstream release notes for exact zone coverage and transition details. These changes do not mean that every location in Canada follows the same rules.
Older data can apply a clock change that no longer occurs, producing incorrect local-time displays, job schedules, deadlines, and date-based calculations. Apps on different data versions can also disagree about the same timestamp.
Updated built-in Linux images are available on Latest and Standard for non-EOL runtimes, with the PHP 8.2 and 8.3 exceptions described below. The updates address the time-zone data needed for these rule changes, including OS data and runtime-bundled data where applicable. Java is available on both Latest and Standard; its rollout is complete.
The following runtime versions are included in the completed rollout to Latest and Standard. For Java, the table summarizes Java SE versions rather than listing individual application-server combinations.
| Runtime | Versions included in the image updates |
|---|---|
| .NET | 8, 9, 10, 11 |
| Node.js | 22, 24 |
| Python | 3.10, 3.11, 3.12, 3.13, 3.14 |
| PHP | 8.4, 8.5 |
| Java SE | 8, 11, 17, 21, 25 |
EOL runtimes do not receive these image updates. Updating an image does not automatically replace time-zone databases bundled in your app or its dependencies.
PHP 8.2 and PHP 8.3 are not included in this initial time-zone update payload. These stacks use a custom PHP time-zone database that is not current. We are investigating an update plan for these two stacks; no availability date is confirmed.
Moving an app on either stack to Latest alone does not address this exception. If your app depends on the changed rules, update and test it on a supported PHP stack included in this rollout, such as PHP 8.4 or 8.5, and verify its date/time behavior before switching production traffic.
| Channel | Availability of the updates |
|---|---|
| Latest | Rollout complete for the included runtimes. |
| Standard (default) | Rollout complete for the included runtimes, including Java. |
Both channels include these updates for all covered runtimes, including Java. Changing your channel does not upgrade your app to a different runtime version or make an EOL runtime supported.
Azure portal
Azure CLI
Use az webapp update to move your app to Standard:
az webapp update \
--resource-group <resource-group> \
--name <app-name> \
--platform-release-channel Standard
Replace the placeholders with your app’s resource group and name. For a deployment slot, add --slot <slot-name>.
Eligible apps, including Java apps, already on Standard or Latest do not need a channel change.
For more information, see OS and runtime patching in Azure App Service.
Use az webapp exec (currently in preview) with Azure CLI 2.90.0 or later to open an interactive shell in the running app:
az webapp exec --resource-group <resource-group> --name <app-name>
For a deployment slot, add --slot <slot-name>. Use --instance <instance-id> to check other instances as needed.
Inside an Ubuntu- or Debian-based container, inspect the OS and installed time-zone package:
cat /etc/os-release
dpkg-query -W -f='${Package} ${Version}\n' tzdata
For a quick OS-level behavior check, convert a timestamp after the November transition:
TZ=America/Winnipeg date -d '2026-11-01 12:00:00 UTC' '+%Y-%m-%d %H:%M:%S %z'
With the updated Manitoba rules, the expected result is:
2026-11-01 07:00:00 -0500
This checks the OS time-zone data on one instance, not the database used by every runtime or library. Repeat relevant conversions through your app’s own date/time APIs and scheduling libraries. An OS package update alone is not proof that application-bundled ICU or other time-zone data is current.
We share further updates here as the PHP 8.2 and 8.3 update plan becomes available.
Thank you for keeping your apps’ time-zone data current on Azure App Service.
]]>