Azure Function Apps pinned to a language version Azure Functions no longer supports

Unsupported runtimes stop getting fixes

Azure Functions publishes a support table for every language it runs, with an expected end-of-support date for each version. Once a version drops off, the supported languages page no longer lists it and the language itself usually stops receiving security patches too. For example, .NET 6 reached the end of official support on 12 November 2024 and .NET 7 on 14 May 2024.

A function app on such a version keeps running, which is the problem: nothing breaks until a vulnerability in the runtime or its libraries is exploited, and no patch will arrive for it.

Reading an app’s configured stack

az functionapp config show --resource-group my-rg --name my-func \
  --query "{linux:linuxFxVersion, windows:windowsFxVersion}"

The value has the form stack|version, for example Python|3.11 or Node|20. Compare the version with the current table on the supported languages page.

The support floors ZopNight compares against

ZopNight parses the stack and version from the app’s linuxFxVersion or windowsFxVersion and fires when the version is below the oldest supported release for that language:

Python      3.10
Node.js     22
Java        8
.NET        8   (dotnet, dotnet-isolated, dotnetcore)
PowerShell  7.4

These floors mirror Microsoft’s published tables and move forward as Microsoft retires versions. A version at or above the floor is not flagged, even if its end-of-support date is near.

Apps the check will not judge

Apps with no stack value, custom container images, and any stack outside the five above are skipped, because there is no support table to compare them with. A bare .NET Framework version setting is not treated as evidence of the app’s language either: Windows apps carry that setting whatever language they actually run, so reading it as .NET would flag Node or PowerShell apps by mistake. Tags describing a runtime version are ignored.

Unpatched runtime risk, with no cost change

This is a compliance finding with no saving. Upgrading the stack does not change the price of the plan the app runs on.

Upgrading the runtime safely

1. Check the target version on the supported languages page, including plan limits: for instance, Python 3.12 is the last version supported on the Linux Consumption plan, which needs a move to Flex Consumption for anything newer.
2. Update dependencies and test the app locally against the new version.
3. On Linux, change the stack with, for example, az functionapp config set --resource-group my-rg --name my-func --linux-fx-version "Python|3.12". On Windows, change the version in the app’s configuration settings in the portal.
4. Deploy to a staging slot first, run the functions, then swap.