InfoSecBulletin Cybersecurity for mankind
Microsoft Defender sent out many false alerts after a wrong security update made it mark two real DigiCert root certificates as malicious. This could have stopped SSL/TLS checks and code-signing work in businesses everywhere.
A Defender antimalware signature update released around April 30, 2026, introduced a detection labeled Trojan:Win32/Cerdigent.A!dha, which incorrectly identified registry entries belonging to two of the internet’s most widely trusted root certificates, DigiCert Assured ID Root CA (thumbprint: 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43) and DigiCert Trusted Root G4 (thumbprint: DDFB16CD4931C973A2037D3FC83A4D7D775D05E4) — as high-severity malware threats.
Singapore Approves 200MW Data-Centre Expansion Under Second Call
Chameleon SEO Poisoning
Hackers poison Bing and Google search results to deliver phishing banking pages
Mysterious AI model “Ox Alpha” with free 100 trillion tokens a day for coders
After BDJobs, Directorate of Secondary and Higher Education 390k data surfaced online
Researchers show new technique to bypass AI safety guardrails in Grok and Gemini
About thousands of leaked AWS keys Held Full Admin Rights
US Bank investigates LockBit’s Data Breach Claims
Five new malware families actively targeting Asian Gov.t infra
T-Mobile Cuts Cables to Remove Chiness Salt Typhoon Hackers from Network
Splunk, Zyxel Patch Multiple Flaws Enabling RCE and Root Command Execution
The certificates are in the Windows trust store at HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates. This is where Windows keeps trusted root and intermediate certificate authorities.
Microsoft Defender automatically put the flagged certificate entries in quarantine on affected systems. This is part of its normal process to fix problems, removing them from the Windows trust store.
Microsoft Defender Warning
This caused a serious problem: without these root certificates, systems might not be able to check SSL/TLS connections for websites, and they could fail to verify legitimate software. This could lead to service disruptions, browser warnings, and application failures in corporate networks.
Organizations relying on DigiCert-signed software or HTTPS endpoints were especially exposed. Cybersecurity expert Florian Roth (@cyb3rops) was one of the first to bring attention to the problem. He shared it on X and asked others in the security field to look into it.
Roth shared a query to help administrators check if the DigiCert certificates were back on affected devices:
text| where ActionType == “RegistryKeyCreated”
| where Timestamp > datetime(2026-05-03T04:00:00)
| project Timestamp, DeviceName, ActionType, InitiatingProcessFileName
| order by Timestamp desc
He also recommended a quick command-line check for affected systems: certutil -store AuthRoot | findstr -i “digicert” .
Microsoft’s Q&A forums soon had many reports from admins saying it was a false alarm. Users pointed out that the DigiCert certificate hashes matched the ones on DigiCert’s website, proving nothing was really wrong.
Microsoft’s Response
Microsoft acknowledged the problem and quickly released updates to fix it. Version .430 was an important update that helped restore the quarantined certificates on affected computers.
Security watchers saw that the fix was happening automatically on managed devices, meaning Microsoft likely applied a quiet repair with the updated signature.
Administrators in places with strict update rules were told to manually check for certificates using certutil and to look at the Advanced Hunting logs in Microsoft Defender for Endpoint to make sure the restoration happened.
