What happened
BleepingComputer reports that a server migration mistakenly exposed an internal business system to the internet, allowing unauthorized access to customer information and identity documents. DigiCert's public incident report on Mozilla's Bugzilla gives the detail. The system archived information that customer representatives had supplied so DigiCert could validate their identities.
The exposed data was mostly business contact information: names, business email addresses, phone numbers and business addresses. A small minority of customer accounts held extra documents such as passports, driver's licenses or utility bills. Those documents are the part that could enable identity fraud.
How a migration became a breach
According to DigiCert's report, on February 4, 2025, the system moved from a VPN-restricted network segment to a different, externally reachable availability zone. The system runs on an account-manager platform with an optional self-registration feature built for other products. That feature came along with the migration.
Three things compounded the exposure:
- No MFA on self-registered accounts. These accounts were not subject to MFA and received default read-only permissions that still allowed access to archived customer records.
- A flawed authorization model. An account with no application assigned was expected to see nothing. In practice it could read archived data.
- Thin monitoring. DigiCert says the system had insufficient alerting on new account creation and on request volume.
DigiCert's own root-cause analysis says the migration was treated as an infrastructure change rather than a security change. It therefore skipped the review that would have examined the new attack surface. The report's lessons-learned section says authorization must not be delegated to a system's network position. In other words, "it's behind the VPN" is not an access control.
Timeline
| Date | Event |
|---|---|
| Feb 4, 2025 | Migration makes the system externally reachable |
| Jun 18, 2026 | Staff notice non-DigiCert accounts and conclude, wrongly, that they can't read data. A WAF blocks new account creation through external access |
| Jun 21, 2026 | A report from DigiCert's managed security research program flags external account creation |
| Jun 27 – Jul 2, 2026 | Window in which archived data was accessed, as later reconstructed |
| Jul 2, 2026 | Authorization patch released. Unassigned accounts now get HTTP 401 |
| Jul 9, 2026 | WAF restricts the system's hostnames to VPN traffic, except approved endpoints |
| Oct 12, 2026 | DigiCert first suspects archived data was accessed |
| Oct 19, 2026 | Access confirmed and judged reportable under browser root program requirements |
| Oct 20, 2026 | Preliminary incident report filed |
| Oct 24, 2026 | Self-registration deactivated. Remaining endpoints moved to private-IP load balancers |
The gap between July 2 and October 19 is the uncomfortable part. DigiCert says it fixed the hole but did not know data had been read. In its words, "The incident was initially handled as an account-creation issue rather than a data-access event." The company says it kept detailed logs and audit tables. Those let it reconstruct the access window and rule out writes to the system or any validation activity.
What DigiCert says was not affected
DigiCert's statements, as reported:
- The unauthorized account had read-only access. It could not write records, approve validations or issue certificates.
- The company says its certificate authority services, CertCentral and DigiCert ONE were not compromised, and customer login credentials and issued certificates remain secure.
- Log review found no validation, issuance or revocation activity tied to the account.
- Customers need not take action on active certificates or continued use of DigiCert services.
These are DigiCert's own conclusions. Outside parties have not independently verified them. They are also consistent across the Bugzilla report and the press coverage.
Why Windows and IT admins should care
DigiCert certificates secure TLS endpoints, code signing and S/MIME across Windows environments. The incident does not touch those certificates. It does, however, affect the people who ordered them. Anyone who went through organization or individual validation may have supplied identity documents to DigiCert.
The incident also touches the root-program rules that Windows relies on. DigiCert's report lists the Mozilla, Chrome, Microsoft and Apple root program policies as relevant. For Microsoft that is section 2.1.18 of the Trusted Root Program Policy. The breach occurred in DigiCert's own business system, not in a Microsoft service. The root-program listing is simply the disclosure obligation that applies to a CA.
One participant on the Bugzilla thread has already asked DigiCert whether this was subscriber verification information and for numbers on the exposed data set. At the time of the report, DigiCert had not published a count of affected people or documents. It says summary statistics can be given to root program representatives on request. Security researchers and reporters are watching that thread.
What to do now
The following is general security practice, not DigiCert guidance:
- Find out who at your organization dealt with DigiCert. Check which people gave names, business emails, phone numbers or addresses. Check who uploaded ID documents or utility bills for validation.
- Watch for notifications. DigiCert has started sending notices. It says it is still reviewing identification documents and will contact people affected by those separately. Cloud architect Fabian Bader posted a copy of his notice on X.
- Alert the exposed individuals to targeted phishing. Names plus business context are good raw material for convincing lures, including ones that pose as certificate renewals or validation requests. Staff should be skeptical of unexpected emails about their certificates.
- Treat exposed ID documents as a personal-risk issue. People whose passport or driver's license was in the archive may want to consider credit monitoring or identity-theft protections. The right steps depend on jurisdiction.
- Don't rush to re-issue certificates. DigiCert says none were affected, and the report shows no issuance or revocation tied to this event.
What's still open
DigiCert's report lists two actions as ongoing, both due November 6, 2026. One is an internal audit confirming that no business-system origin server is externally accessible. The other is a final review of alerting for unexpected account creation or permission changes, including escalation paths. Completed items include a policy requiring security sign-off for network-access changes to internal tools, and an external penetration test finished on August 31, with findings remediated. DigiCert has also named a single owner for the system's security posture.
Analysis
The failure is a familiar one, and it is mundane. No sophisticated exploit was involved. A routine migration changed the network position of a system whose security depended on that position. The account-creation feature then turned an exposure into a data-access path. Many Windows shops have run the same pattern with internal web apps, file portals and admin tools moved to the cloud.
The detection failure is arguably the bigger lesson. Staff saw the strange accounts on June 18, but the question they asked was whether the accounts were assigned to an application, not what they could read. Anyone running incident response can take something from that. Unexpected accounts are evidence of possible access, not just a configuration oddity.
On the other side, DigiCert did self-report to the root programs. It kept logs good enough to reconstruct the access window. It also has a documented list of fixes and owners. The open questions are scale, and why more than three months passed between the patch and the confirmation. Until DigiCert publishes numbers, the scale of the exposure is unknown.