Microsoft says its out of band updates remove six eMudhra roots from Windows, but only the Update Catalog offers them

Nine days to the update, and the update is not on Windows Update

Microsoft's out of band root removal came nine days after the first report (derived), and the file that carries it is not on Windows Update. The reporter's timeline in Mozilla's bug 2083449 records the report emailed to Apple, Chrome, Microsoft, Mozilla and eMudhra at 18:05 UTC on Saturday 17 October 2026, and Chrome's statement gives the same minute. Microsoft's MSRC post and eight KB pages are dated Monday 26 October. On all eight pages the Windows Update tab, the Business tab and the Windows Server Update Services tab read "Not available", and only the Microsoft Update Catalog tab reads "Available" (read 27 October 2026, 21:31 to 21:51 GMT).

That does not show that connected PCs are unprotected. Microsoft's pages say the update is "intended for devices that do not receive current certificate trust list (CTL) updates", and separately that it updated the Windows Disallowed Certificate Trust List on 20 October, three days after the report (derived). It does not show which certificates were removed either. The MSRC post counts seven, "six eMudhra G3 roots and an AAA Certificate Services cross sign", and names none of them. It gives no serial number or thumbprint, and no page read for this briefing does.

Method: every figure is read from a Microsoft, Mozilla, Apple, Chrome or eMudhra page unless it is marked derived (arithmetic on their dates) or inference (this briefing's reading). BleepingComputer's report of 27 October is the pointer to Microsoft's post and agrees with it, but it names two of the eight KB articles. Microsoft ships Windows and runs the Windows root program, so it has an interest in being seen to act. eMudhra is listed on the NSE and BSE and says its global TLS business is around 1 percent of its revenue. The weak keys themselves are covered in brief 397 and are not repeated here; this briefing is about the distrust action and follows the primary pages.

What Microsoft states, and what it leaves out

Microsoft makes three separate moves, and its post is careful to keep them apart. The first is a block on the eight compromised intermediate CAs in the Disallowed list. The second is removal of seven roots from the Windows trust list. The third is a Microsoft Edge CRLSet delivered as a component update, which blocks the affected TLS certificates without a browser update. Microsoft says plainly that the second is the larger decision: "Removing a root from a trust list is not the same as revoking the known impacted intermediate certificate authorities." It calls it "a separate trust decision, broader than blocking the identified compromised intermediate keys."

The post also says it "was not a compromise of Microsoft systems" and that the issue arose in eMudhra's hierarchy, and promises to update itself "if additional findings or trust changes materially affect customers". This briefing compared the post at 21:42 GMT and again at the end of the reading session on 27 October 2026 and found no change. The Windows message center carries a pointer to it dated 26 October at 19:00 Pacific, which is 02:00 GMT on 27 October (derived).

Eight updates, none of them on Windows Update

The MSRC post gives no KB number. The numbers come from the update pages themselves: KB5134133, KB5134125, KB5134130, KB5134134, KB5134124, KB5134123, KB5134140 and KB5134137. BleepingComputer names KB5134133 and KB5134125. The other six were found by reading the update history lists on those pages and Microsoft's Windows Server release health page. Eight is a count of the pages read (derived); Microsoft's pages do not say it is the full set.

Each page carries the same "Who should install this update" paragraph: the update is "intended for devices that do not receive current certificate trust list (CTL) updates, including updates to the list of untrusted certificates", with examples of "devices in disconnected environments, devices that cannot access Microsoft's certificate-update service and devices where automatic CTL updates are disabled". Each carries a [Certificates] line that describes "an updated trusted root certificate payload". None lists the certificates. The KB page for Windows 10 adds a changelog entry dated 26 October that links to the MSRC post.

Zoom

The practical reading is that the people the update is for are the people who have to fetch it by hand. A disconnected server, a golden image or a machine with automatic CTL updates switched off does not get this from Windows Update, Windows Update for Business or WSUS, on Microsoft's pages. Whether an administrator can import the Catalog package into WSUS is not stated on the pages read. KB5134133 also says the package is cumulative, so it brings the 13 October update with it, and its known issues list includes Smart App Control and Remote Desktop faults inherited from earlier updates. It warns that hotpatch devices that install it "will not receive hotpatch updates until after they install the January 2027 baseline update". The Windows 10 and Server 2016 pages also carry prerequisites, for example an update released on or after 8 July 2025 for KB5134125.

Zoom

Two of the eight are for versions at the end of support. The KB5134123 page says support for Windows 10 Enterprise LTSB 2016 ended on 13 October 2026 and that Windows Server 2016 support "ends soon"; the KB5134125 page says free support for Windows 10 Enterprise LTSC 2021 ends on 12 January 2027. Brief 283 covers what those dates mean for a separate Windows Update certificate rotation in 2027; this change is not that one.

Six roots in Microsoft's post, three in the tracker's list

Microsoft counts six eMudhra G3 roots. The tracker's roots.json lists three eMudhra roots in the affected chains, plus the Sectigo root. The tracker's list is about what the eight keys chain to; Microsoft's is about what it chose to remove, and it calls that decision broader than blocking the compromised keys. How the six map to any published list is not established, and the pages read do not say. A commenter in Mozilla's bug lists four non TLS eMudhra roots in the Common CA Database (emSign Root CS CA - G2 and G3, and emSign Root SMIME CA - G1 and G3), so the six may include roots with no TLS role at all (inference). The Microsoft Trusted Root Program's machine readable list is in the CCADB, whose robots.txt disallows automated access, so it was not read.

Zoom

Code signing is where Windows differs. Mozilla's bug record says of the two code signing CAs that they are "trusted by Microsoft", and Apple's support page says its frameworks do not trust code signing certificates, while Chrome says its verifier does not build a TLS path through a code signing constrained intermediate. Microsoft is the one program for which all eight keys mattered (inference from those three statements), and the Windows Authenticode trust decision is the one the MSRC post does not separately describe.

The TLS side has a number a defender can use. Chrome's root program counted from Certificate Transparency, as of 21 October, about 30,800 unexpired precertificates chaining to emSign ECC Root CA - G3, 30,791 of them (23,806 plus 6,985, derived) issued by two Internet2 and InCommon subordinate CAs and 18 by eMudhra's own intermediates. eMudhra's status page says the impact is "contained to a single customer ecosystem in the United States". Whether those are the same population is not stated (inference: they may be). Whether Windows trusts those InCommon issued certificates through one of the seven removed certificates is not established either.

What the other root programs did, and when

Zoom

Microsoft's root removal followed Mozilla's NSS removal of the same upstream root by six days and Apple's block of the ECC root by three (derived). That is not a criticism the record supports on its own: the programs removed different things. Mozilla and Apple removed or blocked the ECC root that signs the TLS root, while Microsoft says it removed six eMudhra G3 roots and a cross sign. The reporter's summary in the bug, written on 18 October, lists "No response from Microsoft" beside the Sectigo cross signs that were then still unrevoked. That is the reporter's note at that moment, and Microsoft's 20 October update followed it. The bug page read contains no later Microsoft statement.

eMudhra's own account differs from the bug in places. Its status page says it was made aware on "October 17, 2026 (late evening, India time)" and that the intermediates were revoked the following day; a participant in the bug asked it to reconcile this with the 18:05 UTC report. eMudhra's 26 October statement says "The flaw was ours" and that it will publish a root cause analysis through the CCADB. Mozilla says its questions to eMudhra, sent on 20 October at 20:31 UTC, were unanswered on 23 October (comment 42), and when eMudhra cited social media scrutiny as a reason for delay, Chrome's root program replied that the scrutiny was "the predictable result of eMudhra's own failure" (comment 41). eMudhra answered that it was within the CCADB's 14 day window for a full report (comment 43) and later that it had answered Mozilla's questions in direct correspondence (comment 51).

What the record does not establish

The strongest sentence on abuse in the primary pages is a negative. eMudhra says the weak keys had not issued a public end entity certificate and that it is "not aware of any evidence that the weak keys were recovered or exploited by anyone before the issue was disclosed". That is eMudhra's statement about eMudhra's own issuance. A certificate signed with a recovered key is not issued by eMudhra at all, which is why a participant in Mozilla's bug could report certificates after the revocation. The comment says all but two carry no revocation pointer, so a client that checks revocation only for the end entity certificate finds nothing to check. The record neither proves nor rules out use against a real victim.

Three labels that are not controls

"Out of band". The label suggests a push to every machine. On Microsoft's own pages it is a package a person has to download from the Catalog, and it is not offered on Windows Update, Windows Update for Business or WSUS. It is a control for the estate that has someone who watches the Catalog.

"Automatic". The MSRC post says to keep automatic certificate trust updates flowing, and Microsoft Learn says Windows downloads the trusted and untrusted lists daily from the Windows Update site. That is a control only on a machine that can reach it. The KB pages name the three cases where it does not: disconnected, blocked, or switched off by the DisableRootAutoUpdate or EnableDisallowedCertAutoUpdate settings that Microsoft Learn documents. A hardened server behind a proxy that blocks the update domain is in the second case without anyone having decided it.

"Revoked". eMudhra's argument in the bug is that it revoked the eight within 14 hours and that a relying party that checks revocation "has not been exposed since the revocation". Mozilla's position in the same bug, stated earlier, is that many endpoints have no effective way to get revocation information, and each program went on to add its own block or removal. Microsoft's sentence separates three things a reader can conflate: revoking an intermediate, blocking it in a Disallowed list, and removing a root from a trust list. Each reaches a different set of clients.

Technical details

Microsoft's MSRC post and the eight KB pages print no thumbprint, serial number, registry value or script for the removal itself. What Microsoft does publish, on its Learn pages, is how the trust and disallowed lists are fetched, where they are stored and how to check their age. Those are the artifacts below, followed by the KB5134133 install commands, the certificate hashes that other parties printed, and the checks the incident tracker publishes. Each block names the page it was copied from; nothing is retyped from memory.

Where the lists come from. Windows downloads two cabinet files daily, one for trusted roots and one for the Disallowed list, and keeps them in the registry. A defender uses this to see whether a machine can reach the service, and to know that the 20 October Disallowed update and any trust list removal travel this way for connected devices (inference for the removal; MSRC does not say).

http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab
http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate\EncodedCtl
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate\DisallowedCertEncodedCtl

The settings that switch it off. These are the policies that make a machine one that "does not receive current CTL updates", the group the KB pages are for. Search group policy and registry exports for them. Microsoft's own page warns that settings made through a policy object stay in the registry after the object is unlinked.

Key: HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot\DisableRootAutoUpdate
Type: REG_DWORD
Name: DisableRootAutoUpdate
Data: 0 to enabled or 1 to disable.
Default: There's no key present by default. Without a key present, the default is enabled.
Key: SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot
Type: REG_DWORD
Name: EnableDisallowedCertAutoUpdate
Data: 1 to enabled or 0 to disable.
Default: There's no key present by default. Without a key present, the default is enabled.
Key: HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate\RootDirUrl
Type: REG_SZ
Name: RootDirUrl
Data: Enter a valid HTTP or file URI.

Checking a machine. The first two commands print the last synchronisation time of each list; a date older than a few days on a machine that should be connected means the updater is not working. The last command copies the lists to a share, which is how Microsoft describes feeding a disconnected network. Whether the lists fetched this way also carry the 26 October removal is not stated; the KB package is the route Microsoft names for those devices.

certutil -verifyctl AuthRoot | findstr /i "lastsynctime"
certutil -verifyctl Disallowed | findstr /i "lastsynctime"
certutil -verifyCTL AuthRoot
certutil -verifyCTL Disallowed
Certutil -syncWithWU \\<server>\<share>

Installing the KB. The KB5134133 page says to place all MSU files in one folder and to install the required checkpoint update first, or to let DISM scan the folder. The commands are as printed for x64.

windows11.0-kb5043080-x64_953449672073f8fb99badb4cc6d5d7849b9c83e8.msu
windows11.0-kb5134133-x64_0e59d2f988a5422dfb489e97faed3b3835fc7568.msu
DISM /Online /Add-Package /PackagePath:c:\packages\windows11.0-kb5134133-x64_0e59d2f988a5422dfb489e97faed3b3835fc7568.msu
Add-WindowsPackage -Online -PackagePath "c:\\packages\\windows11.0-kb5134133-x64_0e59d2f988a5422dfb489e97faed3b3835fc7568.msu"

The sixteen certificates. Eight CA certificates issued by two eMudhra roots and eight cross signs of the same keys by Sectigo's AAA Certificate Services. A hunt can search an inventory, a Certificate Transparency monitor or a trust store export for these SHA-256 hashes. They identify the compromised intermediates, which Microsoft says its Disallowed update already blocks. They are not the seven removed roots.

EM DV TLS CA - G3B | issued by AAA Certificate Services | SHA-256 45A883F349AEDFD5F3A649B5498FFB121712BA8B448F3F2A91DBC5A766FCDDBE
EM DV TLS CA - G3B | issued by emSign Root TLS CA - G3 | SHA-256 42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493
EM DV TLS CA - G3C | issued by AAA Certificate Services | SHA-256 62B7F9868263F72F6911FC78CEAF72C1979158B7368BF648683BB2AA39B02E72
EM DV TLS CA - G3C | issued by emSign Root TLS CA - G3 | SHA-256 0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19
EM EV TLS CA - G3B | issued by AAA Certificate Services | SHA-256 579480AEA166290BD3C643589E795FC0D0E54E86505D180F1DFF99EFD3199512
EM EV TLS CA - G3B | issued by emSign Root TLS CA - G3 | SHA-256 E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838
EM EV TLS CA - G3C | issued by AAA Certificate Services | SHA-256 FD9D5C2DBBD4995AB69B8D50C439D9527B00529199C2FD01B2174EB58F07021F
EM EV TLS CA - G3C | issued by emSign Root TLS CA - G3 | SHA-256 432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3
EM OV CS CA - G3B | issued by AAA Certificate Services | SHA-256 A496E23AC0CAB8155FC9B117B97EAE368EFCBB9041AEC8804D5A308D2D01C2D8
EM OV CS CA - G3B | issued by emSign Root CS CA - G3 | SHA-256 9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4
EM OV CS CA - G3C | issued by AAA Certificate Services | SHA-256 84112972B8E59D14560AE7E7119654474AAD119990CF3722BFC1E3B91615E1FD
EM OV CS CA - G3C | issued by emSign Root CS CA - G3 | SHA-256 4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1
EM OV TLS CA - G3B | issued by AAA Certificate Services | SHA-256 5F1DED4DD590AF74631290CF073B122A2AAC6A1FA479778A0BD43579BD832699
EM OV TLS CA - G3B | issued by emSign Root TLS CA - G3 | SHA-256 98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B
EM OV TLS CA - G3C | issued by AAA Certificate Services | SHA-256 7485B51C0ED192878FA1D2F948FB529AE1842CC5086C4B67F7BE5B2039DE9489
EM OV TLS CA - G3C | issued by emSign Root TLS CA - G3 | SHA-256 CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F

The roots. The four roots the tracker lists. Compare any root in your own stores against them; a match is a dependency to plan around, though it is not a claim about which ones Microsoft removed.

emSign Root TLS CA - G3 | SHA-256 7DD78D5F4F13459A83DFF9ABBBA62EDBAF6F2D102BF257FD712F4D9F2746ED8D | Microsoft: Included
emSign Root CS CA - G3 | SHA-256 F2EDAAFF3D9B701FB4D14C9F285F8C0BAD90FC3BCC1FA07D47F4718EDABA34A5 | Microsoft: Included
AAA Certificate Services | SHA-256 D7A7A0FB5D7E2731D771E9484EBCDEF71D5F0C3E0A2948782BC83EE0EA699EF4 | Microsoft: Included
emSign ECC Root CA - G3 | SHA-256 86A1ECBA089C4A8D3BBE2734C612BA341D813E043CF9E8A862CD5C57A36BBE6B | Microsoft: Included

A client check for non browser software. The tracker's test hosts serve certificate chains through the compromised intermediates. A TLS error is the safe result. The tracker also publishes a PowerShell script for local blocking and a note that applications with their own CA bundle need their own updates; this briefing did not read the script and prints none of it, and the tracker advises against it on managed devices.

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
curl https://dv-g3b-noct-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/

No proof of concept or key recovery code is reproduced here, and none is needed to act. The weakness, per Mozilla, is private keys that are integers below 256.

What to do, in order

The question this leaves

Microsoft tells you to find every certificate that chains to seven roots it has not named and to replace it before the change reaches your devices. Which of your certificates chain to them today, and how would you know before a user's connection fails?

Key facts