Microsoft Ships Emergency Fix for Windows Server Reboot Loops (KB5091157)

The most disruptive thing to hit enterprise Windows shops in April 2026 was not a zero-day or a ransomware crew. It was a Microsoft security patch. KB5082063, the April 14 Patch Tuesday update, walked an unknown number of domain controllers into an endless reboot loop — the single machine most of a corporate network trusts to say who is allowed to log in. Five days later Microsoft shipped an emergency out-of-band update to undo the damage. The reboot loop is fixable. The harder problem is what an incident like this does to the reflex every security team is told to build: patch fast, patch everything.

According to BleepingComputer and Tom's Hardware, the failure was narrow but brutal. After installing KB5082063 and rebooting, non-Global-Catalog domain controllers in environments that use Privileged Access Management (PAM) could hit a crash in the Local Security Authority Subsystem Service — LSASS, the process that enforces security policy and handles logons. The crash fired when the server processed an authentication request too early in the boot sequence.

Because Windows cannot run without a healthy LSASS, the operating system did the only safe thing it knows: it restarted. On reboot the DC hit the same faulty code path, crashed again, and restarted again. The protective mechanism became the outage. Microsoft's advisory listed Windows Server 2016, 2019, 2022, 23H2, and 2025 as affected — effectively every supported server build a large Active Directory estate is likely to run.

How a Security Update Became the Outage

The blast radius here is a function of what a domain controller is. It is not just another server; it is the authority that every workstation, application, and service checks against before granting access. When a DC drops out, the failure does not stay local — logons stall, group policy stops applying, and dependent services start timing out across the estate. An organization whose identity and access management rests on a small cluster of DCs can watch a routine maintenance window turn into a domain-wide outage, without an attacker anywhere in the picture.

It is worth being precise about scope, because the early panic overstated it. This was not "every server that installed the April patch." It was DCs meeting a specific profile: non-Global-Catalog role plus a PAM-style trust configuration. Plenty of estates never saw it. But PAM is exactly the kind of hardened, privileged-tier setup that security-mature organizations deploy — so the bug had a cruel bias toward the shops that had done the most to lock identity down.

A Fix You Have to Go Get Yourself

Microsoft's remediation arrived on April 19 as out-of-band updates: KB5091157 for Windows Server 2025 (OS build 26100.32698) and KB5091575 for Windows Server 2022, with parallel OOB releases tied to the April security updates for Server 2019 and 2016. Per the Microsoft support bulletin, these are cumulative updates that supersede the broken April release.

The catch is in the delivery. Out-of-band updates are not pushed automatically through Windows Update to everyone; administrators have to pull them manually from the Microsoft Update Catalog or stage them through WSUS. For an admin whose DC is already stuck in a reboot loop, that means recovering the box enough to apply a patch it cannot currently download on its own. Microsoft also told affected customers to contact Support for Business for case-by-case mitigation that can be applied even after the bad update is installed. A separate, unrelated April known issue — servers prompting for a 48-digit BitLocker recovery key after the update — piled onto the same week, which is why the two got tangled together in early reports.

My Read

Every defender lives with the same instruction: apply security patches quickly, because the window between disclosure and exploitation keeps shrinking. KB5082063 is the counter-argument that instruction never quite accounts for. When the patch itself is the thing that takes down authentication for the whole domain, "patch immediately" and "stay available" stop being aligned goals and start being a trade-off — and the people who followed best practice fastest were the ones who got burned first.

The real cost is not the day of downtime; it is the erosion of patch trust. Every incident like this hands ammunition to the part of every IT org that wants to wait, to "let someone else test it first," to sit on updates until they feel safe. That instinct is how estates end up months behind on patches an attacker is already exploiting. The answer is not to patch slower — it is to build a rollout process that can move fast without betting the whole domain on an untested update. Vendors ship regressions; a mature program assumes they will, and is structured so the first casualty is a canary, not the production directory.

What Defenders Should Do

The lesson from KB5082063 is process, not this specific KB. Concrete steps:

• Run a patch ring for domain controllers. Never apply a Patch Tuesday update to all DCs at once. Push to one non-critical controller first, let it run through a full boot and authentication cycle, and only then widen the ring — a staged rollout would have caught this before it hit the estate.
• Keep a canary in the exact risky configuration. This bug only bit non-GC DCs in PAM forests. A test DC that mirrors your real privileged-tier setup surfaces config-specific regressions that a generic lab never will.
• Rehearse DC recovery, not just DC patching. Know in advance how you would apply an out-of-band update to a controller stuck in a reboot loop, including boot-into-safe-mode and offline servicing paths. Recovery is a different muscle than deployment.
• Treat out-of-band updates as a manual workflow. OOB fixes do not arrive through normal channels. Have a documented path to pull from the Microsoft Update Catalog or WSUS quickly, so an emergency fix is not itself a scramble.
• Verify backups and rollback before patch day. Confirm you can restore or roll back a DC, and that BitLocker recovery keys are escrowed and retrievable — because the week you need them is the week everything else is already on fire.

Open Questions

Microsoft has not publicly quantified how many domain controllers were affected, and because the trigger required a specific non-GC-plus-PAM configuration, the true scope is hard to estimate from the outside. It is also not fully disclosed why the regression slipped through validation — how a change to LSASS boot-time authentication handling reached general availability without surfacing in a PAM test environment. Microsoft's public bulletins confirm the OOB fixes for Server 2025 and 2022; the exact KB identifiers for the Server 2019 and 2016 out-of-band releases were less consistently reported, so administrators on those builds should confirm the specific update against the Update Catalog before deploying.

Primary Documents

• Microsoft Support — April 19, 2026 KB5091157 (OS Build 26100.32698) Out-of-band
• BleepingComputer — Microsoft warns of reboot loops affecting some domain controllers
• Tom's Hardware — Microsoft's April patch puts Windows domain controllers into reboot loops
• The Register — Microsoft releases Windows Server update to fix April update