← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-21509 · CWE-807 · Disclosed 2026-01-26

Reliance on untrusted inputs in a security decision in Microsoft Office

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

This is a forged backstage pass that convinces Office to let a malicious object slip past the bouncer

CVE-2026-21509 is a Microsoft Office *security feature bypass* rooted in CWE-807: Office makes a trust decision using attacker-influenced input, letting a crafted document sidestep OLE/COM protections that should block unsafe embedded content. Microsoft/NVD list affected product families including Office 2016, Office 2019, Microsoft 365 Apps for enterprise, Office LTSC 2021, and Office LTSC 2024; third-party reporting tied the urgent manual patching need mainly to Office 2016 and 2019, while Office 2021+ / Microsoft 365 Apps were reported as covered by a service-side protection change after app restart.

Microsoft calling this HIGH is fair *because KEV and real-world abuse erase any benefit of the "local" CVSS tag*. But this is not an unauthenticated internet edge bug: the attacker still needs document delivery and user execution, and the blast radius is usually one workstation at a time. Without active exploitation, I would have pushed this downward; with KEV and APT28 tradecraft around it, I keep it solidly HIGH.

"KEV keeps this in HIGH, but it is still a phishing-to-endpoint problem, not a wormable edge crisis"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a weaponized Office document

Observed campaigns used spearphishing attachments and localized lures to put a malicious Word document in front of the victim. In reporting tied to APT28, the initial delivery was not some magical network exploit; it was old-fashioned document delivery using believable themes and targeting.
Conditions required:
  • Attacker can reach users over email, chat, file-share, or another content channel
  • Target uses a vulnerable Office build or an un-restarted service-side protected build
  • User receives the crafted DOC/RTF content
Where this breaks in practice:
  • Secure email gateways can detonate or quarantine suspicious Office attachments
  • Attachment stripping, sandboxing, and Protected View reduce reach
  • Not every enterprise still allows legacy embedded-object workflows from the internet
Detection/coverage: Email security products, detonation sandboxes, and DLP often see this step. Traditional perimeter vuln scanners do not.
STEP 02

User opens the file in Office

The CVSS vector correctly bakes in UI:R: someone has to open or otherwise trigger rendering of the malicious document. In the reported campaigns, simply opening the file was enough to start the malicious chain, so this is less brittle than macro-based lures but still depends on human execution.
Conditions required:
  • Victim opens the document in Word/Office
  • Office trust controls do not fully block the content path
Where this breaks in practice:
  • Protected View, Attack Surface Reduction rules, and file-origin hardening can interrupt execution
  • User awareness and suspicious-file workflows still matter here
Detection/coverage: EDR and Office telemetry can flag suspicious child-process, COM, or network behavior after document open; scanner coverage before execution is uneven.
STEP 03

Bypass OLE/COM safeguards

The exploit abuses Office's trust logic around OLE mitigations / COM controls, with third-party analysis specifically pointing to Shell.Explorer.1 as the object abused in mitigation guidance. This is the decisive technical step: the document persuades Office to treat attacker-controlled content as safe enough to proceed.
Conditions required:
  • Vulnerable Office logic is present
  • Relevant COM/OLE object is still usable
  • Kill-bit or equivalent mitigation is absent
Where this breaks in practice:
  • Registry-based COM compatibility mitigation can break the chain
  • Newer serviced Office channels may already be covered after restart
  • Application control and hardened document handling reduce follow-on execution
Detection/coverage: Registry posture checks can verify the mitigation; runtime detection depends on EDR visibility into COM object activation and Office process behavior.
STEP 04

Pull second stage and establish foothold

Campaign reporting describes WebDAV retrieval, LNK/DLL staging, COM hijacking, and follow-on payloads such as COVENANT Grunt. That means the bypass itself is rarely the end goal; it is the entry ramp to a broader workstation compromise and post-exploitation chain.
Conditions required:
  • Outbound connectivity to attacker infrastructure or abused cloud storage
  • Endpoint defenses fail to stop the dropped/loaded payload
  • User context is sufficient for persistence or payload execution
