← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-42822 · CWE-287 · Disclosed 2026-05-18

Improper authentication in Azure Local Disconnected Operations

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"Technically nasty, operationally niche: treat this as a high-priority internal-control-plane bug, not a fleet-wide internet fire."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Get onto the Azure Local network segment

The attacker first needs IP reachability to the disconnected-operations appliance or its exposed ingress services. In practice that means using nmap or equivalent discovery tooling against an internal enclave, management VLAN, or tightly controlled tenant network rather than scanning the open internet.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: External attack-surface scanners are weak here because exposure is usually private. Internal network discovery, NAC telemetry, and east-west IDS are more useful than perimeter ASM.
STEP 02

Identify the vulnerable endpoint

With connectivity established, the attacker still has to find the specific service or API path where authentication is mishandled. That likely means 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.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Web/API scanners may find the product, but signature-level CVE detection is likely immature until vendors publish plugin coverage or a PoC appears.
STEP 03

Bypass authentication and obtain elevated role

The core exploit is an authentication failure that lets an unauthenticated request be treated as sufficiently trusted to gain higher privileges. A likely operator workflow would be replay and tampering through Burp Suite or handcrafted requests in curl or Python once the vulnerable control is mapped.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Best chance is authz/authn anomaly logging in the appliance, reverse proxy logs, and impossible-state events such as privileged actions with no valid preceding login.
STEP 04

Pivot from control plane to broader cluster impact

If exploitation succeeds, the attacker lands in the local control plane of Azure Local and can potentially manipulate workloads, configuration, or supporting infrastructure. At that point, ordinary admin tooling or native APIs are enough; the exploit itself stops mattering and this becomes a cloud-control-plane compromise inside your environment.
Conditions required:
  • Successful privilege elevation on the appliance
  • Role obtained is powerful enough to manage workloads or infrastructure
  • Downstream components trust the appliance's elevated identity
Where this breaks in practice:
  • 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
Detection/coverage: SIEM collection from the appliance syslog forwarder, host event logs, and cluster-management telemetry should catch post-exploit admin actions better than they catch the initial auth bypass.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found in primary sources reviewed; not in CISA KEV as of the reachable catalog.
Proof-of-concept availabilityNo 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.
EPSS0.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 statusNot listed in CISA's Known Exploited Vulnerabilities catalog.
CVSS and what it impliesCVSS: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 versionsNVD 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 versionTreat 2604.2.25645 or later as the patch floor based on NVD's Microsoft-derived CPE range.
Exposure realityMicrosoft 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 date2026-05-18.
Researcher / reporting creditsNot publicly credited in the reachable vendor and NVD materials reviewed.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to HIGH (7.8/10)

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.

HIGH Downgrade from vendor CRITICAL based on deployment exposure and attacker-position friction
MEDIUM Affected version floor of `2604.2.25645` from NVD/Microsoft-derived CPE mapping
LOW Exploit mechanics and exact vulnerable endpoint because Microsoft public detail is sparse

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# 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
}
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, pull an inventory of every Azure Local Disconnected Operations deployment, verify which ones are below 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

  1. NVD CVE-2026-42822
  2. Microsoft Security Update Guide - CVE-2026-42822
  3. Microsoft Learn - Security controls with disconnected operations for Azure Local
  4. Microsoft Learn - Disconnected operations for Azure Local overview
  5. Microsoft Learn - About updates for disconnected operations
  6. Microsoft Learn - Acquire disconnected operations for Azure Local
  7. CISA Known Exploited Vulnerabilities Catalog
  8. FIRST EPSS
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.