Microsoft KB5002907 Pulled After Deactivating Office 2016/2019 — Emergency Rollback and License Recovery Guide

Microsoft has paused the rollout of the KB5002907 Microsoft 365 update after widespread reports that it deactivated — and in some cases completely removed — perpetual Office 2016 and Office 2019 installations on endpoints that received it. For IT and security teams, this is not a vulnerability story; it is an operational integrity incident with real security implications. A workstation that silently loses its Office activation mid-quarter-close is a helpdesk fire. A workstation where Office binaries are partially removed is worse: users start self-remediating, downloading 'Office installers' from search results, and that is exactly the moment malvertising campaigns pushing fake Office installers (a perennial loader delivery vector) start converting.

If your patch management pipeline auto-approves Microsoft 365 updates, assume KB5002907 may already be staged or deployed somewhere in your estate. The priority actions are: (1) freeze the update in WSUS/Intune/ConfigMgr, (2) inventory which endpoints received it, (3) validate Office activation state fleet-wide, and (4) roll back and reactivate where required. This post gives you the audit queries, rollback script, and change-control detections to do that cleanly.

What Happened

According to reporting by BleepingComputer and corroborating user reports, Microsoft paused distribution of KB5002907 — a Microsoft 365 update — after customers found that applying it broke licensing on perpetual Office SKUs:

• Affected products: Perpetual-license Office 2016 and Office 2019 installations (volume and retail). Microsoft 365 Apps subscription licensing is not the reported failure mode — the impact lands on organizations still running perpetual suites, which is a substantial installed base in healthcare, legal, manufacturing, and government environments that deliberately avoid subscription licensing.
• Observed impact: Office applications reporting unlicensed/deactivated state, and in some cases the Office installation being removed entirely from the endpoint.
• Vendor response: Microsoft paused the rollout. As of publication, no revised update or formal remediation advisory with a fixed version number has been published — treat any KB5002907 payload currently cached in your deployment rings as suspect.

There is no CVE associated with this incident and it is not listed in CISA's Known Exploited Vulnerabilities catalog — this is a defective update, not an exploited vulnerability. The security relevance is operational: unmanaged user self-remediation, shadow-IT re-installation from untrusted sources, and the patch-management governance lesson that 'Microsoft-signed' does not equal 'safe to auto-deploy.'

Why Defenders Should Care About a 'Licensing Bug'

Three reasons this lands in the SOC's lane, not just the desktop team's:

1. User self-remediation is a malware delivery opportunity. Users with a broken Office will search for 'Office 2019 installer download.' Fake Office installer SEO poisoning and malvertising consistently rank among the most effective initial-access vectors for loaders and stealers. Expect a spike in risk while remediation is in flight.
2. Partial removal corrupts your software inventory. If Office binaries were removed on some endpoints, your vulnerability management tooling now has stale state — you cannot accurately assess Office CVE exposure on machines whose inventory says 'Office 2019 installed' but whose disk says otherwise. Re-baseline inventory after rollback.
3. Emergency rollback activity is anomalous by default. Mass wusa.exe /uninstall execution and licensing service manipulation are behaviors you should be alerting on anyway (attackers abuse both — KB removal to re-expose vulnerabilities, SPP tampering for license theft and defense evasion). This incident is a forcing function to build that visibility.

Detection & Response

The detections below serve two purposes: (a) auditing the blast radius of KB5002907 in your environment, and (b) flagging the emergency-remediation behaviors (update removal, licensing service manipulation) so they pass through change control rather than happening silently — whether performed by your own admins or by an intruder abusing the same tooling.

Sigma Rules

---
title: Windows Update Standalone Installer Uninstall Activity
description: Detects use of wusa.exe to uninstall Windows updates. Legitimate during emergency patch rollback (e.g., KB5002907 removal), but also abused by attackers to remove security updates and re-expose known vulnerabilities. All instances should be reconciled against change tickets.
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith: '\wusa.exe'
  selection_cli:
    CommandLine|contains:
      - '/uninstall'
      - '/kb:'
  condition: selection_img and selection_cli
