Numeric truncation error in Microsoft Office Excel

CVE-2026-68804 is a heap-based buffer overflow triggered by a numeric truncation error in Microsoft Excel's file-parsing logic. An attacker crafts a malicious .xlsx (or similar) file; when a user opens it, an integer value is silently truncated during a size calculation, leading to an undersized heap allocation and subsequent out-of-bounds write. This yields code execution in the context of the logged-in user. Every supported Office edition is affected — Microsoft 365 Current Channel through Office 2019 Volume Licensed (build 1808) — making the *reachable population* enormous. The Preview Pane is not a viable attack vector, so the victim must actively double-click or otherwise open the file.

Microsoft labels this Important/HIGH at CVSS 7.8, but the score overstates the real-world risk for a well-defended enterprise. The vector is AV:L/AC:L/PR:N/UI:R/S:U — *local, user-interaction required*. In practice, any file arriving via email or web download carries the Mark of the Web (MOTW) flag, which forces Protected View — a read-only sandbox that blocks macros, ActiveX, and most exploit payloads. An attacker must convince the user to click Enable Editing *after* Protected View warns them. Layer on top of that: modern email gateways detonate Office attachments in sandboxes, EDR agents flag anomalous child processes spawned from EXCEL.EXE, and Application Guard (where deployed) provides hardware isolation. With no public PoC, no KEV listing, no in-the-wild exploitation, and an EPSS of only 0.36%, the realistic urgency is materially lower than the vendor label implies.

Why this verdict

• Protected View + MOTW gate: The exploit cannot fire until the user explicitly clicks Enable Editing on an internet-sourced file. This is a default-on defense in all supported Office versions that breaks the chain for the majority of delivery scenarios.
• No PoC, no wild exploitation, low EPSS: With a 0.36% EPSS and zero known exploitation, the threat is entirely theoretical. Exploit development for modern heap-based overflows in Office on Windows 10/11 with ASLR+CFG is non-trivial.
• Email gateway and EDR layered defense: Enterprise email sandboxes detonate Office attachments before delivery; EDR and ASR rules block anomalous child processes from Excel. Each layer independently reduces the probability of successful exploitation.
• Role multiplier: Excel is predominantly a *workstation application* running in standard user context. (a) Low-value role: dev sandbox — chain succeeds, blast radius limited to user session. (b) Typical role: corporate workstation — chain succeeds if user bypasses Protected View, blast radius is one user's data and session token. (c) High-value role: Excel on a finance server or terminal server with privileged data — plausible but these represent <5% of installs, and code execution is still user-context, not SYSTEM or domain-admin. No path to domain takeover, fleet compromise, or supply-chain pivot from this bug alone. No floor override triggered.

Why not higher?

Upgrading to HIGH would require either active exploitation, a public PoC lowering the skill bar, or a blast radius beyond a single user session. None of these conditions are met. The bug runs in user context on a workstation — there is no privilege escalation, no lateral movement primitive, and no domain-controller or identity-provider role in the blast radius.

Why not lower?

Downgrading to LOW would undercount the sheer installed base of Microsoft Excel across every enterprise and the reality that social engineering *does* succeed — users click Enable Editing regularly. The underlying primitive (heap overflow → RCE) is high-impact when it lands, and a motivated attacker with resources could develop a working exploit. The CVSS temporal score of 6.8 anchors the floor above LOW.

1. Enable Attack Surface Reduction (ASR) rules for Office — Deploy the ASR rules Block Office applications from creating child processes (D4F940AB-401B-4EFC-AADC-AD5F3C50688A) and Block Office applications from injecting code into other processes (75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84) via Intune or Group Policy. These block the most common post-exploitation actions even if the heap overflow succeeds. No mitigation SLA applies at MEDIUM — go straight to the 365-day remediation window, but these ASR rules should be your standing baseline.
2. Enforce Protected View and Application Guard — Verify via Group Policy or Intune that Protected View is enabled for files originating from the internet, Outlook attachments, and unsafe locations. For M365 E5 tenants, enable Application Guard for Office to provide hardware-isolated containers. These are default-on but can be disabled by users or admins — audit the settings.
3. Harden email gateway sandbox policies — Ensure your email gateway (Defender for Office 365, Proofpoint, Mimecast) is configured to detonate .xlsx, .xlsb, .xlsm, and .xls attachments in a sandbox before delivery. Block or quarantine files that trigger sandbox verdicts.
4. Deploy Snort/Suricata IDS signatures — If you run network IDS, deploy Talos Snort 2 rules 1:66902–1:66948 and Snort 3 rules 1:301589–1:301607 to detect known exploitation patterns for this CVE family.

Run on each Windows host where Office is installed. Requires no admin privileges. Example: powershell -ExecutionPolicy Bypass -File .\Check-CVE-2026-68804.ps1

# Check-CVE-2026-68804.ps1
# Checks whether the installed Office build includes the fix for CVE-2026-68804
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

$ErrorActionPreference = 'Stop'

# Patched build numbers per channel (major.minor)
$patchedBuilds = @{
    '20228' = 20190   # Current Channel / MEC / Retail 2607
    '20131' = 20206   # MEC 2606
    '20026' = 20266   # MEC 2605
    '19127' = 20730   # Semi-Annual Enterprise 2508
    '17932' = 20910   # LTSC 2024
    '14334' = 20848   # LTSC 2021
    '10417' = 20197   # Office 2019
}

try {
    $excelPath = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\excel.exe' -ErrorAction SilentlyContinue).'(Default)'
    if (-not $excelPath -or -not (Test-Path $excelPath)) {
        $excelPath = Get-ChildItem "$env:ProgramFiles\Microsoft Office" -Recurse -Filter 'EXCEL.EXE' -ErrorAction SilentlyContinue | Select-Object -First 1 -ExpandProperty FullName
    }
    if (-not $excelPath -or -not (Test-Path $excelPath)) {
        $excelPath = Get-ChildItem "${env:ProgramFiles(x86)}\Microsoft Office" -Recurse -Filter 'EXCEL.EXE' -ErrorAction SilentlyContinue | Select-Object -First 1 -ExpandProperty FullName
    }
    if (-not $excelPath) {
        Write-Output 'UNKNOWN - Excel not found on this system.'
        exit 2
    }

    $version = (Get-Item $excelPath).VersionInfo.ProductVersion
    Write-Output "Detected Excel at: $excelPath"
    Write-Output "Product version:   $version"

    # Parse build number (e.g. 16.0.20228.20190)
    $parts = $version -split '\.'
    if ($parts.Count -lt 4) {
        Write-Output 'UNKNOWN - Could not parse version string.'
        exit 2
    }
    $buildMajor = $parts[2]
    $buildMinor = [int]$parts[3]

    if ($patchedBuilds.ContainsKey($buildMajor)) {
        $requiredMinor = $patchedBuilds[$buildMajor]
        if ($buildMinor -ge $requiredMinor) {
            Write-Output "PATCHED - Build $buildMajor.$buildMinor meets or exceeds fix build $buildMajor.$requiredMinor."
            exit 0
        } else {
            Write-Output "VULNERABLE - Build $buildMajor.$buildMinor is below fix build $buildMajor.$requiredMinor."
            exit 1
        }
    } else {
        # Unknown channel — compare against lowest known patched build
        Write-Output "UNKNOWN - Build major $buildMajor not in known patched list. Manual verification required."
        exit 2
    }
} catch {
    Write-Output "UNKNOWN - Error: $_"
    exit 2
}

Sources

1. Microsoft MSRC Advisory
2. Talos Intelligence – August 2026 Patch Tuesday
3. CrowdStrike – August 2026 Patch Tuesday Analysis
4. SANS ISC – Microsoft Patch Tuesday August 2026
5. Microsoft Office Security Update Release Notes
6. The Hacker News – Microsoft August 2026 Patches