Container Apps nodes running outdated kernel (6.6.130.1-3) — missing CVE-2026-31431 (CopyFail) patch

Question

We have identified that our Azure Container Apps environment in East US 2 is running kernel version 6.6.130.1-3 (Azure Linux 3.0), which is vulnerable to CVE-2026-31431 ("Copy Fail") — a local privilege escalation vulnerability that enables container escape via shared page cache.

Azure Linux shipped the fix in release 3.0.20260506 (kernel 6.6.137.1-2) on May 6, 2026 — over 3 weeks ago — but our nodes have not been updated.

• CVE is in CISA KEV catalog with active PoC exploitation
• Microsoft Defender blog confirms the vulnerability: https://www.microsoft.com/en-us/security/blog/ (search CVE-2026-31431)

Questions:

1. When will the Container Apps node pool in East US 2 be updated to Azure Linux ≥ 3.0.20260506?
2. Is there a way to force node rotation for our environment?

Answer 1

Hi @Anthony Rieder

Thank you for reaching out to Microsoft Q&A.

Azure Container Apps is a fully managed service where the underlying infrastructure, including node OS and kernel versions, is maintained and updated by Microsoft. Due to this design, customers do not have direct visibility or control over node pools, kernel patching, or upgrade timelines. When a security fix (such as the kernel patch for CVE‑2026‑31431) is released, it is rolled out gradually across regions and environments as part of the platform’s update process. Even though the patched Azure Linux version may already be available, existing nodes in a Container Apps environment might continue running older kernel versions until they are replaced as part of platform-driven maintenance or scaling activities. Additionally, kernel fixes are typically applied through new node images rather than in-place updates, which means systems remain on older versions until node rotation occurs. As a result, there is currently no guaranteed timeline for when a specific environment (such as East US 2) will receive the updated kernel, and this delay is expected behavior for a managed service.

Refer below points to resolve this issue or this is the workaround

Understand current limitation

Azure Container Apps does not provide any mechanism to manually upgrade node OS, trigger kernel updates, or force node pool rotation. Infrastructure updates are fully platform-managed and applied automatically.

Trigger node refresh indirectly using scaling

You can scale your application to increase the chances of scheduling workloads on newer nodes (if updated images are already rolled out):

az containerapp update \
  --name <app-name> \
  --resource-group <rg-name> \
  --min-replicas 2 \
  --max-replicas 5

This may result in new replicas running on updated nodes.

Scale down and scale up (re-scheduling workaround)

Scaling down to zero replicas and then scaling up again can help force workload rescheduling:

az containerapp update \
  --name <app-name> \
  --resource-group <rg-name> \
  --min-replicas 0
# Then scale back up
az containerapp update \
  --name <app-name> \
  --resource-group <rg-name> \
  --min-replicas 1

This can sometimes place workloads on newly provisioned nodes.

Restart or deploy a new revision

Deploying a new revision or restarting the app creates new replicas, which may be scheduled on updated nodes:

Recreate the Container Apps environment

If immediate remediation is critical, consider recreating the environment. This ensures new infrastructure is provisioned with the latest available node image and kernel version.

Raise a support request for expedited rollout

Since this is a security vulnerability (CVE‑2026‑31431), you can open a Microsoft support ticket requesting confirmation of rollout status or prioritization for your region.

Consider AKS if strict patch control is required

If your workload requires immediate kernel patching, controlled upgrades, or forced node rotation, consider using Azure Kubernetes Service (AKS), where node image upgrades and patching can be explicitly managed by the customer.

Answer 2

Hello Anthony Rieder,

Greetings! Thanks for raising this question in Q&A forum.

This is a very valid and serious security concern. The reason your nodes haven't been updated yet is that Azure Container Apps is a fully managed platform, meaning Microsoft controls the underlying node pool patching and kernel updates — customers cannot trigger node rotation manually. While the Azure Linux fix was released on May 6, 2026, the rollout of updated node images across all regions and all customer environments happens gradually and is managed entirely by the Azure Container Apps platform team. A delay of a few weeks between an upstream fix and full fleet rollout is unfortunately not uncommon, but given this CVE is actively exploited and listed in the CISA KEV catalog, it absolutely warrants urgent escalation.

Here's what you should do right now, step by step:

1. Raise a Critical Severity Support Ticket immediately

Since this CVE has an active PoC exploit and is in the CISA KEV catalog, this qualifies as a Severity A (Critical) support case. Go to the Azure Portal, click "Help + Support", and create a new support request with:

• Product: Azure Container Apps
• Issue type: Security
• Severity: Critical (Sev A)
• Description: Reference CVE-2026-31431, your environment region (East US 2), current kernel version (6.6.130.1-3), and the fact that the fix has been available since May 6, 2026 (kernel 6.6.137.1-2)

This is the fastest path to get Microsoft's engineering team to prioritize patching your environment.

2. Report through Microsoft Security Response Center (MSRC)

In parallel, report this via the official MSRC portal at https://msrc.microsoft.com/report this ensures the right security team at Microsoft is also aware and can track the exposure in your specific environment.

3. Apply immediate compensating controls while you wait

Since you cannot force a node rotation yourself, reduce your blast radius right now by:

• Ensuring all containers run as non-root users (this raises the bar for exploitation)
• Enabling Defender for Containers on your environment if not already done, so you get runtime threat detection
• Reviewing your Container Apps environment's network isolation ensure apps are behind a VNet and not directly exposed to the internet
• Restricting inter-container communication wherever possible to limit lateral movement risk

4. Ask Microsoft Support for an ETA on node rotation for East US 2

When you open the support ticket, explicitly ask: "What is the expected timeline for node pool rotation to kernel 6.6.137.1-2 or later in our East US 2 Container Apps environment?" Support engineers can check the rollout status for your specific region and escalate internally if needed.

5. Monitor Azure Service Health for updates

Go to Azure Portal > Service Health > Health Advisories and filter by Azure Container Apps and East US 2. Microsoft sometimes posts security maintenance notifications here when rolling out critical patches.

Given that this CVE is actively exploited, I'd strongly encourage not waiting on this and opening the Critical support ticket today. Microsoft's support SLA for Sev A issues requires a response within one hour, which will get you the fastest possible action.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.