MediumBreach / campaignOngoing
DigiCert confirms data breach after a migration left an internal system exposed to the internet
A Feb 2025 migration exposed a DigiCert business system; unauthorised accounts read archived customer contact data and some ID documents. CA unaffected.
- Published
- Updated
- Ecosystem
- Enterprise softwareCloud
What happened
- DigiCert confirmed unauthorised access to an internal business system that held archived customer information, after a security misconfiguration left the application reachable from the internet (GBHackers). DigiCert’s own report says the February 2025 migration “inadvertently allowed this internal business system to be accessible externally” (DigiCert report).
- 4 February 2025: an infrastructure migration moved the system from a VPN-restricted segment to an externally accessible availability zone (DigiCert report; GBHackers).
- The exposed system carried a self-registration feature inherited from an account-management platform. Accounts created through it skipped MFA and defaulted to read-only access, and the authorization model did not block unassigned accounts from reading archived data (DigiCert report; BleepingComputer).
- 18 June 2026: an internal team observed non-DigiCert accounts on the system, initially concluded they had no data access, and placed the system behind a WAF (DigiCert report; GBHackers).
- 21 June 2026: a managed security research program reported that external account creation was possible (DigiCert report).
- 27 June to 2 July 2026: the window during which an unauthorised account accessed customer data, per DigiCert’s later investigation (DigiCert report; BleepingComputer).
- 2 July 2026: an authorization patch began returning HTTP 401 for accounts with no assigned application (DigiCert report; GBHackers).
- 12 October 2026: DigiCert first suspected unauthorised access to archived data; 19 October 2026 it determined the event was reportable, and 20 October 2026 it filed a preliminary incident report (DigiCert report).
- DigiCert acknowledged in its report: “The incident was initially handled as an account-creation issue rather than a data-access event” (DigiCert report).
What was exposed
- Most affected records held business contact information: “names, business email addresses, phone numbers, and business addresses” (DigiCert report; BleepingComputer).
- A small minority of accounts also contained customer-provided identity documents, a driver’s licence, passport, or utility bill (DigiCert report; GBHackers).
- DigiCert describes the affected data as “a small proportion” of archived data and has not disclosed a count of affected customers; it says summary statistics are available to Root Program representatives on request (DigiCert report). BleepingComputer says it asked DigiCert for the figure and will update if it responds (BleepingComputer).
- The unauthorised account had read-only access and could not modify records, approve certificate validations, or issue certificates; DigiCert says CertCentral, DigiCert ONE and its certificate authority systems were not accessed (DigiCert report; GBHackers).
What to do
- DigiCert customers: watch for the breach notification DigiCert is sending, and be alert to phishing or social engineering that uses exposed business contact details (BleepingComputer).
- If you submitted identity documents (passport, licence or utility bill) to DigiCert, note that affected individuals are still being identified and will be notified once DigiCert’s document review completes (BleepingComputer).
- No certificate action is required: DigiCert reports no certificate issuance, validation or revocation activity, and says issued certificates and login credentials remain secure (GBHackers; BleepingComputer).
- For your own estate, the incident is a reminder to review infrastructure migrations for exposure changes, disable self-registration on internal systems, and enforce least-privilege authorization, the contributing factors DigiCert identified (GBHackers; DigiCert report).