Windows Admin Center privilege escalation shows trust-boundary gaps

At a glance

What this is: This is an analysis of CVE-2025-64669 in Windows Admin Center, where insecure directory permissions enabled local privilege escalation to SYSTEM.

Why it matters: It matters because administrative tooling often sits at the center of Windows operations, so one writable path can become a privilege boundary failure across server and endpoint management.

By the numbers:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Cymulate's analysis of CVE-2025-64669 in Windows Admin Center

Context

Windows Admin Center is a privileged management plane, so a local write weakness in its data path is not a cosmetic configuration issue. It becomes a trust-boundary problem when the platform executes scripts or loads binaries from locations standard users can modify. For identity and access teams, the lesson is that administrative tooling needs the same control scrutiny as the workloads it manages, including service accounts, privileged workflows, and filesystem permissions.

This case is a classic example of how local privilege escalation often starts with a narrow permission mistake and ends with full system compromise. The article shows two execution paths, one through extension uninstall logic and one through updater DLL hijacking, which makes the governance issue broader than a single bug. That pattern is common in infrastructure tools that mix convenience, automation, and elevated execution.

The identity angle is indirect but real: privileged workflows, signed scripts, and updater processes behave like high-risk machine identities. When those processes trust user-writable paths, they create an NHI-style abuse surface even in a Windows administration context.

Key questions

Q: What breaks when a management tool trusts user-writable paths?

A: A writable path turns a storage location into an execution surface if a privileged process reads scripts or DLLs from it. The failure is not just local access, but privilege amplification. Standard users can shape content that SYSTEM later consumes, so the control gap is usually path integrity, not authentication.

Q: Why do privileged Windows services create high-risk trust assumptions?

A: Privileged services often assume that files in their working directories are trustworthy because the directories are local and operational. That assumption fails when standard users can write to those locations. Once that happens, service identity, filesystem permissions, and execution context become one attack chain rather than separate controls.

Q: How can security teams measure whether local privilege escalation risk is actually controlled?

A: Track whether any privileged process executes from user-modifiable directories, whether ACLs on management paths are restrictive, and whether detections exist for script or DLL replacement between validation and load. If you cannot answer those three questions quickly, the control is not operating reliably.

Q: Who is accountable when a management-plane flaw exposes administrative access?

A: The owning platform team and the identity governance function share accountability, because the flaw spans application design and privileged access control. Management consoles should be governed like identity infrastructure, with clear ownership for redirect policy, token handling, session design, and secure update response when flaws are found.

Technical breakdown

Why writable program data becomes a privilege boundary problem

Windows Admin Center stored operational files under C:\ProgramData\WindowsAdminCenter, but that location was writable by standard users. When privileged services later read, execute, or load content from that tree, filesystem access becomes an access-control issue rather than a simple storage issue. The danger is not the folder itself, but the combination of writable paths and trusted execution context. In identity terms, this is a machine-identity trust failure: a privileged process is effectively delegating authority to content an unprivileged user can shape.

Practical implication: treat writable application directories as privileged attack surface and remove user write access wherever elevated processes depend on that path.

How extension uninstall logic can be abused for code execution

The uninstall path executed PowerShell scripts found in an extension uninstall folder with elevated privileges. That means the application assumed whatever was present in the directory was legitimate, then ran it as part of its administrative workflow. Even with AllSigned in place, a signing trust model can still fail if an attacker can plant, replace, or abuse approved script material. The issue is a classic execution-of-untrusted-content problem inside a management product.

Practical implication: restrict script discovery paths, verify script provenance before execution, and separate uninstall orchestration from user-modifiable storage.

How updater DLL hijacking and TOCTOU defeat validation

The updater process loaded DLLs from a writable updater directory, which created the conditions for DLL hijacking. Cymulate then showed a time-of-check time-of-use gap: validation happened first, but the malicious DLL could be swapped in before the updater process loaded it. That means integrity checks were not tied tightly enough to runtime loading. This is a control design problem, not just a detection problem. When update workflows rely on a directory that low-privileged users can write to, the privileged process becomes a loader for attacker-controlled code.

Practical implication: lock down update directories, bind validation to the exact file instance being executed, and monitor for post-check file replacement.

Threat narrative

Attacker objective: The attacker aims to turn ordinary local access into SYSTEM-level control of the Windows Admin Center host.

1. Entry occurred through a writable Windows Admin Center directory that standard users could modify locally.
2. Escalation followed when the product executed trusted uninstall scripts or loaded updater DLLs from that user-writable path.
3. Impact was SYSTEM-level code execution on the host, breaking the Windows security boundary and enabling full local compromise.

Breaches seen in the wild

• Gravity SMTP CVE-2026-4020 API Keys Exposure — CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.
• Gladinet Hard-Coded Keys RCE Exploitation — Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Writable management paths create a hidden privilege plane: This vulnerability is not just about a bad directory permission. It shows that management tooling often creates a second, weaker access layer where filesystem write access can override intended administrative controls. In practice, privileged automation is only as safe as the least protected path it trusts.

Signed execution does not compensate for unsafe trust placement: The uninstall abuse shows that script signing is not enough if an attacker can influence what the privileged process discovers and runs. Security teams need to distinguish code trust from location trust, because both have to hold at the same time. Otherwise, signing becomes a thin control around a broken workflow.

Updater integrity is a runtime control problem, not a packaging problem: The DLL hijacking path highlights a common assumption failure, namely that a pre-execution check is sufficient. It is not, if the file can be swapped after validation and before load. This is a useful reminder for broader Windows hardening, especially where privileged services and writable directories intersect.

Machine identity governance now includes local execution boundaries: Although this is a Windows vulnerability, the underlying issue looks familiar to NHI governance teams. A privileged service behaves like a high-trust non-human identity, and its filesystem dependencies become part of its identity boundary. That makes least privilege, path integrity, and execution provenance relevant to IAM and PAM programmes as well as endpoint teams.

Privilege escalation in management planes exposes governance debt: The named concept here is management plane trust leakage. It describes what happens when administrative tools inherit user-writable state into privileged workflows. Practitioners should treat this as a governance defect, because it widens blast radius and undermines any zero-trust narrative around the management tier.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs , Key Research and Survey Results.
• Related finding: 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Forward look: Review Ultimate Guide to NHIs , Key Challenges and Risks for the visibility, rotation, and privilege gaps that keep management-plane trust failures alive.

What this signals

Management-plane trust leakage is now a practical governance issue for both endpoint teams and identity programmes. When a privileged service can consume user-writable content, the organisation has effectively created a second privilege boundary that sits outside normal IAM review. That means hardening directory ACLs, service execution paths, and updater behavior should be treated as part of privileged access control, not just patching hygiene.

The broader signal is that Windows administration tools increasingly behave like high-value machine identities. They authenticate actions, execute code, and broker privileged workflows, which means their security depends on lifecycle controls that identity teams already recognise. Service visibility, execution provenance, and offboarding of stale administrative components matter because a management plane compromise can become a host-level compromise very quickly.

Teams should also expect more scrutiny of administrative plugins, update channels, and local script execution in 2026 patch planning. The practical question is not whether a product has a CVE, but whether the surrounding operational model allows untrusted content to reach privileged execution. That is where the next control failure usually appears, before detection can reliably stop it.

For practitioners

• Harden writable management directories Remove standard-user write access from Windows Admin Center program data and any sibling folders that privileged services consume. Review inherited ACLs on C:\ProgramData\WindowsAdminCenter, updater paths, and extension folders before deployment or patching.
• Separate execution from user-controlled content Refactor uninstall and update workflows so privileged processes never execute scripts or load binaries from user-writable locations. Where that is not immediately possible, add provenance checks and isolate execution to signed, immutable staging paths.
• Monitor for privilege escalation indicators Use endpoint telemetry and SIEM detections for suspicious PowerShell execution, DLL placement in updater directories, and child processes launched by WAC components. Map these signals to Windows Admin Center service accounts and local admin activity.
• Validate exposure with attack simulation Test Windows Admin Center instances against the published CVE scenario and confirm whether standard users can influence extension uninstall or updater behavior. This is the fastest way to verify whether the vulnerable trust path still exists in production.
• Review administrative tool trust models Inventory every management plane that mixes browser-based administration, privileged services, and writable filesystem state. Prioritise products where script discovery, plugin handling, or auto-update behavior depends on local paths.

Key takeaways

• The breach revealed a management-plane trust failure, where writable directories became a path to SYSTEM-level execution.
• The impact was not theoretical, because Cymulate demonstrated two distinct escalation paths that both crossed the Windows security boundary.
• The control that matters most is path integrity, combining strict ACLs, immutable execution sources, and runtime validation tied to the exact file being loaded.

Key terms

• Privilege Escalation: An attack technique where a compromised identity — often an NHI with initially limited permissions — exploits vulnerabilities or misconfigurations to gain elevated access rights, typically leading to broader compromise.
• DLL Hijacking: DLL hijacking occurs when an application loads a dynamic library from a location an attacker can control. If a privileged process searches a writable directory first, the attacker can replace or plant a library that the process loads and executes with elevated rights.
• Time-Of-Check/Time-Of-Use Flaw: A race condition where a system validates something, then later acts on a value that can change in the meantime. In agent systems, this can turn a trusted file path or command into an unsafe action, creating escapes, tampering, or persistence.
• Management Plane: The administrative layer used to configure, govern, and enforce behaviour across many endpoints or services. A management plane is not the workload itself. It is the control layer above it, which makes it especially sensitive to privileged misuse and delegated automation.

What's in the full report

Cymulate's full analysis covers the operational detail this post intentionally leaves for the source:

• Step-by-step exploit paths for extension uninstall abuse and updater DLL hijacking
• The exact proof-of-concept flow used to trigger SYSTEM execution from a low-privileged account
• Disclosure timeline details, including Microsoft validation and patching milestones
• Validation guidance for testing Windows Admin Center exposure in live environments

👉 Cymulate's full post covers the exploit paths, proof-of-concept steps, and disclosure timeline

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives practitioners a structured way to connect privilege, lifecycle, and control design across identity programmes.