Here’s the anticlimax up front: the “update” Microsoft pushed to the CVE-2026-68801 page changes exactly one thing — who gets credited for reporting the bug. The Security Update Guide flags it as an informational change only. No new patch, no revised severity, no expanded affected-products list. If your patch pipeline flagged this and paged someone at 2 a.m., you can go back to sleep.
So why write about it at all? Because the acknowledgement edit is a decent excuse to check whether you actually deployed the underlying fix — an Excel remote code execution vulnerability, which is not a class of bug you want lingering on endpoints. Metadata churn on MSRC pages is routine and boring. The RCE it points at is neither.
What the CVE actually is
CVE-2026-68801 is tracked by Microsoft as a remote code execution flaw in Microsoft Excel. Microsoft, as usual, doesn’t publish exploit internals in the advisory, and I’m not going to invent a mechanism I can’t confirm. But the shape of these bugs is extremely consistent across years of Patch Tuesdays, so here’s the honest read on the class rather than fabricated specifics:
- Excel RCEs are almost always memory-corruption bugs — use-after-free, type confusion, or heap overflow triggered while the parser chews through a malformed spreadsheet (XLS, XLSX, XLSB, or one of the legacy binary formats Excel still opens without complaint).
- The attack vector is opening a crafted file. That means phishing attachments, files pulled from a compromised share, or a link that lands a document in the Downloads folder. “Remote” here does not mean unauthenticated network worm — it means the code runs when the victim opens the thing.
- Execution happens in the context of the user running Excel. On a workstation where the user is a local admin — still depressingly common — that’s game over for the machine. On a properly least-privileged box, it’s a foothold, not a checkmate.
One detail worth confirming against the live advisory rather than assuming: check the “Access Vector” and whether the Preview Pane is listed as an attack vector. For some Office file-format bugs it is, which drops the required user interaction from “open the file” to “click it once in Explorer.” That materially changes your urgency. Read the actual CVE page’s exploitability assessment — “Exploitation More Likely” versus “Less Likely” is the number that should drive your timeline, not the CVSS score.
Who’s exposed
If Microsoft shipped this in a monthly rollup, the affected footprint is the usual Office spread: Microsoft 365 Apps (Click-to-Run), the perpetual-license Office 2016 / 2019 / 2021 / 2024 builds, and standalone Excel installs. I’m not going to quote a specific fixed build number here because I can’t verify the exact one for this CVE — pull it from the advisory’s “Security Updates” table, which lists the KB and the minimum patched version per channel.
The practical exposure map:
- Managed M365 Apps machines on Current or Monthly Enterprise Channel — likely already patched if your auto-update is healthy. Verify, don’t assume.
- Volume-license Office installs that rely on WSUS/SCCM/Intune — these lag, and this is where you’ll find the stragglers.
- Kiosks, shared terminals, and that one finance workstation nobody reboots — the classic long tail.
Audit what you’ve actually got deployed
Before you touch remediation, find out where you stand. This PowerShell reports the installed Click-to-Run version, Protected View posture, and the Attack Surface Reduction rules that blunt Office-spawned payloads. It’s read-only — nothing here changes state.
#requires -Version 5.1
# Excel / Office exposure audit - REPORT ONLY, makes no changes
$ErrorActionPreference = 'Stop'
function Get-OfficeC2RVersion {
$key = 'HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration'
try {
$c = Get-ItemProperty -Path $key -ErrorAction Stop
[PSCustomObject]@{
Product = 'Office Click-to-Run'
Version = $c.VersionToReport
Channel = $c.CDNBaseUrl
InstallType = 'C2R'
}
} catch {
Write-Warning "No Click-to-Run install found (MSI/volume license may be present instead)."
$null
}
}
function Get-ExcelProtectedView {
# Checks the current user's hive; run per-user for full coverage
$ver = @('16.0') # Office 2016+ all report 16.0
foreach ($v in $ver) {
$pv = "HKCU:\SOFTWARE\Microsoft\Office\$v\Excel\Security\ProtectedView"
try {
$p = Get-ItemProperty -Path $pv -ErrorAction Stop
[PSCustomObject]@{
DisableInternetFilesInPV = $p.DisableInternetFilesInPV
DisableUnsafeLocationsInPV = $p.DisableUnsafeLocationsInPV
DisableAttachmentsInPV = $p.DisableAttachmentsInPV
}
} catch {
Write-Warning "Protected View keys not set for $v (defaults apply = Protected View ON)."
}
}
}
function Get-RelevantASR {
try {
$pref = Get-MpPreference -ErrorAction Stop
# 'Block all Office applications from creating child processes'
$ruleId = 'D4F940AB-401B-4EFC-AADC-AD5F3C50688A'
$ids = $pref.AttackSurfaceReductionRules_Ids
$acts = $pref.AttackSurfaceReductionRules_Actions
if (-not $ids) { Write-Warning 'No ASR rules configured.'; return }
for ($i=0; $i -lt $ids.Count; $i++) {
if ($ids[$i] -eq $ruleId) {
$state = switch ($acts[$i]) {0{'Disabled'}1{'Block'}2{'Audit'}6{'Warn'}default{'Unknown'}}
[PSCustomObject]@{ Rule='Office child process'; State=$state }
}
}
} catch {
Write-Warning "Defender not available or Get-MpPreference failed: $($_.Exception.Message)"
}
}
Write-Host "== Office version ==" -ForegroundColor Cyan
Get-OfficeC2RVersion | Format-List
Write-Host "== Excel Protected View ==" -ForegroundColor Cyan
Get-ExcelProtectedView | Format-List
Write-Host "== Relevant ASR rule ==" -ForegroundColor Cyan
Get-RelevantASR | Format-Table -AutoSize
Compare the reported VersionToReport against the fixed build in the advisory. Anything lower is unpatched. For fleet-wide reporting, run the same logic through a Defender advanced hunting query against DeviceTvmSoftwareVulnerabilities — Microsoft’s own vuln management will list CVE-2026-68801 by device once the definition propagates.
Remediation, in priority order
- Deploy the update. For Click-to-Run, force it:
"C:\Program Files\Common Files\Microsoft Shared\ClickToRun\OfficeC2RClient.exe" /update user. For volume-license, push the KB via your management stack. This is the actual fix; everything below is compensating control. - Confirm Protected View is on for internet, unsafe-location, and attachment files. It’s the default, but it gets turned off by well-meaning users who got tired of the yellow bar. Protected View opens untrusted files in a sandbox, which defeats the “open and pop” path for most of these bugs.
- Enable the ASR rule that blocks Office apps from spawning child processes — Audit first, then Block once you’ve confirmed no legitimate macro workflow depends on it. This won’t stop in-process code execution, but it stops the common next stage (Excel launching PowerShell or cmd).
- Keep Mark-of-the-Web enforcement intact so files from email and browsers actually inherit the untrusted zone that triggers Protected View. If you strip MOTW somewhere in your file pipeline, you’re quietly disarming the sandbox.
None of these steps are irreversible, but flip the ASR rule to Block only after an audit window — going straight to Block on a finance team that lives in macro-heavy workbooks will generate the kind of helpdesk tickets that get security controls rolled back.
The honest verdict
Office file-format RCEs are not going away, and Excel is the perennial worst offender because it parses the most legacy binary formats and has the deepest, oldest C++ parsing code. Expect several more of these per year — that’s the baseline, not an anomaly. Microsoft has genuinely narrowed the blast radius over the last few years: Protected View, blocking macros from the internet by default, and MOTW propagation mean a single memory-corruption bug no longer translates cleanly into mass compromise the way it did a decade ago. The bugs keep coming; the exploitation ceiling has dropped. Both things are true.
As for this specific event — an acknowledgement update is exactly what it says on the tin, and treating it as a security event would be theater. The right move is unglamorous: use it as a prompt to confirm the real patch landed, because “informational change only” on a memory-corruption RCE still assumes you fixed the memory-corruption RCE.
Urgency: the acknowledgement change is zero-priority. The underlying patch is a next-patch-cycle-at-latest item for hardened, least-privileged fleets — but pull it forward to this week if the advisory rates exploitation “More Likely,” lists Preview Pane as a vector, or if you’ve got local-admin users opening attachments from outside. That combination is how a click-to-open bug becomes an incident.