---
title: Vulnerability Management for Azure Kubernetes Service (AKS)
description: Learn how Microsoft manages security vulnerabilities for Azure Kubernetes Service (AKS) clusters, including the production-ready default experience with AKS Automatic.
ms.topic: concept-article
ms.subservice: aks-security
ms.service: azure-kubernetes-service
author: davidsmatlak
ms.author: davidsmatlak
ms.date: 06/22/2026
# Customer intent: "As a cloud security engineer, I want to understand Microsoft's vulnerability management processes for Azure Kubernetes Service, so that I can effectively assess and mitigate security risks within my organization's Kubernetes deployments."
---

# Vulnerability management for Azure Kubernetes Service (AKS)

Vulnerability management involves detecting, assessing, mitigating, and reporting on any security vulnerabilities that exist in an organization's systems and software. Vulnerability management is a shared responsibility between you and Microsoft.

For most production workloads, AKS Automatic is the recommended default cluster experience. AKS Automatic reduces operational overhead by providing managed system node pools, automatic cluster and node image upgrades, built-in security safeguards, and production-ready defaults. If you need more direct control over cluster configuration, AKS Standard remains available for specialized scenarios.

This article describes how Microsoft manages security vulnerabilities and security updates, also referred to as patches, for AKS clusters. For an overview of the AKS Automatic experience, see [Introduction to Azure Kubernetes Service (AKS) Automatic](intro-aks-automatic.md).

[!INCLUDE [azure linux 2.0 retirement](./includes/azure-linux-retirement.md)]

## AKS Automatic and vulnerability management

AKS Automatic is designed to be the production-ready default for new AKS workloads. It includes defaults that strengthen the security posture of the cluster and reduce the amount of manual work required to keep workloads current, such as:

- Managed system node pools that AKS creates, scales, and upgrades.
- Azure Linux for the system node pool.
- Automatic cluster and node image upgrades.
- Azure role-based access control (RBAC) for Kubernetes authorization.
- Workload identity and OIDC issuer support.
- Deployment safeguards and baseline Pod Security Standards.
- Image cleaner to remove unused images.
- Managed network defaults that reduce the need for custom infrastructure configuration.

These defaults help Microsoft and customers reduce exposure windows for known vulnerabilities and simplify the process of keeping clusters current. AKS Standard is still available when you need a more manual or customizable operating model.

## How vulnerabilities are discovered

Microsoft identifies and patches vulnerabilities and missing security updates for the following components:

- **AKS container images**: Microsoft builds and maintains the container images used in AKS, which include Kubernetes components and other open-source software. Microsoft scans these images for vulnerabilities and applies patches as needed.
- **Ubuntu operating system 18.04 and 22.04 worker nodes**: Canonical provides Microsoft with OS builds that have all available security updates applied.
- **Windows Server 2022 OS worker nodes**: The Windows Server operating system is patched on the second Tuesday of every month. SLAs should be the same as per their support contract and severity.
- **Azure Linux OS nodes**: Azure Linux provides AKS with OS builds that have all available security updates applied.

For AKS Automatic clusters, the managed system node pool uses Azure Linux by default, which aligns the cluster with the platform's hardened and managed operating system model. That default reduces the amount of node-level patch management you need to do yourself.

## AKS Container Images

While the [Cloud Native Computing Foundation][cloud-native-computing-foundation] (CNCF) owns and maintains most of the code AKS runs, Microsoft takes responsibility for building the open-source packages we deploy on AKS. That responsibility includes having complete ownership of the build, scan, sign, validate, and hotfix process, and control over the binaries in container images. Having responsibility for building the open-source packages deployed on AKS enables us to establish a software supply chain over the binary, and to patch the software as needed.  

Microsoft is active in the broader Kubernetes ecosystem to help build the future of cloud-native compute in the wider CNCF community. This work not only ensures the quality of every Kubernetes release for the world, but also enables AKS quickly get new Kubernetes releases out into production for several years. In some cases, ahead of other cloud providers by several months. Microsoft collaborates with other industry partners in the Kubernetes security organization. For example, the Security Response Committee (SRC) receives, prioritizes, and patches embargoed security vulnerabilities before they're  announced to the public. This commitment ensures Kubernetes is secure for everyone, and enables AKS to patch and respond to vulnerabilities faster to keep our customers safe. In addition to Kubernetes, Microsoft signed up to receive prerelease notifications for software vulnerabilities for products such as Envoy, container runtimes, and many other open-source projects.

