This is a master key left inside a locked bunker, not one hanging on the public front door
CVE-2026-42822 is an improper-authentication flaw in Azure Local Disconnected Operations that lets an unauthenticated attacker elevate privileges over the network. Publicly available details are thin, but NVD ties it to Azure Local versions earlier than 2604.2.25645, and Microsoft describes the product as a local control-plane appliance for sovereign, regulated, and disconnected environments rather than a broadly internet-facing cloud service.
Microsoft's 10.0/CRITICAL baseline reflects the *technical* worst case: no auth, no user interaction, network reachability, and full compromise potential. In the real world, that score overstates enterprise-wide urgency because this is a preview / specialized deployment, usually on private or isolated networks, and the attacker must first reach a narrow management or ingress path inside an environment that is explicitly designed to avoid broad external exposure.
4 steps from start to impact.
Get onto the Azure Local network segment
nmap or equivalent discovery tooling against an internal enclave, management VLAN, or tightly controlled tenant network rather than scanning the open internet.- Network path to the Azure Local disconnected-operations appliance
- Target environment actually deployed this preview feature
- Firewall rules expose the relevant ingress service to the attacker's segment
- Azure Local disconnected deployments are marketed for sovereign, regulated, remote, and isolated environments
- Many deployments will not be internet-exposed at all
- The reachable population is tiny compared with mainstream Microsoft server products
Identify the vulnerable endpoint
curl, Burp Suite, or custom HTTP tooling against the ingress interface, because Microsoft has not published endpoint-level technical details and I found no public exploit chain in primary sources.- A reachable service tied to disconnected operations
- Enough protocol knowledge to fingerprint the local control plane
- The vulnerable code path is exposed in the deployed configuration
- No public vendor write-up with exploit mechanics
- No public PoC identified during this review
- Feature-specific deployments vary and may expose different service sets
Bypass authentication and obtain elevated role
Burp Suite or handcrafted requests in curl or Python once the vulnerable control is mapped.- Target is running a vulnerable build earlier than
2604.2.25645 - Exploit path is reachable from the attacker's network location
- No compensating ACL or proxy layer blocks the malformed or unauthenticated request
- Ingress access may already be restricted to approved users or jump hosts
- Certificate-based controls protect the management NIC for some operations
- Identity-provider and RBAC integrations may reduce reachable surfaces outside the exact flaw path
Pivot from control plane to broader cluster impact
- Successful privilege elevation on the appliance
- Role obtained is powerful enough to manage workloads or infrastructure
- Downstream components trust the appliance's elevated identity
- Blast radius is largely bounded to the affected Azure Local deployment rather than every Microsoft asset you own
- Disconnected environments often have stricter segmentation and change control than commodity server tiers
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found in primary sources reviewed; not in CISA KEV as of the reachable catalog. |
|---|---|
| Proof-of-concept availability | No public PoC identified during this review. That is an analyst inference from the absence of vendor technical detail and lack of a discoverable public exploit repo, not proof that private exploit code does not exist. |
| EPSS | 0.00093 from the user-supplied intel block, which is a very low 30-day exploitation probability. Percentile was not independently verified from FIRST in this session. |
| KEV status | Not listed in CISA's Known Exploited Vulnerabilities catalog. |
| CVSS and what it implies | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H means Microsoft scored this as unauthenticated remote compromise with changed scope. That's the technical upper bound, not the deployment reality. |
| Affected versions | NVD maps the issue to Azure Local versions earlier than 2604.2.25645. Public Microsoft text available here does not provide a richer version narrative. |
| Fixed version | Treat 2604.2.25645 or later as the patch floor based on NVD's Microsoft-derived CPE range. |
| Exposure reality | Microsoft positions disconnected operations for sovereign, regulated, remote, and isolated use cases and says it helps reduce attack surface by not exposing systems to external networks. The appliance is reachable via a management NIC and an external/ingress NIC exposed to users in your network, which strongly suggests internal or enclave exposure, not broad internet population. |
| Disclosure date | 2026-05-18. |
| Researcher / reporting credits | Not publicly credited in the reachable vendor and NVD materials reviewed. |
noisgate verdict.
The single decisive factor is attacker position: this is an unauthenticated network bug in a niche, private, disconnected control-plane product, not a mass-exposed internet service. The technical impact is severe, but the reachable population and preconditions for access materially narrow real-world exploitation opportunities.
Why this verdict
- Downward adjustment: requires reachability into a specialized private environment — the product is built for disconnected/on-prem sovereign use, which implies post-perimeter or enclave access in many enterprises.
- Downward adjustment: narrow exposure population — this is a preview Azure Local feature on validated hardware, not a commodity Windows role on every subnet.
- Upward adjustment: unauthenticated network exploitation with control-plane blast radius — if an attacker reaches the vulnerable endpoint, compromise of the local control plane can have serious integrity and availability consequences.
Why not higher?
I am not calling this CRITICAL because the vendor score assumes the vulnerable service is broadly reachable like an internet-exposed auth bypass. Microsoft's own product positioning points the other way: private, disconnected, regulated deployments with constrained exposure. No KEV listing, no public exploitation evidence, and a very low EPSS score all reinforce that this is not behaving like an urgent internet wildfire.
Why not lower?
I am not dropping this to MEDIUM because the flaw is still unauthenticated over the network and sits in a management/control-plane context. Once the attacker is on the right segment, the blast radius can be substantial inside that Azure Local deployment, so this deserves real prioritization rather than backlog treatment.
What to do — in priority order.
- Restrict ingress exposure — Limit the disconnected-operations external/ingress NIC to approved admin, jump-host, or tenant subnets only, and block broad east-west access with ACLs or NGFW policy. For a HIGH verdict, deploy this compensating control within 30 days if patching cannot happen immediately.
- Force administration through jump hosts — Require operators to traverse hardened jump hosts or privileged access workstations before reaching Azure Local management paths. This reduces who can even touch the vulnerable surface and should be enforced within 30 days.
- Turn on appliance log forwarding — Use the Azure Local disconnected-operations syslog forwarding capability to push security events into your SIEM and alert on privileged actions without preceding successful authentication. For a HIGH finding, complete this telemetry hardening within 30 days.
- Cull unused preview deployments — If a lab, pilot, or preview disconnected-operations instance is not serving a real business need, remove or shut down its exposed paths rather than defending shelfware. Exposure reduction is the fastest risk cut and belongs within the same 30-day window.
- Perimeter-only internet blocking does not solve this if the attacker is already on the internal or enclave network where the ingress NIC is reachable.
- Tenant MFA or Azure-side identity hardening does not reliably neutralize an improper authentication flaw in the local control plane itself.
- EDR alone is weak as a preventive control here; it may help on post-exploit actions, but it does not stop a network auth-bypass request at the appliance boundary.
Crowdsourced verification payload.
Run this on an Azure Local seed node or appliance management host that has filesystem access to the disconnected-operations install/update files. Invoke it with powershell -ExecutionPolicy Bypass -File .\Test-CVE-2026-42822.ps1 -FixedVersion 2604.2.25645; local admin is recommended because some install paths and registry locations may be restricted.
# Test-CVE-2026-42822.ps1
# Checks for Azure Local Disconnected Operations version evidence and compares it
# to the fixed version floor for CVE-2026-42822.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
[CmdletBinding()]
param(
[Parameter(Mandatory=$false)]
[string]$FixedVersion = '2604.2.25645'
)
function Convert-ToVersionArray {
param([string]$Version)
if ([string]::IsNullOrWhiteSpace($Version)) { return $null }
$parts = $Version -split '\.'
$nums = @()
foreach ($p in $parts) {
if ($p -notmatch '^\d+$') { return $null }
$nums += [int]$p
}
return ,$nums
}
function Compare-VersionString {
param(
[string]$A,
[string]$B
)
$va = Convert-ToVersionArray $A
$vb = Convert-ToVersionArray $B
if ($null -eq $va -or $null -eq $vb) { throw "Invalid version comparison: '$A' vs '$B'" }
$max = [Math]::Max($va.Count, $vb.Count)
for ($i = 0; $i -lt $max; $i++) {
$ai = if ($i -lt $va.Count) { $va[$i] } else { 0 }
$bi = if ($i -lt $vb.Count) { $vb[$i] } else { 0 }
if ($ai -lt $bi) { return -1 }
if ($ai -gt $bi) { return 1 }
}
return 0
}
function Get-VersionFromTextFile {
param([string]$Path)
try {
if (-not (Test-Path -LiteralPath $Path -PathType Leaf)) { return $null }
$raw = Get-Content -LiteralPath $Path -Raw -ErrorAction Stop
# Prefer Azure Local style versions such as 2604.2.25645
$matches = [regex]::Matches($raw, '\b\d{4}\.\d+\.\d{4,5}\b')
if ($matches.Count -gt 0) {
$versions = $matches | ForEach-Object { $_.Value } | Sort-Object -Unique
return $versions[-1]
}
# Fallback to generic x.y.z(.w) versions
$matches = [regex]::Matches($raw, '\b\d+\.\d+\.\d+(?:\.\d+)?\b')
if ($matches.Count -gt 0) {
$versions = $matches | ForEach-Object { $_.Value } | Sort-Object -Unique
return $versions[-1]
}
}
catch {
return $null
}
return $null
}
function Add-Candidate {
param(
[ref]$List,
[string]$Source,
[string]$Version
)
if (-not [string]::IsNullOrWhiteSpace($Version)) {
$List.Value += [pscustomobject]@{
Source = $Source
Version = $Version
}
}
}
$candidates = @()
# Common disconnected-operations paths documented by Microsoft Learn
$pathsToProbe = @(
'C:\AzureLocalDisconnectedOperations\AzureLocal.DisconnectedOperations.Appliance.manifest',
'C:\AzureLocalDisconnectedOperations\OperationsModule\Azure.Local.DisconnectedOperations.psd1',
'C:\AzureLocalDisconnectedOperations\OperationsModule\Azure.Local.DisconnectedOperations.psm1',
'C:\azurelocal\OperationsModule\Azure.Local.DisconnectedOperations.psd1'
)
foreach ($p in $pathsToProbe) {
$ver = Get-VersionFromTextFile -Path $p
Add-Candidate -List ([ref]$candidates) -Source $p -Version $ver
}
# Probe installed PowerShell modules if present
try {
$mods = Get-Module -ListAvailable 'Azure.Local.DisconnectedOperations' -ErrorAction SilentlyContinue |
Sort-Object Version -Descending
foreach ($m in $mods) {
if ($m.Version) {
Add-Candidate -List ([ref]$candidates) -Source ("Module:" + $m.Path) -Version $m.Version.ToString()
}
}
}
catch {}
# Probe uninstall registry for any Azure Local disconnected operations package
$regPaths = @(
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
foreach ($rp in $regPaths) {
try {
Get-ItemProperty $rp -ErrorAction SilentlyContinue | ForEach-Object {
$name = $_.DisplayName
$ver = $_.DisplayVersion
if ($name -and $name -match 'Azure Local|Disconnected Operations' -and $ver) {
Add-Candidate -List ([ref]$candidates) -Source ("Registry:" + $name) -Version $ver
}
}
}
catch {}
}
if ($candidates.Count -eq 0) {
Write-Output 'UNKNOWN: No Azure Local Disconnected Operations version evidence found on this host.'
exit 2
}
# Select the highest parseable version discovered
$best = $null
foreach ($c in $candidates) {
try {
if ($null -eq $best) {
$best = $c
continue
}
if ((Compare-VersionString -A $c.Version -B $best.Version) -gt 0) {
$best = $c
}
}
catch {
continue
}
}
if ($null -eq $best) {
Write-Output 'UNKNOWN: Version evidence was found but could not be parsed.'
exit 2
}
try {
$cmp = Compare-VersionString -A $best.Version -B $FixedVersion
if ($cmp -lt 0) {
Write-Output ("VULNERABLE: Detected version {0} from {1}; fixed floor is {2}." -f $best.Version, $best.Source, $FixedVersion)
exit 1
}
else {
Write-Output ("PATCHED: Detected version {0} from {1}; fixed floor is {2}." -f $best.Version, $best.Source, $FixedVersion)
exit 0
}
}
catch {
Write-Output ("UNKNOWN: Failed to compare detected version '{0}' with fixed floor '{1}'. Error: {2}" -f $best.Version, $FixedVersion, $_.Exception.Message)
exit 2
}
If you remember one thing.
2604.2.25645, and immediately cut exposure down to named admin/jump-host networks only. For this HIGH verdict, use the noisgate mitigation SLA to get segmentation, access restriction, and logging controls in place within 30 days, then complete the vendor update under the noisgate remediation SLA within 180 days; if you find any instance reachable from broad corporate user networks, move that one to the front of the queue.Sources
- NVD CVE-2026-42822
- Microsoft Security Update Guide - CVE-2026-42822
- Microsoft Learn - Security controls with disconnected operations for Azure Local
- Microsoft Learn - Disconnected operations for Azure Local overview
- Microsoft Learn - About updates for disconnected operations
- Microsoft Learn - Acquire disconnected operations for Azure Local
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.