Where this breaks in practice:
  • EDR, AMSI-adjacent telemetry, process injection detection, and proxy controls can stop later stages
  • Per-host compromise limits immediate blast radius compared with server-side RCE
Detection/coverage: Best detection is behavioral: Office spawning unusual helpers, WebDAV traffic, LNK/DLL staging, COM hijack registry writes, scheduled task creation, and beaconing to cloud-hosted C2.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusYes. NVD flags the CVE as present in CISA KEV, and reporting links exploitation to APT28/UAC-0001 campaigns observed days after disclosure.
KEV statusListed in CISA KEV on 2026-01-26 with a due date of 2026-02-16 in NVD's mirrored KEV metadata.
Proof-of-concept / weaponizationI did not find a primary-source-confirmed, broad public GitHub exploit to anchor on. What *is* documented is real weaponization in targeted campaigns, plus public detection and mitigation scripts from Vicarius.
EPSSUser-supplied EPSS is 0.15294. That is meaningful, but KEV matters more than EPSS here because exploitation is no longer hypothetical.
CVSS vector reality checkCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H means no privileges required, but also local attack path and required user interaction. That is classic client-side phishing territory, not drive-by edge compromise.
Affected version rangesNVD CPEs include Office 2016, Office 2019, Microsoft 365 Apps for enterprise, Office LTSC 2021, and Office LTSC 2024 across x86/x64. Third-party patch reporting says Office 2016/2019 required explicit update action, while 2021+ / Microsoft 365 Apps were protected by a service-side change after restart.
Fixed versions / mitigation stateReported fixed builds: Office 2019 16.0.10417.20095 and Office 2016 16.0.5539.1001. Temporary mitigation guidance centers on setting the COM compatibility kill-bit for Shell.Explorer.1 / {EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}.
Exposure populationThis is not meaningfully internet-scannable. Shodan/Censys/FOFA are poor prioritization tools here because the vulnerable surface is a desktop Office client path, not an exposed server daemon.
Disclosure date2026-01-26 via Microsoft/NVD/CVE publication.
Who reported / analyzed itCNA is Microsoft. Campaign analysis cited by public reporting references Zscaler ThreatLabz, CERT-UA, and later Trellix for exploitation details.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (8.2/10)

The single biggest amplifier is confirmed exploitation with KEV listing on a product family that sits on nearly every enterprise endpoint. The single biggest brake is that this remains a user-execution, client-side chain rather than an unauthenticated network service compromise.

HIGH KEV status and active exploitation significance
HIGH Attack-path friction from user interaction and endpoint-only blast radius
MEDIUM Exact exploit mechanics across all affected Office channels

Why this verdict

  • KEV overrides complacency: once CISA KEV and observed campaigns are on the board, this is no longer a theoretical Office oddity.
  • User execution is real downward pressure: the attacker still needs a victim to open a crafted document, which implies successful delivery, social engineering, and a workstation target rather than direct edge reach.
  • Client-side blast radius keeps it out of CRITICAL: exploitation usually lands on one user context at a time, and modern EDR/email controls can still break multiple links in the chain.
  • Office ubiquity keeps the floor high: even with friction, the reachable population inside a large enterprise is massive because Office is everywhere.

Why not higher?

This is not an unauthenticated remote service bug and not an internet-edge mass-exploitation story. The chain depends on delivery plus user interaction, and the initial blast radius is an endpoint session, not an enterprise control plane.

Why not lower?

Dropping this to MEDIUM would ignore the two facts that matter most to defenders: KEV listing and documented real-world abuse. A phish-to-workstation bug in Office is still high operational risk when it is already being weaponized against real targets.

05 · Compensating Control

What to do — in priority order.

  1. Apply the COM kill-bit now — If you still run Office 2016 or 2019, push the registry-based COM compatibility mitigation for Shell.Explorer.1 immediately as a temporary shield. Because this CVE is KEV-listed, deploy it within hours, not on a normal change cadence.
  2. Force Office restarts on serviced channels — For Microsoft 365 Apps / Office 2021+ environments reportedly covered by a service-side fix, enforce application restart so the protection actually takes effect. Treat this as an immediate, within-hours action for high-risk user groups.
  3. Tighten Office document ingress — Quarantine or detonate inbound legacy Office formats, embedded-object documents, and externally sourced RTF/DOC payloads in mail and collaboration channels. For this KEV item, move those policy changes within hours where business impact allows.
  4. Watch Office child-process and COM abuse — Raise detections for Office spawning unusual helpers, WebDAV fetches, LNK/DLL staging, COM hijack registry writes, verclsid abuse, and beaconing from freshly opened documents. Stand up or tune those detections within hours for exposed populations.