falsepositives:
  - Approved emergency patch rollback activity (validate against change management records)
level: medium
---
title: Office Software Protection Platform Tampering or Reactivation via OSPP
description: Detects execution of the Office Software Protection Platform script (ospp.vbs), used to inspect and reactivate Office licenses. Expected during KB5002907 recovery by IT staff; unexpected execution by end users or from non-admin context may indicate license tampering or hands-on-keyboard activity.
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    CommandLine|contains:
      - 'ospp.vbs'
  condition: selection
falsepositives:
  - IT administrators performing license recovery or auditing during the KB5002907 incident
  - Volume licensing scripts in enterprise imaging/task sequences
level: low

KQL — Microsoft Sentinel / Defender

First, hunt for rollback activity and license-script execution across your managed fleet. Second, if you have the Azure Update Management / Log Analytics solution ingesting update compliance data, identify endpoints that actually installed KB5002907 — this is your remediation target list.

// Hunt 1: Detect KB uninstall and Office license recovery activity (Defender XDR)
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where FileName =~ "wusa.exe" and ProcessCommandLine has_all ("/uninstall", "/kb:")
    or ProcessCommandLine has "ospp.vbs"
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessAccountName
| order by TimeGenerated desc;

// Hunt 2: Endpoints that installed KB5002907 (requires Update Management / AMA update data in Log Analytics)
Update
| where TimeGenerated > ago(30d)
| where Title has "KB5002907" or KBID == "KB5002907"
| where UpdateState =~ "Installed"
| summarize arg_max(TimeGenerated, *) by Computer
| project Computer, Title, UpdateState, Approved, TimeGenerated
| order by Computer asc;

// Hunt 3: Sentinel variant using process events (Sysmon/SecurityEvent ingestion)
SecurityEvent
| where TimeGenerated > ago(14d)
| where Process in ("wusa.exe", "cscript.exe", "wscript.exe")
| where CommandLine has_all ("/uninstall", "/kb:") or CommandLine has "ospp.vbs"
| project TimeGenerated, Computer, Account, Process, CommandLine, ParentProcessName
| order by TimeGenerated desc;

Velociraptor VQL

Use this artifact to sweep endpoints for evidence that KB5002907 was installed (via the servicing registry hive) and to capture current process state for any wusa/ospp activity still in flight. Run it as a hunt across your Windows fleet to build the impact list without waiting for patch-management tooling to catch up.

-- KB5002907 impact sweep: servicing registry evidence + live rollback/licensing activity
SELECT * FROM foreach(
  row={
    SELECT Key.FullPath AS RegistryArtifact
    FROM glob(
      globs="HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Component Based Servicing/Packages/*KB5002907*",
      accessor="registry"
    )
  },
  query={
    SELECT RegistryArtifact, "KB5002907 servicing package present" AS Finding FROM scope()
  }
)

-- Correlated live activity: update uninstall or Office licensing scripts currently running
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE (Name =~ "wusa" AND CommandLine =~ "/uninstall")
   OR CommandLine =~ "ospp.vbs"

Remediation Script — Audit, Roll Back, Reactivate

Run this from your RMM or as an Intune remediation script with elevated context. It audits for KB5002907, removes it if present, reports Office licensing status via OSPP, and attempts reactivation for volume-licensed installs. Retail/MAK activations may require user interaction — log those for helpdesk follow-up rather than brute-forcing activation.

# KB5002907 emergency audit + rollback + Office license recovery
# Run elevated. Output is structured for RMM/Intune ingestion.

$kb = "KB5002907"
$report = [ordered]@{ Hostname = $env:COMPUTERNAME; KBPresent = $false; Removed = $false; LicenseState = "Unknown" }

