CVE-2026-47299 Azure Monitor Agent: No Fixed Version Confirmed

The August 11, 2026 MSRC entry identifies the product and impact, but it does not publicly explain the underlying flaw, identify a prerequisite such as local access or an authenticated Azure role, name a CVE weakness category, or link the issue to a specific Knowledge Base package. This is important operationally because Azure Monitor Agent is delivered as an Azure extension, not as a normal Windows cumulative update. Waiting for a Windows Update deployment ring to solve this exposure could leave the agent unchanged.

Microsoft’s own Azure Monitor documentation says the agent runs on Azure virtual machines, scale sets, and Arc-enabled servers. That puts the exposure boundary around systems where AMA has been deliberately deployed for Log Analytics, Microsoft Sentinel, VM Insights, performance monitoring, or related collection duties—not every Windows device in a tenant.

The advisory is real, but its patch mapping is incomplete​

MSRC’s August 11 publication establishes that Microsoft recognizes CVE-2026-47299 as an Azure Monitor Agent elevation-of-privilege issue. Its publication date is notable: this is a Tuesday release, but Azure Monitor Agent is maintained on a separate extension cadence from Windows client and server cumulative updates.

The missing mapping matters more than it may first appear. A security team ordinarily needs to answer four asset-management questions quickly:

• Which operating systems and deployment models are affected?
• Which installed versions are vulnerable?
• Which specific version is fixed?
• Is the remediation already present through automatic extension upgrades, or must the extension be explicitly redeployed?

The public advisory, as released, does not settle those questions. It is not enough to know that “the Azure Monitor Agent” has a vulnerability when a tenant may have Windows AMA, Linux AMA, the Metrics Extension, manually pinned extensions, automatically upgraded extensions, and Arc-connected servers operating under different update policies.

No independent technical write-up, proof of concept, or detailed third-party analysis of CVE-2026-47299 was publicly available at publication time. Searches of the public CVE and NVD records also did not yield a usable matching entry when this article was prepared. That does not cast doubt on the advisory; Microsoft is the assigning vendor and its MSRC record is the primary source. It does mean administrators should resist filling in the blanks with assumptions about attack vector, severity, or exploitability.

An elevation-of-privilege classification alone does not establish remote unauthenticated compromise. It describes the consequence after successful exploitation: an attacker obtains permissions they should not have. Whether that begins with local code execution, an authenticated session, a low-privileged account, extension-management access, or another condition remains undisclosed.

Azure Monitor Agent updates do not behave like Patch Tuesday KBs​

The practical complication is AMA’s rollout model. Microsoft Learn says Azure Monitor Agent versions are deployed progressively across regions under Azure Safe Deployment Practices, with full availability potentially taking four to six weeks from rollout start. During that time, machines in different Azure regions can be on different versions even when they share the same policy.

Microsoft’s current release notes list Windows Azure Monitor Agent version 1.44 in the July 2026 release. That package updated OpenSSL to 3.6.3, updated the Metrics Extension to version 2.2026.617.1755, and included unspecified internal-library security and reliability improvements. The release notes do not name CVE-2026-47299, so there is no basis yet to say that Windows AMA 1.44 is the security fix.

Linux AMA version 1.44 began rolling out on August 10, one day before CVE-2026-47299 was published, according to Microsoft Learn. That release includes security and reliability changes, including updates to bundled Metrics Extension dependencies and the OpenTelemetry Collector. Again, Microsoft has not publicly tied that release to CVE-2026-47299.

The close timing is worth watching but should not be treated as confirmation. Security teams routinely get into trouble when they infer a fixed version from a release date, only to discover later that the CVE applies to a component delivered through a different extension channel or a later hotfix.

Microsoft’s documentation also makes clear that it supports Azure Monitor Agent versions released within the last year and issues bug fixes only in the latest version. That policy is a good reason to move old installations forward, but it is not a substitute for Microsoft identifying the version that remediates this particular vulnerability.

Windows and Arc administrators should check extension state now​

The first response should be an inventory exercise, not an emergency reboot campaign. Identify systems where the Azure Monitor Agent Windows extension is installed and determine whether automatic extension upgrades are enabled. The relevant extension is ordinarily named

, published by

.

For Azure virtual machines, Microsoft supports one-time upgrades by setting a target extension version and recommends enabling automatic extension upgrades. For Azure Arc-enabled Windows servers, Microsoft documents updating the extension through Azure PowerShell or Azure CLI and separately enabling automatic upgrades on the connected-machine extension.

This is especially relevant in environments that deliberately pin extension versions for change control. A pinned AMA extension may continue working perfectly from a telemetry perspective while remaining behind the security baseline. The Azure portal’s healthy-extension status should not be confused with current patch status: “Provisioning succeeded” tells you that the extension installed; it does not confirm that the machine has the latest type-handler version.

Scale sets deserve separate attention. Microsoft notes that scale sets configured with a Manual upgrade policy require administrators to update existing instances after changing the scale-set model. In other words, changing the extension definition does not necessarily update running instances. A VMSS can therefore present a split state in which newer instances receive a newer AMA version while older instances retain the previous extension package.

Arc adds another layer. An Arc-enabled server may be visible to Azure and show the agent extension in inventory, but it depends on the Azure Connected Machine agent, outbound connectivity, policy assignment, and whatever maintenance controls govern that on-premises machine. Azure’s staged extension update model can therefore be slower and less uniform on Arc estates than on native Azure VMs.

Do not confuse AMA with the retired Log Analytics agent​

Administrators should also verify that remediation work is aimed at the right product. The Azure Monitor Agent replaced the older Log Analytics agent, variously known as MMA or OMS. Microsoft retired the Log Analytics agent on August 31, 2024, and the old agent’s security history—including the OMI-related issues that affected Linux deployments—does not identify the scope of CVE-2026-47299.

A server that still has legacy monitoring components installed may need its own cleanup plan, but that is separate from validating Azure Monitor Agent extension versions. Conversely, an organization that completed the AMA migration may assume the work is finished because the extension is “managed by Azure.” That assumption is exactly where staged rollout and disabled automatic upgrades can create a patching gap.

The right short-term posture is straightforward:

• Inventory Azure Monitor Agent extensions across Azure VMs, scale sets, and Arc-enabled Windows servers.
• Record the installed type-handler version, automatic-upgrade setting, region, and scale-set upgrade policy.
• Move unsupported or stale AMA versions to the latest available release through approved change control.
• Prioritize systems where lower-privileged users can execute code locally, such as shared administration servers, virtual desktop hosts, developer jump boxes, and multi-user application servers.
• Preserve extension and Azure Activity Log records before making broad changes, so any later Microsoft clarification can be mapped to the systems that were actually exposed.

Microsoft needs to publish the version boundary​

CVE-2026-47299 is a valid security item, but at present it is not a fully actionable advisory. The gap is not a lack of administrator guidance—Microsoft’s AMA management documentation is detailed—but the absence of a public, CVE-specific statement tying the vulnerability to affected versions, fixed versions, and deployment channels.

Until that mapping appears, the defensible action is to treat current Azure Monitor Agent maintenance as urgent hygiene rather than claim protection from a version Microsoft has not yet named. For Windows administrators, the key consequence is simple: this vulnerability will be remediated through Azure extension management, and fleets that rely solely on Windows Update reporting may not see the systems that need attention.