A February 2025 migration exposed DigiCert customer records online

A February 2025 server migration put an internal DigiCert business system on the public internet. It had previously been reachable only over VPN. The system carried a self-registration feature meant for other applications to use, so external users could create their own accounts. Those accounts weren’t tied to any application, but an authorization flaw let them read archived customer records anyway.

DigiCert, a certificate authority, now confirms that one such account read customer data between June 27 and July 2, 2026. The exposed records held names, business email addresses, phone numbers, and business addresses. For some customers they also held identity documents submitted during certificate validation: driver’s licenses, passports, utility bills, and other documents carrying a name and address. The company is still reviewing which identification documents were exposed and says it will notify those people once that review finishes.

Cloud architect Fabian Bader posted his notification on X. “Thanks @digicert that your data leak was ‘limited’ to only my full PII data and potentially any verification documents I submitted for my certificate,” he wrote.

The timeline shows a triage failure. DigiCert found unauthorized accounts on the exposed system in June 2026 and decided they couldn’t reach customer information, because the accounts weren’t assigned to an application. The company then received a report through its managed security research program flagging that external users could register on the system. It deployed fixes to restrict access and close the authorization flaw, and still didn’t know archived data had been read. “The incident was initially handled as an account-creation issue rather than a data-access event,” DigiCert said in its report. Confirmation that an account had actually read customer data came on October 19, from a later investigation.

The mechanism is ordinary. A feature that is safe behind a network boundary stops being safe when the boundary moves. Self-registration on a VPN-only system is a convenience; the same feature on the public internet is an open door. The authorization model made it worse. An account with no application assignment should have been able to read nothing. Instead the default was permissive enough to grant read access to archived customer records.

The handling is the more useful lesson. DigiCert found the unauthorized accounts and reasoned about what they should have been able to do, rather than checking what they did. Access logs would have answered the actual question. The gap between finding the accounts in June and confirming data access on October 19 is the cost of answering a design question when the situation called for a forensic one.

For anyone running a similar setup, two steps follow from this. After any migration, enumerate what became internet-reachable that previously depended on a network boundary, and re-check the authorization model of each exposed surface against the new exposure. When you find accounts that should not exist, pull their access logs before you decide what they could or couldn’t touch.

DigiCert says the exposed account had read-only access and could not modify records, approve certificate validations, or issue certificates, and that its certificate authority services, CertCentral, and DigiCert ONE platforms were not compromised. Login credentials and issued certificates remain secure. The company has disabled self-registration, restricted access to the affected system, and added access controls. It has not said how many people were affected, describing the exposure only as a small portion of its archived customer data.