# --- Step 1: Is the bad update installed?
$installed = Get-HotFix -Id $kb -ErrorAction SilentlyContinue
if ($installed) {
    $report.KBPresent = $true
    Write-Output "[!] $kb installed on $($env:COMPUTERNAME) (InstalledOn: $($installed.InstalledOn))"

    # --- Step 2: Uninstall it
    $proc = Start-Process -FilePath "wusa.exe" -ArgumentList "/uninstall /kb:5002907 /quiet /norestart" -Wait -PassThru
    if ($proc.ExitCode -in 0, 3010) {   # 3010 = success, reboot required
        $report.Removed = $true
        Write-Output "[+] Uninstall initiated (exit $($proc.ExitCode)); reboot required to complete."
    } else {
        Write-Output "[-] Uninstall returned exit code $($proc.ExitCode) — investigate manually."
    }
} else {
    Write-Output "[i] $kb not present."
}

# --- Step 3: Audit Office licensing state (covers Office 2016/2019, x86/x64 paths)
$ospp = @(
    "$env:ProgramFiles\Microsoft Office\Office16\OSPP.VBS",
    "${env:ProgramFiles(x86)}\Microsoft Office\Office16\OSPP.VBS"
) | Where-Object { Test-Path $_ } | Select-Object -First 1

if ($ospp) {
    $status = & cscript.exe //nologo $ospp /dstatus 2>&1 | Out-String
    if ($status -match "LICENSED") {
        $report.LicenseState = "Licensed"
        Write-Output "[+] Office reports LICENSED."
    } elseif ($status -match "NOTIFICATIONS|UNLICENSED|GRACE") {
        $report.LicenseState = "Deactivated"
        Write-Output "[!] Office deactivated — attempting reactivation (volume/KMS only)."
        & cscript.exe //nologo $ospp /act 2>&1 | Out-String | Write-Output
    } else {
        Write-Output "[?] Ambiguous license state — full ospp output below for review:`n$status"
    }
} else {
    Write-Output "[i] ospp.vbs not found — Office may have been REMOVED by the update. Flag for reinstall from licensed media."
    $report.LicenseState = "OfficeMissing"
}

$report.GetEnumerator() | ForEach-Object { Write-Output ("{0}={1}" -f $_.Key, $_.Value) }

Remediation Checklist

1. Freeze the update at the source. Decline KB5002907 in WSUS, create a decline/pause rule in ConfigMgr, or pull it from Intune update rings. Verify it is not cached in any pending deployment ring before assuming containment.
2. Build the impact list. Use the KQL hunt and VQL sweep above (or Get-HotFix via your RMM) to enumerate endpoints where the update installed. Do not rely on patch tooling dashboards alone — several reporting orgs found inventory lag of 24-48 hours.
3. Roll back and reactivate. Deploy the remediation script above. Reboot to complete the uninstall (wusa exit 3010). Volume-licensed endpoints should reactivate via /act; retail activations may need manual re-entry of keys — queue these for the helpdesk with a scripted runbook.
4. Reinstall Office where binaries were removed. Deploy from your licensed volume media or admin center installer — never let users source installers themselves. Consider temporarily blocking execution of Office-branded installers from user-writable paths via WDAC/AppLocker during the recovery window to shut down the malvertising lure.
5. Re-baseline software inventory. After rollback, force a full inventory resync so vulnerability management accurately reflects which endpoints still run Office 2016/2019 (both of which carry their own patching obligations — Office 2016 extended support ended in October 2025, so any remaining 2016 installs are now an unpatched attack surface and should be on your modernization list independent of this incident).
6. Institutionalize the lesson. Add a canary/pilot ring requirement for Microsoft 365 updates in your change policy. This incident is the second high-profile defective Microsoft update cycle in recent memory; ring-based deployment with a 3-7 day soak period on a representative pilot cohort would have contained this to tens of machines instead of thousands.
7. Reconcile change control. Every wusa /uninstall and ospp.vbs execution flagged by the detections above during the recovery window should map to a ticket. Anything that doesn't is an investigation, not noise.

Monitor the Microsoft 365 admin center and the original BleepingComputer report for Microsoft's revised update and formal guidance before re-approving any successor KB.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub