DigiCert prévient ses clients après une fuite dans ses archives ayant exposé des documents d'identité

DigiCert commence à prévenir ses clients

L'avis indique que les informations exposées se limitaient aux noms, aux adresses e-mail professionnelles, aux numéros de téléphone et aux adresses professionnelles. Lorsqu'un client avait fourni une preuve d'identité, elles pouvaient aussi comprendre un permis de conduire, un passeport, une facture d'électricité ou un autre document portant un nom et une adresse. L'architecte cloud Fabian Bader en a publié une copie sur X.

La fuite ne touche donc qu'un groupe restreint : des personnes ayant acheté un certificat et téléversé des pièces d'identité pour les vérifications de DigiCert. L'entreprise indique qu'elle examine encore ces documents pour déterminer qui est concerné et qu'elle préviendra les intéressés une fois cet examen terminé. Elle n'a pas précisé combien de personnes, d'organisations ou de documents sont impliqués. De la partie touchée de ses archives, elle dit seulement qu'elle est petite.

Le message de Bader ne mâche pas ses mots. « Merci @digicert que votre fuite de données se soit 'limitée' à l'ensemble de mes données personnelles et potentiellement aux documents de vérification que j'ai soumis pour mon certificat », a-t-il écrit.

DigiCert a confirmé l'accès non autorisé le 19 octobre 2026 et a déposé son rapport préliminaire d'incident le lendemain. L'entreprise affirme que le compte disposait d'un accès en lecture seule et ne pouvait ni modifier des enregistrements, ni approuver des validations de certificats, ni émettre des certificats.

Comment une migration de serveur a ouvert une archive

À l'origine du problème, un déplacement de serveur le 4 février 2025. Une migration d'infrastructure a fait sortir un système métier interne d'un segment réseau accessible uniquement par VPN pour le placer dans une zone de disponibilité joignable depuis internet.

Le système comportait une fonction d'auto-inscription conçue pour d'autres applications, ce qui permettait à des tiers de créer des comptes. Ces comptes n'étaient rattachés à aucune application et n'étaient pas couverts par l'authentification multifacteur que DigiCert imposait à son personnel. Une faille d'autorisation leur permettait pourtant de lire des informations archivées.

Le personnel a repéré des comptes extérieurs à DigiCert le 18 juin 2026, mais un premier examen a conclu à tort que les comptes sans application rattachée ne pouvaient pas atteindre les données. Un rapport du programme de recherche en sécurité géré de l'entreprise est arrivé le 21 juin. Les ingénieurs ont déployé un correctif d'autorisation le 2 juillet, et les enquêteurs ont ensuite situé l'accès non autorisé entre le 27 juin et le 2 juillet. DigiCert a soupçonné pour la première fois une lecture de données archivées le 12 octobre et a confirmé un incident déclarable le 19 octobre. Son rapport l'admet : « L'incident a d'abord été traité comme un problème de création de comptes plutôt que comme un accès aux données ».

Le système est resté joignable depuis internet de février 2025 jusqu'aux correctifs de juillet. DigiCert ne situe toutefois un accès confirmé aux données que dans la fenêtre du 27 juin au 2 juillet. Rescana fait la même distinction : l'entreprise ne dit pas que des données clients étaient lues depuis février 2025.

Ce qui a été exposé et ce qui ne l'a pas été

Le rapport de DigiCert décrit ce groupe comme des comptes contenant « des données personnelles supplémentaires sous la forme d'un document fourni par le client ».

Ces limites comptent pour quiconque exploite un certificat en production. DigiCert affirme que ses services d'autorité de certification, CertCentral et DigiCert ONE n'ont pas été compromis, et que les identifiants de connexion des clients comme les certificats émis restent sûrs. Les enquêteurs n'ont trouvé aucune émission de certificat, aucun changement de validation ni aucune activité de révocation liés au compte. Les clients n'ont donc pas à remplacer leurs certificats actifs. Rescana, qui a publié une évaluation de l'incident le 6 novembre, classe l'événement en gravité moyenne avec une portée élevée et indique que le rapport de DigiCert ne justifie pas un remplacement d'urgence des certificats.

Ce que DigiCert a changé et ce qui suit

DigiCert a restreint l'accès au système touché, désactivé l'auto-inscription et ajouté des contrôles d'accès. L'entreprise a aussi réinitialisé les mots de passe des systèmes métier, placé les points d'accès encore exposés derrière une infrastructure réseau privée et renforcé la surveillance.

Des alertes sur l'accès aux fichiers et le volume de requêtes au niveau applicatif ont été mises en place le 15 octobre.

Le rapport cite trois facteurs contributifs : un changement réseau effectué sans revue de sécurité suffisante, une surveillance qui ne couvrait pas l'activité des comptes des systèmes métier, et un modèle d'autorisation qui n'avait pas anticipé l'auto-inscription. La leçon énoncée est que « l'autorisation d'un système métier ne doit pas être déléguée à sa position réseau ».

Deux mesures correctives, l'audit de l'exposition des serveurs d'origine et la revue des alertes automatisées sur les comptes, devaient être achevées le 6 novembre. DigiCert a indiqué pouvoir communiquer des chiffres récapitulatifs aux programmes de racines de navigateurs sur demande. C'est par cette voie qu'un décompte pourrait finir par devenir public.