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.
Apple iOS 27.2 Released Fixes 163 Flaws, Including Critical WebKit RCE
CISA adds PHP2Shell to KEV, PHP Releases New Security Updates to Fix Critical HTTP2Shell flaw
Cloudflare Unveils Emergency WAF Ruleset Update on Brotli flaw
Daily Cyber security update for 26.10. 2026
The Washington Post report
Ex-DOGE AI startup Cathedral Breaches Anthropic Internal Systems within 12 Hours
Daily Cyber security update for 25. 10. 2026
Daily Cyber security update for 24. 10. 2026
PHP shares new RCE flaw (CVE 2026-115560) with no patch but mitigation
US banks faced unauthorized access by AI agents in customer accounts: Axios reports
Atlassian patched 176 flaw in Jira and Confluence: Fortinet Urges to Patch Flaws Affecting FortiOS, FortiManager
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.
