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.
Meta’s louisiana data center to exceed 250 billion price tag
Ransomware Crisis in 2026: 5,064 Organizations Affected in 135 Countries
Palo Alto Networks Addresses 13 Vulnerabilities
Critical Dell BIOS & Zimbra Flaws Expose Enterprise Systems
CoLoCity Launches New 1.0 MW Data Center Facility at Gulshan
Daily Cyber security update for 10. 07. 2026
How Hacker Compromise AWS Cloud Environment Using AI in 72 Hours
Mycelium Framework: First AI-as-a-Service Botnet
CrowdStrike Shows 5 New Prompt Injection Techniques for AI Agents
Critical GCP Dialogflow Vulnerability Allows Malicious Code Injection
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.
