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.
Citrix NetScaler SAML 0-Day Flaw Under Attack
Major Danish university breached, 200,000 users at risk
Microsoft’s X account hijacked to promote Clippy crypto scam
Critical cPanel, GitLab AI Gateway and Dell CSM Flaws Enable RCE And Admin Hijacking
Nearly 100,000 email addresses exposed in first AI-related data breach in Singapore
Hackers Exploit Zimbra Mail Servers: TeamViewer patched 5 critical flaws
Google Warns of Hackers Actively Exploiting Citrix 0-Day Flaws
CISA Warns Critical MikroTik RouterOS Flaw While Cisco SD-WAN Zero-Day Exploited in Attacks
Apple Zero-Day Exploited: Pentagon Data Breach Reportedly Exposes Sensitive Data of 3 Million People
JadePuffer Agentic AI targets and destroys Azure’s cloud resources
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.