What doesn't work
  • Perimeter vulnerability scanning does not solve this; the vulnerable surface is an endpoint Office client path, so your internet scanner will mostly tell you nothing useful.
  • MFA does not block exploitation of the document itself; it may help later account abuse, but it does not stop the Office trust-bypass chain.
  • Macro blocking alone is insufficient because reported exploitation chains did not rely on the old 'enable macros' failure mode.
06 · Verification

Crowdsourced verification payload.

Run this on the target Windows endpoint or through your management tooling as Administrator for full registry visibility. Example: powershell.exe -ExecutionPolicy Bypass -File .\Test-CVE-2026-21509.ps1; it checks installed Office 2016/2019 builds and whether the Shell.Explorer.1 kill-bit mitigation is present. Exit code 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# Test-CVE-2026-21509.ps1

# Checks Microsoft Office exposure for CVE-2026-21509

# Output: VULNERABLE / PATCHED / UNKNOWN

# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN


[CmdletBinding()]
param()

$ErrorActionPreference = 'SilentlyContinue'

function Parse-Version($s) {
    try { return [version]$s } catch { return $null }
}

function Get-FileVersion($path) {
    if (Test-Path $path) {
        try { return [version](Get-Item $path).VersionInfo.FileVersion } catch { return $null }
    }
    return $null
}

function Test-KillBit {
    $paths = @(
        'HKLM:\SOFTWARE\Microsoft\Office\Common\COM Compatibility\{EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}',
        'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Office\Common\COM Compatibility\{EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}'
    )
    foreach ($p in $paths) {
        $v = Get-ItemProperty -Path $p -Name 'Compatibility Flags'
        if ($null -ne $v) {
            $flags = [int64]$v.'Compatibility Flags'
            if (($flags -band 0x400) -eq 0x400) { return $true }
        }
    }
    return $false
}

$fixed2016 = [version]'16.0.5539.1001'
$fixed2019 = [version]'16.0.10417.20095'
$killBit = Test-KillBit

$findings = @()
$unknowns = @()
$servicedProtected = $false

# Click-to-Run detection

$c2r = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration'
if ($c2r) {
    $productIds = @()
    if ($c2r.ProductReleaseIds) { $productIds = ($c2r.ProductReleaseIds -split ',') }
    $platform = $c2r.Platform
    $ver = Parse-Version $c2r.VersionToReport

    $is2016 = ($productIds | Where-Object { $_ -match '2016' }).Count -gt 0
    $is2019 = ($productIds | Where-Object { $_ -match '2019' }).Count -gt 0
    $isServiced = ($productIds | Where-Object { $_ -match 'O365|2021|2024|LTSC2021|LTSC2024' }).Count -gt 0

    if ($isServiced) { $servicedProtected = $true }

    if ($is2016 -and $ver) {
        $findings += [pscustomobject]@{ Product='Office 2016 C2R'; Version=$ver; Vulnerable=($ver -lt $fixed2016) }
    }
    if ($is2019 -and $ver) {
        $findings += [pscustomobject]@{ Product='Office 2019 C2R'; Version=$ver; Vulnerable=($ver -lt $fixed2019) }
    }
    if (-not $is2016 -and -not $is2019 -and -not $isServiced) {
        $unknowns += 'Click-to-Run Office detected but release channel could not be mapped confidently.'
    }
}

# Uninstall inventory fallback

