TL;DR: Microsoft patched CVE-2026-26119 in Windows Admin Center after research showed authentication reflection could let a low-privileged domain user coerce machine authentication, relay it to the management gateway, and reach SYSTEM access, with full domain compromise possible under the right conditions, according to Semperis. The issue shows how relay-resistant assumptions fail when web-based admin tools depend on authentication flows that were never designed for hostile coercion.
At a glance
What this is: This is Semperis analysis of CVE-2026-26119 in Windows Admin Center, showing how authentication reflection could turn a low-privileged domain user into SYSTEM-level control on exposed management systems.
Why it matters: IAM and PAM teams should treat admin-plane authentication paths as attack surfaces, because relayable trust assumptions can collapse into domain compromise even when the endpoint is meant to reduce direct PowerShell exposure.
By the numbers:
- Microsoft released an out-of-band patch for Windows Admin Center with CVE-2026-26119 on February 17, 2026.
- The initial fix was released on January 13, 2026 as CVE-2026-20929.
- The vulnerability was submitted to Microsoft on July 8th, 2025.
👉 Read Semperis's analysis of Windows Admin Center authentication reflection and CVE-2026-26119
Context
Windows Admin Center is a browser-based management platform for privileged Windows administration, and the issue here is not the web UI itself but the trust model behind it. Authentication reflection let an attacker manipulate machine authentication in a way that the gateway accepted as legitimate, turning management convenience into a privileged execution path.
For identity teams, the lesson is that administrative access controls must be evaluated at the protocol layer as well as the application layer. A tool can reduce direct PowerShell exposure and still create a dangerous path if it accepts reflected or relayed authentication in an admin workflow.
Key questions
Q: What breaks when authentication reflection is possible on a privileged Windows admin portal?
A: The trust boundary breaks between the client session and the management action. A low-privileged domain user can coerce authentication, relay it into the portal, and inherit a privileged management context that was supposed to stay bound to the original transport and endpoint.
Q: Why do Windows admin gateways create such high-risk identity exposure when AD CS is nearby?
A: Because the management plane is no longer just an interface. If it can execute commands on or adjacent to certificate services, compromise of the gateway can cascade into trusted certificate issuance, which is a much stronger and longer-lived identity primitive than a session token.
Q: How can security teams tell whether channel binding protections are actually working?
A: They should validate the control by testing reflected and relayed authentication flows on each supported host version and gateway path. If the same authentication succeeds across different transports or survives coercion, the protection is not being enforced where the decision occurs.
Q: Who is accountable when a management portal allows relay into certificate infrastructure?
A: Accountability sits with the system owner, the platform team, and the identity team together, because the failure spans application design, host enforcement, and downstream trust architecture. Frameworks such as NIST CSF and zero trust treat that as shared control ownership, not a single-team defect.
Technical breakdown
How authentication reflection turns trusted Windows auth into relay access
Authentication reflection abuses a system that accepts authentication material from a client and then reuses it in a way the attacker can redirect. In this case, the attacker coerced machine authentication and reflected it into Windows Admin Center over HTTP, where the gateway accepted the session and issued privileged cookies and anti-forgery tokens. The subtlety is that the request sequence still looks like normal integrated authentication, so the abuse hides inside legitimate protocol behaviour rather than obvious malformed input.
Practical implication: block relay-prone authentication paths on privileged web gateways and do not assume Windows Integrated Authentication alone makes an admin plane safe.
Why Kestrel changed the protection model for channel binding
Channel binding tokens help tie authentication to the transport that initiated it, which is how extended protection limits relay attacks. The article shows that Windows Admin Center ran on Kestrel rather than IIS, and EPA was not effectively enforced until Microsoft backported and then aligned the behaviour with HTTP.SYS. That meant the backend accepted authentication without the transport constraints that would have prevented reflection, so the application inherited the platform’s gap instead of adding its own control.
Practical implication: verify where channel binding is actually enforced in the stack, because relying on the web app layer alone can leave relay resistance absent.
Why remote code execution on the admin gateway becomes domain compromise
Once the attacker could execute code as NT AUTHORITY\SYSTEM on a server hosting Windows Admin Center and AD CS, the privilege boundary collapsed from local admin-plane compromise into certificate authority compromise. SYSTEM access on AD CS lets an attacker back up CA keys and forge certificates for privileged identities, including Domain Admins. This is why the impact is not just command execution, but a path to persistent and highly trusted identity compromise across the domain.
Practical implication: treat management servers that host certificate services as crown-jewel identity infrastructure and isolate them from reflection-capable administration paths.
Threat narrative
Attacker objective: The attacker aims to obtain SYSTEM-level control over the management host and ultimately forge trusted certificates that enable domain-wide privilege.
- Entry occurred when a low-privileged authenticated domain user coerced machine authentication through RPC/DCOM and targeted the Windows Admin Center HTTP service.
- Credential access followed when the attacker reflected the authentication back into the gateway, bypassing the expected transport-bound trust model and obtaining valid session material.
- Escalation happened after the attacker used the management endpoint to execute code as SYSTEM on a host running Windows Admin Center and AD CS.
- Impact was full domain compromise potential, because SYSTEM access on AD CS allowed backup of CA keys and certificate forgery for privileged accounts.
Breaches seen in the wild
- Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.
- DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Authentication reflection is a trust failure, not just a web bug. The problem is that the gateway accepted identity material in a way that assumed the transport and the client context were trustworthy. That assumption breaks when an attacker can coerce and replay authentication across protocols, which is why admin-plane identity controls need to be validated at the binding layer, not only at login. Practitioners should treat reflected authentication as a privilege boundary collapse, not a nuisance flaw.
EPA absence in the admin stack created a standing relay window. The article shows that Windows Admin Center on Kestrel did not benefit from the transport enforcement that HTTP.SYS later applied by default on newer Windows releases. That is a named control gap, not a generic hardening issue: the reflected session was possible because channel binding was not consistently enforced where the trust decision happened. The implication is that platform defaults, not just application code, determine whether relay resistance actually exists.
Domain compromise through an admin portal is a lifecycle problem as much as an exploitation problem. A management plane that can reach AD CS has identity blast radius far beyond its own UI. Once SYSTEM is available on certificate infrastructure, certificate issuance and trusted identity issuance become part of the attack surface. Practitioners should understand that the governance model for privileged admin tools must include downstream identity assets, not just the endpoint itself.
Named concept: reflected admin-plane trust debt. This flaw shows how legacy management tools accumulate hidden trust debt when they depend on authentication patterns that were designed for cooperative clients, not coercive ones. The deeper issue is that least privilege was defined for interactive administration, while the actual runtime behaviour allowed machine authentication to be reflected into an elevated session. Security teams should read this as evidence that admin convenience can embed unpriced identity risk for years.
Windows Admin Center exemplifies why identity controls and transport controls cannot be separated in privileged access design. Authentication, channel binding, and endpoint role are part of one chain, and breaking any link changes the security outcome. When the management service can execute commands and reach certificate services, the platform becomes an identity control point, not just an admin UI. Practitioners should reassess every privileged web console as a potential identity infrastructure component.
From our research:
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which shows how quickly delegated access can outgrow governance.
- Read NHI Lifecycle Management Guide for the offboarding and rotation controls that reduce standing trust in privileged machine access.
What this signals
Reflected authentication is a reminder that privileged access tooling now sits inside the identity control plane, not outside it. If a management console can reach certificate services, the operational boundary is already an identity boundary. Teams should review every admin portal for downstream trust anchors, then align isolation and audit controls to the systems it can touch, not just the portal itself.
Reflected admin-plane trust debt: this is the pattern where a management tool inherits security assumptions from older authentication models and quietly carries them forward into modern deployments. The practical signal for programmes is simple: if a control depends on the original transport remaining trustworthy, it may fail the moment an attacker can coerce or replay the session.
Windows environments that still mix browser-based administration, integrated authentication, and certificate services should be prioritised for design review. Teams should pair host-version checks with privilege-path mapping, then use OWASP Non-Human Identity Top 10 guidance to frame the non-human access risk that emerges when system-level trust is reachable through a web gateway.
For practitioners
- Map every privileged web console to its downstream identity blast radius Inventory whether the management plane can reach AD CS, domain controllers, or other trust anchors. If a console can execute code or trigger admin actions on those systems, classify it as identity infrastructure and apply stricter segmentation, logging, and approval controls.
- Verify where channel binding is enforced in the stack Test whether EPA or equivalent CBT enforcement happens in the app, the reverse proxy, or HTTP.SYS, and confirm the behaviour on every Windows version you support. If enforcement differs by host OS, treat that as a version-specific exposure, not a configuration detail.
- Block coercion paths that can trigger machine authentication Harden RPC, DCOM, and other coercion vectors that let an attacker force machine auth toward an HTTP endpoint. Pair that with signing requirements, service reduction, and RPC filters so the trust decision cannot be replayed into privileged management endpoints.
- Isolate AD CS from relay-capable administration channels Do not host certificate services on systems that are reachable through admin tools accepting Windows Integrated Authentication unless the transport binding is demonstrably enforced. Keep certificate authorities in a separate trust zone and monitor for any code execution that touches CA key material.
Key takeaways
- Authentication reflection turned a browser-based admin tool into a path to SYSTEM access, which means the vulnerability was a trust-boundary failure, not just a code-execution bug.
- The scale of impact was domain compromise potential, because control of a certificate authority host can let an attacker forge trusted certificates for privileged identities.
- Transport-bound authentication enforcement, coercion-path hardening, and isolation of certificate services are the controls that would have prevented or sharply limited this abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | The flaw centers on risky non-human authentication and relayable secrets. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero trust requires transport-bound verification for privileged access decisions. |
| NIST CSF 2.0 | PR.AC-1 | The incident exposed weak control over who can reach privileged identity infrastructure. |
Map privileged management tools to access boundaries and constrain their reach into crown-jewel systems.
Key terms
- Authentication Reflection: Authentication reflection is an attack technique where a valid authentication exchange is coerced and replayed back to a service that accepts it as trusted. In privileged Windows environments, the danger is that a legitimate-looking session can be redirected into elevated access without the user or system expecting the transport to be hostile.
- Channel Binding Token: A channel binding token links authentication to the specific transport session that initiated it. When enforced correctly, it makes replay and relay attacks much harder because the authentication material cannot simply be moved to another connection and reused as if nothing changed.
- Extended Protection for Authentication: Extended Protection for Authentication is a set of safeguards that bind authentication to the right endpoint and transport context. For admin tooling, it reduces relay risk, but only when the enforcement point is actually active in the host or middleware path that makes the trust decision.
- Identity Blast Radius: Identity blast radius is the total downstream impact a compromised identity or management plane can have across authentication, authorization, and trust issuance. In this case, the blast radius extends beyond the portal itself because access to certificate infrastructure can reshape the trust fabric of the domain.
Deepen your knowledge
Authentication reflection, channel binding, and privileged management-plane exposure are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are governing Windows admin tooling or certificate infrastructure, it is a relevant starting point.
This post draws on content published by Semperis: Windows Admin Center authentication reflection, CVE-2026-26119, and domain compromise risk. Read the original.
Published by the NHIMG editorial team on 2026-03-23.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org