DigiCert indique que des comptes auto-enregistrés ont lu des données clients archivées, dont certains documents d'identité

Le 5 novembre 2026, DigiCert — l'autorité de certification de Lehi, dans l'Utah, qui émet les certificats TLS et de signature de code sous-tendant une grande part de la confiance du web public — a détaillé une exposition de données dans un rapport d'incident déposé sur le Bugzilla de Mozilla. La cause première était une erreur de configuration plutôt qu'une exploitation : lors d'une migration d'infrastructure le 4 février 2025, un système interne a été déplacé d'un segment réseau restreint par VPN vers une zone accessible depuis Internet, ce qui a aussi activé une fonction d'enregistrement de comptes jamais prévue pour des inscriptions publiques. Les comptes ainsi créés ne disposaient pas de l'authentification multifacteur que DigiCert impose à son personnel, mais pouvaient tout de même ouvrir des enregistrements clients archivés — et le système est resté exposé pendant environ 17 mois.

Ce qui a été exposé

Les enregistrements archivés étaient des éléments que les clients avaient auparavant soumis pour vérifier leur identité. La plupart des données qu'un compte non autorisé a consultées consistaient en coordonnées professionnelles — noms, adresses e-mail professionnelles, numéros de téléphone et adresses d'entreprise. Pour une petite minorité de comptes, les enregistrements comprenaient aussi des documents d'identité fournis par les clients, tels que passeports, permis de conduire et factures de services, ainsi que d'autres documents indiquant noms et adresses. DigiCert n'a pas précisé combien de clients, de personnes ou de documents étaient concernés, indiquant seulement qu'une faible part de ses informations archivées avait été touchée.

DigiCert a souligné ce que l'intrus ne pouvait pas faire : le compte non autorisé ne pouvait ni modifier des enregistrements, ni approuver des vérifications d'identité, ni émettre de certificats. Ses services centraux d'autorité de certification, les plateformes CertCentral et DigiCert ONE, les identifiants de connexion des clients et les certificats déjà émis n'ont pas été affectés.

Comment cela s'est déroulé

DigiCert a d'abord remarqué, le 18 juin 2026, des comptes n'appartenant pas à des employés, et une première analyse interne a conclu à tort que ces comptes ne pouvaient pas atteindre les données stockées. Un signalement distinct est parvenu le 21 juin via le programme de recherche en sécurité géré de l'entreprise. Un compte non autorisé a lu des enregistrements archivés entre le 27 juin et le 2 juillet 2026, et DigiCert a déployé le 2 juillet un correctif d'autorisation mettant fin à l'exposition. Ce n'est que le 19 octobre 2026 que l'entreprise a confirmé que des données clients avaient effectivement été consultées, le rapport d'incident public et les notifications individuelles suivant début novembre.

Réponse

DigiCert a désactivé l'auto-enregistrement sur toutes les instances du système métier, placé les points d'accès encore exposés derrière une infrastructure de réseau privé, réinitialisé des mots de passe, revu les autorisations du système et renforcé sa surveillance. L'entreprise indique exiger désormais une approbation de sécurité pour toute modification des contrôles d'accès réseau. Pour une autorité de certification — une institution dont toute la valeur repose sur la confiance — l'épisode rappelle avec force que les archives sensibles de vérification d'identité exigent la même rigueur de périmètre que les systèmes d'émission de certificats eux-mêmes, et qu'une seule migration mal orientée peut discrètement l'anéantir.