Skip to content
HACKTECH
Data exposureReported Published 2 sources

DigiCert discloses unauthorised access to internal archive exposed by migration

DigiCert disclosed in a preliminary incident report on Mozilla's Bugzilla, filed on 20 October 2026, unauthorised access to an internal business system that stores information customer representatives provide to validate their identity. Its full report, posted on 1 November, says a February 2025 infrastructure migration moved the system from a VPN-restricted segment to an externally accessible availability zone, where an account self-registration feature let accounts be created without MFA and read archived data. DigiCert says the data access window ran from 27 June to 2 July 2026, that most of the data was business contact information while a small minority of customer accounts included a document such as a driver's licence, passport or utility bill, and that no certificates were issued, modified or revoked. The Register reported that DigiCert has not disclosed how many customers or individuals were affected.

  • DigiCert
  • certificate authorities
  • network migration
  • self-registration
  • MFA
  • access control
  • archive exposure

What the sources report

  • According to DigiCert's full report, an infrastructure migration on 4 February 2025 moved the business system from a VPN-restricted segment to an availability zone that was externally accessible; the report says the migration was treated as an infrastructure change rather than a security change, and The Register reported the move 'didn't get a proper security review.'
  • An account-registration feature 'intended for other use cases' became available to the system; accounts registered through it were not subject to the MFA DigiCert otherwise requires and were read-only by default, but these unassigned accounts had access to archived data.
  • Report timeline: non-DigiCert accounts observed on 18 June 2026 (the reviewer concluded they had no data access because they were not assigned to any application); a managed security programme reported possible account creation through external access on 21 June; data access window 27 June to 2 July; authorisation patch released 2 July; WAF restricted the hostnames to VPN traffic on 9 July; unauthorised access to archived data first suspected on 12 October 2026.
  • DigiCert states 'The access could not write records, act as a validation approver, or issue certificates' and that no certificates were issued, modified or revoked; the report gives no record count, and DigiCert's Bugzilla reply to a request for figures did not give a number.
  • Remediation listed includes deactivating the self-registration feature and moving remaining externally accessible endpoints onto private-IP load balancers and internal hostnames (24 October 2026), a least-privilege review of the permissions model (30 October 2026), new file-access and request-volume alerting (15 October 2026), and an external-vendor penetration test after the authorisation and network changes (completed 31 August 2026).
  • The Register reported on 6 November 2026 that DigiCert told affected customers it is 'completing a review of identification documents to determine the specific individuals involved'; in a Bugzilla reply DigiCert said it had contacted affected customers and reported the incident to law enforcement.

What it means for your organisation

The exposure began with a network change: a system intended for internal access via VPN and MFA became reachable from the internet, and its account and permission model had not been designed for outside users. DigiCert's own lesson, that 'authorization for a business system must not be delegated to its network position', applies to any archive, backup or back-office data store treated as internal. Monitoring that had not been reassessed after the migration, and an initial review that wrongly concluded the unknown accounts had no data access, delayed recognition of the data access until October 2026.

What we check

  • Compare the external attack surface before and after infrastructure or cloud-zone migrations, and require security sign-off for any change that alters network reachability.
  • Test internal data stores, archives and document repositories for authentication and authorisation independently of VPN or network location, including whether self-registered or unassigned accounts can read data.
  • Enumerate self-registration, SSO and account-manager endpoints for features inherited from other products, and confirm MFA is enforced on every registration and login path.
  • Review alerting on new account creation, file access and request volume for document stores, and confirm that triage of unknown accounts includes a review of data-access logs.

Sources

Services that cover these checks

  • Database security audit

    A configuration and access review of your production databases: who can connect, from where and with which privileges, whether data is encrypted at rest and in transit, what is logged, and whether backups would survive the same attacker. We read each instance's live configuration.

    Duration: 3 to 7 working days

  • Cloud configuration review

    An IAM-first review of AWS, Azure or GCP. We map what an attacker reaches after compromising one workload or one developer laptop, then rank those paths by the data at the end of each and write the Terraform or policy change that cuts it.

    Duration: 4 to 8 working days

  • Network & infrastructure testing

    Internal and external network testing, including Active Directory. Where scope allows we go from an unauthenticated foothold to domain-wide impact and document the whole chain: the exposed service or sprayed credential that got us in, each privilege escalation on the way, and the accounts and hosts it reached.

    Duration: 5 to 12 working days

  • Incident response

    Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.

    Duration: Live incidents until recovery is verified; readiness work in days

Run these checks against your own systems

We pick the checks that apply to your systems. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.

Scope an engagementHow the scoping call works