An Azure service that provides an event-driven serverless compute platform.
Hi lk-di & thx for join me at Q&A platform,
the key detail here is that you're running Azure Functions on classic Linux Consumption (Y1), not a regular Linux App Service application.
Microsoft published an Azure Functions-specific update on October 23, which clarifies this distinction.
According to that announcement, Linux Functions on Consumption, Dedicated, Elastic Premium, and Flex Consumption are being patched separately by the Azure Functions team. The rollout includes the relevant Node.js security fixes, but it was still in progress as of October 23.
So the October 22 App Service announcement stating that patched images are available on the Latest Platform Release Channel does not mean those images are already available to Linux Consumption Functions.
The Platform Release Channel instructions from the App Service announcement aren't applicable guidance for this hosting configuration. I wouldn't recommend using az webapp update --platform-release-channel Latest as a workaround.
Your linuxFxVersion=NODE|22 configuration selects the Node.js 22 release line, not a specific patch version. The actual patch version is determined by the managed Functions platform image.
Regarding restarting or redeploying, neither operation guarantees that you'll receive Node.js 22.23.4. A restart might pick up an updated image if it's already available to your app, but it cannot force an image that hasn't reached the relevant deployment infrastructure. Redeploying your application code won't change that either.
I haven't seen a confirmed West Europe completion date or an ETA specifically for Node.js 22.23.4 on Linux Consumption. The October 23 announcement confirms that the rollout is underway, but doesn't establish when your two apps will receive the patched runtime.
For mitigation, I'd first assess whether your Functions actually process untrusted Brotli-compressed data through the affected decoder. If they do, consider temporarily disabling that processing path or restricting untrusted inputs until the patched runtime is available. The appropriate mitigation depends on how your application uses Brotli; simply disabling HTTP response compression wouldn't necessarily address every possible exposure.
Given that this is a security-related runtime update, I'd open an Azure Functions technical support case and provide the hosting plan, region, observed Node.js version, UTC timestamps, and CVE reference. Ask the Functions engineering team to confirm the rollout status for West Europe and whether an earlier supported remediation is available.
I'd also continue checking process.version from actual function executions, particularly after platform recycling, rather than relying on the configured NODE|22 value.
Classic Linux Consumption is scheduled for retirement in September 2028, so planning a move to Flex Consumption makes sense longer term. However, migration shouldn't be presented as an immediate fix for this CVE, because the October 23 announcement says the Linux Functions rollout is still in progress across hosting plans.
For now, the supported path appears to be waiting for the Azure Functions-managed rollout while applying application-specific mitigations, unless Microsoft support can confirm an alternative for your workload.
rgds,
Alex
p.s. if my answer is help - pls mark it as an answer