September closed the Update Stack and went quiet on File History

This morning we told Windows shops to finish CVE-2026-81963 before Tuesday. Those are the September cumulatives. Microsoft's other Monday note is about the same KBs: File History may stop creating copies after you install them. BleepingComputer carried the service alert today. The updater you need can go quiet on the backup you thought was still running. That is not a reason to skip the patch. It is a reason to look at the last backup date with your own eyes.

What File History is doing, and what it is not

File History is the Control Panel feature that copies Documents, Desktop, Pictures, and the rest of a profile to a USB disk or a NAS. It is not Windows Backup to OneDrive. A lot of shops never migrated. They still have a USB dock under a desk and a green "on" they have not checked since the last quiet Friday.

After the September security updates, some of those boxes cannot create or update backups. Event Viewer shows FileHistory.exe dying against KERNELBASE.dll. The UI lies in small ways: "Reconnect your drive" when the drive is fine, a Last Backup stamp that never moves, previous versions that say none are available. Affected builds, per the alert Susan Bradley spotted, include Windows 10 21H2 and later, LTSC 2016 and 2019, and Windows 11 23H2 and later. The originating KBs are the same list we named this morning for the Update Stack: KB5124012, KB5124008, KB5122880, and the Windows 10 cousins (KB5122878, KB5122876, KB5123099).

Microsoft has not published a File History repair in that note. Last week's out-of-band updates fixed some Remote Desktop, Hyper-V, and USB audio breakage from the same month and left other audio bugs outstanding. A separate domain-login failure has a workaround. File History does not, in the text we have. Do not uninstall the security update to get the copies back. That trades an exploited local-to-SYSTEM climb for a backup that was already a single USB disk.

Why a shop in Alberta should care

We keep saying recovery is a finding, not a checkbox. This is the checkbox failing because you did the right thing. A contractor laptop that still uses File History to a NAS, or a reception PC that dumps invoices to a USB drive, will look "patched" in WSUS and "backed up" in the user's head. The stamp on the drive is the evidence. If it stopped on the Tuesday you approved September, you have been running without new copies since then.

Acronis on a hosting panel last week, Netcore restore.cgi this morning, File History this afternoon: three different products, one question. Who can wipe the copies, and when did anyone prove a restore. A broken File History job is the gentle version. Ransomware is the rude one.

The rest of Monday, in one paragraph

Linux kernel KEV trio is due today. Update Stack is due tomorrow. Securonix described TASK#STOMP, a PowerShell backdoor that steals documents, Wi-Fi passwords, and the clipboard, and persists under scheduled-task names that sound like Windows (Local Credential Manager, Network Audio Service, Windows Display Manager, Device Credential Handler). Initial access is unclear. Treat a random .vbs on the desktop as a ticket. Blackpoint's ChainScript RAT is the ClickFix cousin, with C2 found via a Polygon contract and lures that look like Spotify, Zoom, or Teams. SolarWinds patched ARM CVE-2026-28326, an unauthenticated RCE from a hard-coded key, in 2026.2.1, with no reported use. thegentlemen's Air Canada listing is still a claim. None of those move the File History check.

What we would check before Tuesday

• Install the September cumulative that names CVE-2026-81963. Then open File History (or your real backup) and confirm a new copy landed after the reboot. The stamp is the evidence. The icon is not.
• If File History is the only copy, start a second one that is not that feature: a NAS job, a vendor backup, a dated restore you can name. Do not wait for Microsoft's repair to be the first copy.
• Do not roll back the KB to "fix" backups. Isolate the USB or NAS if you must, and copy what is already there before you experiment.
• Hunt the TASK#STOMP task names and a desktop .vbs you did not put there. Kernel reboot today if you have not. ISE is already late.

Bottom line

A security update that breaks File History is still a security update. Forensic Five reviews whether the copies actually landed, including the week you patched. From St. Albert, Alberta. Apply the Stack fix. Then look at the last backup date like someone may have stopped writing.