DigiCert Exposes Archived Customer Identity Documents and Contact Data via Misconfigured Internal System
DigiCert confirmed on October 19, 2026 that an unauthorized account read a subset of archived customer records stored on an internal, non-PKI business system. The exposure stemmed from a February 4, 2025 infrastructure migration that moved an internal archival tool's underlying account manager platform from a VPN-restricted network segment to a publicly reachable availability zone. Most exposed records were routine business contact details such as names, business emails, phone numbers, and addresses, but a small minority of accounts also held identity verification documents such as driver's licenses, passports, or utility bills. DigiCert states the unauthorized account only had read-only access and could not issue, modify, or revoke certificates, and that core services such as CertCentral and DigiCert ONE were unaffected.
Entenda a falha
A vulnerabilidade
This is a misconfiguration and authorization flaw with no CVE, in the account manager platform behind a DigiCert internal archival system (not PKI, not CertCentral or DigiCert ONE). A February 4, 2025 migration moved the platform from a VPN-restricted segment to a publicly reachable availability zone. Anyone on the internet could then use its self-service registration feature. The accounts created this way skipped MFA and got default read-only permissions that still allowed access to archived customer files. An unauthorized account read business contact data and, for a few customers, identity documents. Access was read-only. The articles give no version numbers; the authorization patch came on July 2, 2026.
Como funciona
The archival tool sat on an account manager platform that also had a self-registration feature built for other customer-facing applications. After the migration, the platform was reachable from the internet. An outsider could register an account, and the platform did not require MFA for it. The new account had no application assigned, but the platform gave it default read-only permissions. Those permissions still let it open archived customer files, so the account could view records it should never have reached.
Por que é vulnerável
There were two root causes. The network change was made without a security review, which exposed an internal system publicly. The registration feature was also inherited from the platform even though the archival tool never meant to use it, so its defaults (no MFA, read-only access to archives) were wrong for this use. Authorization did not deny accounts that had no assigned application. DigiCert's fix returns HTTP 401 to such accounts, disables self-registration on all internal instances, and puts endpoints behind private-IP load balancers. It also requires formal security sign-off for network accessibility changes.
Como foi descoberta
DigiCert staff first noticed non-DigiCert accounts on the server on June 18, 2026, and put the system behind a WAF. Three days later a managed security research program report warned that external users could still register accounts. An authorization patch followed on July 2, and in July DigiCert believed the unassigned account had no data access. A deeper log review in October 2026 showed the account had viewed archived files between June 27 and July 2. DigiCert confirmed the incident on October 19, 2026.
Explicação gerada por IA a partir da matéria e dos artigos, em 06/11/2026 00:17.
Detalhes técnicos
The migrated platform carried a self-service registration feature intended for other customer-facing applications. Because the archival tool was never meant to support self-registration, accounts created this way bypassed multi-factor authentication and were assigned default read-only permissions that still allowed access to archived customer files. Internal staff first noticed non-DigiCert accounts on the server on June 18, 2026, and placed the system behind a Web Application Firewall; a managed security research program then warned three days later that external users could still register accounts. Investigators later confirmed the unauthorized access occurred between June 27 and July 2, 2026, a window DigiCert only fully reconstructed during a deeper log review in October 2026, after initially believing in July that the unassigned account lacked data access.
Remediação
DigiCert deployed an authorization patch on July 2, 2026, and later updated the system to return an HTTP 401 error to any account lacking an assigned application. It restricted WAF hostnames to VPN traffic, forced password resets for internal system users on October 17, deactivated the self-registration feature across all internal instances by October 24, 2026, moved remaining endpoints behind private-IP load balancers, added application-level SIEM alerts, and updated internal policy to require formal security sign-off for network accessibility changes. DigiCert has not disclosed the number of affected customer accounts publicly but can provide summary statistics to Root Program representatives on request; affected customers are advised to watch for phishing attempts leveraging exposed business details and to monitor credit reports if they submitted identity documents.
Linha do tempo
-
DigiCert Exposes Archived Customer Identity Documents and Contact Data via Misconfigured Internal System
ler a análise desta fonte ocultar
DigiCert confirmed on October 19, 2026 that an unauthorized account read a subset of archived customer records stored on an internal, non-PKI business system. The exposure stemmed from a February 4, 2025 infrastructure migration that moved an internal archival tool's underlying account manager platform from a VPN-restricted network segment to a publicly reachable availability zone. Most exposed records were routine business contact details such as names, business emails, phone numbers, and addresses, but a small minority of accounts also held identity verification documents such as driver's licenses, passports, or utility bills. DigiCert states the unauthorized account only had read-only access and could not issue, modify, or revoke certificates, and that core services such as CertCentral and DigiCert ONE were unaffected.
Technical Details
The migrated platform carried a self-service registration feature intended for other customer-facing applications. Because the archival tool was never meant to support self-registration, accounts created this way bypassed multi-factor authentication and were assigned default read-only permissions that still allowed access to archived customer files. Internal staff first noticed non-DigiCert accounts on the server on June 18, 2026, and placed the system behind a Web Application Firewall; a managed security research program then warned three days later that external users could still register accounts. Investigators later confirmed the unauthorized access occurred between June 27 and July 2, 2026, a window DigiCert only fully reconstructed during a deeper log review in October 2026, after initially believing in July that the unassigned account lacked data access.
Remediation
DigiCert deployed an authorization patch on July 2, 2026, and later updated the system to return an HTTP 401 error to any account lacking an assigned application. It restricted WAF hostnames to VPN traffic, forced password resets for internal system users on October 17, deactivated the self-registration feature across all internal instances by October 24, 2026, moved remaining endpoints behind private-IP load balancers, added application-level SIEM alerts, and updated internal policy to require formal security sign-off for network accessibility changes. DigiCert has not disclosed the number of affected customer accounts publicly but can provide summary statistics to Root Program representatives on request; affected customers are advised to watch for phishing attempts leveraging exposed business details and to monitor credit reports if they submitted identity documents.