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.
LastPass says hackers stole customer data via Klue, supply chain breach
New Apple Exploit Bypasses Boot Defenses, Possibly Affects Millions of iPhones Worldwide
India’s Tata Electronics hit by cyber breach: Hacker target 630 GB record
Anthropic’s Mythos reportedly broke NSA classified systems in hours
OpenAI New Method “Deployment Simulation” Predicts AI Risks Before Deployment
AryStinger botnet infected thousands of D-Link routers globally
Hacker suspected of sending alerts across Brazil
CyberSentinel AI features 33 security tools like Nmap, SQLMap, and ZAP, utilizing Claude and GPT
Barracuda hosts Dhaka roundtable on cyber resilience
CISA Alerts Fortinet Users as FortiBleed Affects 86,644 FortiGate Devices
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.