Microsoft scans container images using static analysis to discover vulnerabilities and missing updates in Kubernetes and Microsoft-managed containers. If fixes are available, the scanner automatically begins the update and release process.

In addition to automated scanning, Microsoft discovers and updates vulnerabilities unknown to scanners in the following ways:

- Microsoft performs its own audits, penetration testing, and vulnerability discovery across all AKS platforms. Specialized teams inside Microsoft and trusted third-party security vendors conduct their own attack research.
- Microsoft actively engages with the security research community through multiple vulnerability reward programs. A dedicated [Microsoft Azure Bounty program][azure-bounty-program-overview] provides significant bounties for the best cloud vulnerability found each year.
- Microsoft collaborates with other industry and open source software partners who share vulnerabilities, security research, and updates before the public release of the vulnerability. The goal of this collaboration is to update large pieces of Internet infrastructure before the vulnerability is announced to the public. In some cases, Microsoft contributes vulnerabilities found to this community.
- Microsoft's security collaboration happens on many levels. Sometimes it occurs formally through programs where organizations sign up to receive prerelease notifications about software vulnerabilities for products such as Kubernetes and Docker. Collaboration also happens informally due to our engagement with many open source projects such as the Linux kernel, container runtimes, virtualization technology, and others.

## Worker nodes

### Linux nodes

The nightly canonical OS security updates are turned off by default in AKS. In order to enable them explicitly, use the `unmanaged` [channel][aks-node-image-upgrade].

If you're using the `unmanaged` [channel][aks-node-image-upgrade], then nightly canonical security updates are applied to the OS on the node. The node image used to create nodes for your cluster remains unchanged. If a new Linux node is added to your cluster, the original image is used to create the node. This new node receives all available security and kernel updates during the automatic assessment performed every night, but remains unpatched until all checks and restarts are complete. You can use node image upgrade to check for and update node images used by your cluster. For more information on node image upgrade, see [Azure Kubernetes Service (AKS) node image upgrade][aks-node-image-upgrade].

For AKS clusters using a [channel][aks-node-image-upgrade] other than `unmanaged`, the unattended upgrade process is disabled.

For AKS Automatic, the default system node pool is managed by AKS and uses the NodeImage upgrade model to keep nodes current without requiring routine manual intervention.

### Windows Server nodes

For Windows Server nodes, Windows Update doesn't automatically run and apply the latest updates. Schedule Windows Server node pool upgrades in your AKS cluster around the regular Windows update release cycle and your own update management process. This upgrade process creates nodes that run the latest Windows Server image and patches, then removes the older nodes. For more information on this process, see [Upgrade a node pool in AKS][upgrade-node-pool-in-aks].

Windows Server nodes are primarily a Standard cluster or specialized workload choice. AKS Automatic uses Azure Linux for the system node pool.

## How vulnerabilities are classified

Microsoft makes large investments in security hardening the entire stack, including the OS, container, Kubernetes, and network layers, in addition to setting good defaults and providing security-hardened configurations and managed components. Combined, these efforts help to reduce the impact and likelihood of vulnerabilities.

The AKS team classifies vulnerabilities according to the Kubernetes vulnerability scoring system. Classifications consider many factors including AKS configuration and security hardening. As a result of this approach, and the investments AKS make in security, AKS vulnerability classifications might differ from other classification sources.

The following table describes vulnerability severity categories:

| Severity | Description |
| -------- | ----------- |
| Critical | A vulnerability easily exploitable in all clusters by an unauthenticated remote attacker that leads to full system compromise. |
| High | A vulnerability easily exploitable for many clusters that leads to loss of confidentiality, integrity, or availability. |
| Medium | A vulnerability exploitable for some clusters where loss of confidentiality, integrity, or availability is limited by common configurations, difficulty of the exploit itself, required access, or user interaction. |
| Low | All other vulnerabilities. Exploitation is unlikely or consequences of exploitation are limited. |

## How vulnerabilities are updated

AKS patches Common Vulnerabilities and Exposures (CVEs) that have a _vendor fix_ every week. Any CVEs without a fix are waiting on a vendor fix before they can be remediated. The fixed container images are cached in the next corresponding virtual hard disk (VHD) build, which also contains the updated Ubuntu/Azure Linux/Windows patched CVEs. As long as you're running the updated VHD, you shouldn't be running any container image CVEs with a vendor fix that is over 30 days old.  