$uninstallRoots = @(
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
    'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
$apps = foreach ($root in $uninstallRoots) {
    Get-ItemProperty $root | Where-Object { $_.DisplayName -match 'Microsoft Office' }
}

foreach ($app in $apps) {
    $name = [string]$app.DisplayName
    $dispVer = Parse-Version $app.DisplayVersion
    if ($name -match '2016' -and $dispVer) {
        $findings += [pscustomobject]@{ Product=$name; Version=$dispVer; Vulnerable=($dispVer -lt $fixed2016) }
    } elseif ($name -match '2019' -and $dispVer) {
        $findings += [pscustomobject]@{ Product=$name; Version=$dispVer; Vulnerable=($dispVer -lt $fixed2019) }
    } elseif ($name -match '2021|2024|Microsoft 365|365 Apps') {
        $servicedProtected = $true
    }
}

# InstallRoot fallback using WinWord version

$installRoots = @(
    'HKLM:\SOFTWARE\Microsoft\Office\16.0\Word\InstallRoot',
    'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Office\16.0\Word\InstallRoot'
)
foreach ($ir in $installRoots) {
    $root = (Get-ItemProperty $ir).Path
    if ($root) {
        $exe = Join-Path $root 'WINWORD.EXE'
        $fv = Get-FileVersion $exe
        if ($fv) {
            if (($fv.Build -ge 10417) -or ($fv.Build -ge 5539 -and $fv.Build -lt 10417)) {
                $unknowns += "Found WINWORD.EXE $fv at $exe, but edition mapping (2016 vs 2019) is ambiguous without better inventory."
            }
        }
    }
}

# Deduplicate findings

$findings = $findings | Sort-Object Product, Version -Unique

if ($findings.Count -gt 0) {
    $vuln = $findings | Where-Object { $_.Vulnerable -eq $true }
    if ($vuln.Count -gt 0) {
        if ($killBit) {
            Write-Output 'VULNERABLE'
            Write-Output 'Reason: Vulnerable Office 2016/2019 build detected, but temporary COM kill-bit mitigation is present.'
            $vuln | ForEach-Object { Write-Output ("Detected: {0} {1}" -f $_.Product, $_.Version) }
            exit 1
        } else {
            Write-Output 'VULNERABLE'
            Write-Output 'Reason: Vulnerable Office 2016/2019 build detected and COM kill-bit mitigation is absent.'
            $vuln | ForEach-Object { Write-Output ("Detected: {0} {1}" -f $_.Product, $_.Version) }
            exit 1
        }
    } else {
        Write-Output 'PATCHED'
        $findings | ForEach-Object { Write-Output ("Detected: {0} {1}" -f $_.Product, $_.Version) }
        if ($killBit) { Write-Output 'Note: COM kill-bit mitigation also present.' }
        exit 0
    }
}

if ($servicedProtected -and -not $findings.Count) {
    Write-Output 'PATCHED'
    Write-Output 'Reason: Only Microsoft 365 Apps / Office 2021+ style inventory was detected; vendor reporting indicates service-side protection after Office restart.'
    if ($killBit) { Write-Output 'Note: COM kill-bit mitigation also present.' }
    exit 0
}

if ($unknowns.Count -gt 0) {
    Write-Output 'UNKNOWN'
    $unknowns | ForEach-Object { Write-Output $_ }
    exit 2
}

Write-Output 'UNKNOWN'
Write-Output 'Reason: No conclusive Office 2016/2019 inventory found, or product mapping could not be determined.'
exit 2
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat this as an endpoint exploitation campaign problem, not a perimeter scanning project: identify every Office 2016/2019 host, push the temporary COM mitigation or patch immediately, within hours because the CVE is KEV-listed, and force Office restarts on Microsoft 365 / Office 2021+ populations the same day. For timing, the normal noisgate mitigation SLA for HIGH would be ≤30 days, but KEV overrides that to patch / mitigate immediately, within hours; the noisgate remediation SLA remains ≤180 days, though any mature team should front-load completion for exposed user groups in the current sprint, not hide behind the long tail.

Sources

  1. Microsoft Security Update Guide - CVE-2026-21509
  2. NVD - CVE-2026-21509
  3. CVE.org record - CVE-2026-21509
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS API documentation
  6. The Hacker News - APT28 Uses Microsoft Office CVE-2026-21509
  7. TechRadar - emergency patch / affected builds summary
  8. Vicarius detection script and mitigation notes
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.