What is the CVSS score of CVE-2025-59494?

CVE-2025-59494 has a CVSS 3.1 base score of 7.8 (High). CVSS vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.6%.

Which versions of Azure Monitor Agent are affected by CVE-2025-59494?

Microsoft Azure Monitor Agent (AMA) contains a high-severity local privilege escalation flaw that could allow an attacker with an existing low-privileged foothold on a monitored Azure VM, VM scale…

How to fix or mitigate CVE-2025-59494?

Within 24 hours, inventory every Azure VM, VM scale set, and Azure Arc-enabled server running Microsoft Azure Monitor Agent (AMA; all versions tracked by CPE), confirm which have monitoring enabled, restrict interactive local logon and administrative rights to only necessary accounts, and verify no untrusted low-privileged users have local access. Within 7 days, implement interim hardening: enforce least privilege on monitored hosts, enable enhanced monitoring for anomalous privilege escalation or suspicious AMA process behavior, review Microsoft's advisory for mitigations, and consider temporarily disabling AMA only on non-critical hosts if equivalent monitoring visibility can be maintained. Within 30 days, apply the vendor-released patch as soon as Microsoft publishes an exact fixed AMA version, validate patched hosts through rescanning, and update incident response runbooks to detect and contain local privilege escalation on monitored Azure and Arc systems.

Azure Monitor Agent CVE-2025-59494

HIGH

Improper Access Control (CWE-284)

2025-10-14 secure@microsoft.com

Authentication Bypass Microsoft Azure Monitor Agent

7.8

CVSS 3.1 · Vendor: microsoft

Severity by source

Vendor (microsoft) PRIMARY

7.8 HIGH

AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

vuln.today AI

7.8 HIGH

Local privilege escalation requiring an existing low-privilege account (AV:L, PR:L), easily repeatable (AC:L), yielding full host compromise (C:H/I:H/A:H) with no scope change.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (microsoft).

CVSS VectorVendor: microsoft

Attack Vector

Local

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Oct 08, 2026 - 13:03 vuln.today

CVE Published

Oct 14, 2025 - 17:16 cve.org

HIGH 7.8

DescriptionCVE.org

Improper access control in Azure Monitor Agent allows an authorized attacker to elevate privileges locally.

AnalysisAI

Privilege escalation in Microsoft Azure Monitor Agent lets a locally authenticated, low-privileged user on a monitored host abuse improper access controls in the agent to gain elevated (SYSTEM/root) rights. The CPE cpe:2.3:a:microsoft:azure_monitor_agent:*:*:*:*:*:*:*:* tracks the agent across all versions, so any host actually running AMA - typically Azure VMs, VM scale sets, and Azure Arc-enabled servers with monitoring enabled - is in scope. Exploitation is local-only (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) and requires a pre-existing foothold with low-privileged access; no public exploit identified at time of analysis, and EPSS sits at 0.64% (49th percentile), so this is a credible post-compromise escalation rather than an emergency-level remote threat.

Technical ContextAI

The root cause class is CWE-284 (Improper Access Control), and the assigned vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H confirms a local privilege-escalation pattern: an attacker who already holds a valid low-privileged session on the host (PR:L) can act without user interaction (UI:N) and achieve high confidentiality, integrity, and availability impact under a single security scope. In practice this class typically means the agent's privileged service or its supporting artifacts - install and data directories, configuration files, service/named-pipe endpoints, or scheduled components - do not adequately restrict access by non-administrative principals, allowing a low-privileged user to modify agent-controlled resources that are subsequently consumed by a higher-integrity process, thereby crossing an integrity boundary. Microsoft assigns this to the Azure Monitor Agent, the telemetry collection component that runs with elevated privileges on monitored machines to gather logs and metrics and forward them to Azure Monitor via the Data Collection Rules/endpoints pipeline; because it must run with high rights to read protected data, a flaw in how it gates access to its own resources is directly privilege-relevant. The available data does not identify which specific component or configuration is misconfigured, nor whether the issue is confined to a particular OS platform or agent build; treat the entire AMA deployment surface as potentially affected until the MSRC advisory is consulted.

RemediationAI

Microsoft's authoritative guidance is the MSRC update guide for CVE-2025-59494 (https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-59494), which is the source to consult for the corrected agent build and deployment instructions; the input data does not specify an exact fixed version number, so do not assume a version - verify the patched build against that advisory. Practically, apply the remediation by updating the Azure Monitor Agent extension on every affected host (Azure portal extension update, AutoUpdate on the AMA extension, PowerShell/Azure CLI extension upgrade, or Arc agent extension upgrade) and confirm the running agent version afterward, since hosts with extension auto-update disabled or pinned versions will otherwise remain unpatched. If immediate fleet-wide updating is not feasible, targeted compensating controls reduce exposure but each has trade-offs: remove unnecessary local interactive accounts and enforce least privilege on monitored hosts (limits who can reach the PR:L precondition, but does not fix the underlying ACL flaw); audit and tighten permissions on the agent's install, data, and configuration paths and on the agent service itself so non-administrative principals have no write access (effective hardening, but ACL changes made outside supported configuration can break telemetry collection, so validate in a pilot ring); enable EDR/auditing for suspicious local elevation, agent service restarts, or unexpected modification of agent files (detective only, requires tuning to avoid alert noise). Disabling or uninstalling the agent should not be used as a mitigation because it eliminates all monitoring and security telemetry from the host, which is a materially worse security posture than the risk being avoided.