For the OS-based vulnerabilities in the VHD, AKS also relies on node image vhd updates by default, so any security updates come with weekly node image releases. Unattended upgrades are disabled unless you switch to unmanaged, which isn't recommended as its release is global.

AKS Automatic reduces the amount of patch management you need to do manually by using managed system node pools and automatic cluster upgrade channels. That means the platform is responsible for keeping the cluster closer to current, supported versions without requiring you to orchestrate every node and control plane update yourself.

## Update release timelines

Microsoft's goal is to mitigate detected vulnerabilities within a time period appropriate for the risks they represent. The [Microsoft Azure FedRAMP High][microsoft-azure-fedramp-high] Provisional Authorization to Operate (P-ATO) includes AKS in audit scope and is authorized. FedRAMP Continuous Monitoring Strategy Guide and the FedRAMP Low, Moderate, and High Security Control baselines requires remediation of known vulnerabilities within a specific time period according to their severity level. As specified in FedRAMP RA-5d.

## How vulnerabilities and updates are communicated

In general, Microsoft doesn't broadly communicate the release of new patch versions for AKS. However, Microsoft constantly monitors and validates available CVE patches to support them in AKS in a timely manner. If a critical patch is found or user action is required, Microsoft [posts and updates CVE issue details on GitHub][aks-cve-feed].

For AKS Automatic, these updates are meant to happen with less customer intervention because the cluster follows managed upgrade behavior and production-ready defaults. For AKS Standard, users are more likely to need to monitor and apply upgrades themselves.

## Security Reporting

You can report a security issue to the Microsoft Security Response Center (MSRC), by [creating a vulnerability report][mrc-create-report].

If you prefer to submit a report without logging in to the tool, send email to [secure@microsoft.com](mailto:secure@microsoft.com). If possible, encrypt your message with our PGP key by downloading it from the [Microsoft Security Response Center PGP Key page][msrc-pgp-key-page].

You should receive a response within 24 hours. If for some reason you don't, follow up with an email to ensure we received your original message. For more information, go to the [Microsoft Security Response Center][microsoft-security-response-center].

Include the following requested information (as much as you can provide) to help us better understand the nature and scope of the possible issue:

- Type of issue (for example, buffer overflow, SQL injection, cross-site scripting, etc.)
- Full paths of source files related to the manifestation of the issue
- The location of the affected source code (tag/branch/commit or direct URL)
- Any special configuration required to reproduce the issue
- Step-by-step instructions to reproduce the issue
- Proof-of-concept or exploit code (if possible)
- Impact of the issue, including how an attacker might exploit the issue

This information helps us triage your reported security issue quicker.

If you're reporting for a bug bounty, more complete reports can contribute to a higher bounty award. For more information about our active programs, see [Microsoft Bug Bounty Program][microsoft-bug-bounty-program-overview].

### Policy

Microsoft follows the principle of [Coordinated Vulnerability Disclosure][coordinated-vulnerability-disclosure].

## Next steps

For most production workloads, start with AKS Automatic.

> [!div class="nextstepaction"]
> [Create an Azure Kubernetes Service (AKS) Automatic cluster](./automatic/quick-automatic-managed-network.md)

<!-- LINKS - internal -->
[microsoft-azure-fedramp-high]: /azure/azure-government/compliance/azure-services-in-fedramp-auditscope#azure-government-services-by-audit-scope
[aks-node-image-upgrade]: node-image-upgrade.md
[upgrade-node-pool-in-aks]: manage-node-pools.md#upgrade-a-single-node-pool

<!-- LINKS - external -->
[microsoft-bug-bounty-program-overview]: https://aka.ms/opensource/security/bounty
[coordinated-vulnerability-disclosure]: https://aka.ms/opensource/security/cvd
[cloud-native-computing-foundation]: https://www.cncf.io/
[aks-cve-feed]: https://github.com/Azure/AKS/issues?q=is%3Aissue+is%3Aopen+cve
[mrc-create-report]: https://aka.ms/opensource/security/create-report
[msrc-pgp-key-page]: https://aka.ms/opensource/security/pgpkey
[microsoft-security-response-center]: https://aka.ms/opensource/security/msrc
[azure-bounty-program-overview]: https://www.microsoft.com/msrc/bounty-microsoft-azure
