DigiCert, l’un des principaux acteurs mondiaux de la certification numérique, a confirmé une fuite de données résultant de l’accès non autorisé à un système interne contenant des informations fournies par ses clients.
L’incident ne concerne toutefois pas directement l’infrastructure de certification de l’entreprise. Selon le rapport d’incident publié par DigiCert dans le cadre du programme de Mozilla, aucun certificat n’a été émis, modifié ou révoqué à la suite de cette compromission. Les services d’autorité de certification, CertCentral et DigiCert ONE sont également restés opérationnels.
L’origine de l’incident est particulièrement instructive : une migration d’infrastructure effectuée en février 2025 a rendu accessible depuis Internet un système qui devait normalement être limité à un réseau protégé par VPN.
Une mauvaise gestion des autorisations et une surveillance insuffisante ont ensuite permis à un compte créé depuis l’extérieur d’accéder en lecture à une partie des données archivées.
Une migration d’infrastructure a exposé un système interne
Selon le rapport officiel de DigiCert, le problème remonte au 4 février 2025.
À cette date, l’entreprise a déplacé un système interne depuis un segment réseau restreint par VPN vers une autre zone de disponibilité. Cette opération a accidentellement rendu le système accessible depuis l’extérieur.
Le problème ne concernait donc pas à l’origine une vulnérabilité connue d’un produit DigiCert avec un identifiant CVE. Il s’agissait principalement d’un changement d’architecture ayant modifié la surface d’exposition du système.
Le rapport précise que la migration avait été considérée comme une modification d’infrastructure et non comme une modification de sécurité. Elle n’avait donc pas fait l’objet du niveau de revue de sécurité qui aurait pu permettre d’identifier cette nouvelle exposition.
Cette distinction est importante. Une infrastructure auparavant protégée par un réseau privé peut devenir vulnérable simplement parce qu’un changement de routage, de zone réseau ou de configuration cloud la rend accessible depuis Internet.
Une fonction d’inscription laissée active a aggravé le problème
La migration n’est cependant qu’une partie de la chaîne ayant conduit à l’incident.
Le système concerné utilisait une plateforme de gestion des comptes également employée dans d’autres environnements DigiCert. Cette plateforme disposait d’une fonctionnalité d’auto-inscription destinée à d’autres cas d’utilisation.
Cette fonction n’aurait pas dû être disponible sur le système interne concerné.
Or, après la migration, le point d’entrée permettant de créer des comptes est devenu accessible depuis Internet.
Les comptes créés par cette méthode n’étaient pas soumis au mécanisme d’authentification multifacteur (MFA) utilisé pour les collaborateurs de DigiCert. Ils étaient configurés en lecture seule, mais cette restriction n’empêchait pas leur accès à certaines données archivées.
C’est précisément cette combinaison qui a rendu l’incident possible :
- un système interne rendu accessible depuis Internet ;
- une fonction d’auto-inscription qui aurait dû être désactivée ;
- des comptes créés sans MFA ;
- un modèle d’autorisation qui permettait malgré tout à ces comptes de consulter des données ;
- une surveillance insuffisante des créations de comptes et des accès.
DigiCert reconnaît dans son analyse des causes que son modèle d’autorisation n’avait pas prévu le scénario d’un compte auto-enregistré sans application associée.
Les données ont été consultées entre le 27 juin et le 2 juillet 2026
La chronologie publiée par DigiCert permet de mieux comprendre comment l’incident a évolué.
Le 18 juin 2026, une équipe interne avait déjà constaté la présence de comptes qui n’appartenaient pas à DigiCert.
Cependant, ces comptes n’étant associés à aucune application, l’analyse initiale avait conclu qu’ils ne pouvaient pas accéder aux données.
Cette conclusion s’est révélée incorrecte.
Le 21 juin, le programme de recherche en sécurité de DigiCert a signalé la possibilité de créer des comptes depuis l’extérieur. L’entreprise a confirmé cette possibilité le 24 juin.
L’analyse forensique réalisée ultérieurement a établi que la consultation des données avait commencé le 27 juin 2026.
Le 2 juillet, DigiCert a déployé une correction empêchant les comptes ne disposant d’aucune application associée d’accéder aux données archivées. Cette correction a mis fin à la fenêtre d’accès identifiée par l’entreprise.
Le détail le plus préoccupant est que DigiCert n’a pas immédiatement identifié l’événement comme une fuite de données.
L’entreprise indique que l’incident avait initialement été traité comme un problème de création de comptes et non comme un événement impliquant une consultation de données.
Ce n’est que le 12 octobre 2026 que DigiCert a commencé à soupçonner qu’une partie des données archivées avait effectivement été consultée.
Le 19 octobre, l’accès non autorisé a été confirmé et l’incident a été considéré comme un événement devant être déclaré aux programmes racine des navigateurs.
Quelles informations ont été exposées ?
Les données consultées étaient principalement des informations professionnelles concernant des représentants de clients.
DigiCert indique notamment que les données concernées comprennent :
- les noms ;
- les adresses e-mail professionnelles ;
- les numéros de téléphone ;
- les adresses professionnelles.
Pour une faible proportion des comptes concernés, l’archive contenait également des informations personnelles supplémentaires sous la forme de documents transmis par les clients pour leurs procédures de validation d’identité.
Il pouvait notamment s’agir :
- de permis de conduire ;
- de passeports ;
- de factures ou justificatifs de domicile ;
- d’autres documents comportant un nom et une adresse.
DigiCert précise que l’incident ne concerne qu’une petite proportion des données archivées. L’entreprise n’a toutefois pas publié de nombre précis de personnes, d’organisations ou de documents concernés dans son rapport public.
Cette absence de chiffre impose donc une certaine prudence. Il serait incorrect d’affirmer qu’un nombre précis de clients a été touché sans disposer d’une confirmation officielle.
Les certificats DigiCert sont-ils compromis ?
C’est probablement la principale question pour les entreprises utilisant les services de DigiCert.
À ce stade, la réponse officielle est non.
DigiCert affirme que ses services d’autorité de certification n’ont pas été affectés. Le rapport indique également que zéro certificat n’a été compromis dans le cadre de cet incident.
Aucun certificat n’a été émis, modifié ou révoqué à la suite de l’accès non autorisé.
Les journaux examinés par DigiCert n’ont montré aucune activité associée au compte compromis concernant la validation, l’émission ou la révocation de certificats.
Les clients n’ont donc pas à remplacer leurs certificats actifs en raison de cet incident, selon DigiCert.
L’entreprise précise également que ses identifiants de connexion clients restent sécurisés.
Les informations publiées dans la page d’état de DigiCert montrent par ailleurs que les principaux services de la plateforme, notamment CertCentral et DigiCert ONE, sont actuellement opérationnels.
Pour rappel, CertCentral est la plateforme de DigiCert utilisée pour gérer différents certificats et leurs cycles de vie, notamment les certificats TLS/SSL.
Aucun accès en écriture ni capacité d’émettre des certificats
L’accès obtenu par le compte concerné était limité à la lecture.
Cela signifie que l’attaquant pouvait consulter certaines informations mais ne pouvait pas modifier les enregistrements concernés.
DigiCert précise également que le compte ne disposait pas des capacités nécessaires pour :
- approuver une validation ;
- modifier les données ;
- effectuer des opérations de certification ;
- demander ou émettre des certificats.
Cette limitation a considérablement réduit l’impact potentiel de l’incident.
Le rapport d’incident indique notamment que l’analyse des journaux n’a révélé aucune opération de validation, d’émission ou de révocation associée au compte utilisé pour accéder aux données.
L’incident est donc avant tout une fuite de données personnelles et professionnelles, et non une compromission de l’infrastructure PKI de DigiCert.
Une erreur de configuration devenue un problème de contrôle d’accès
L’intérêt de cette affaire dépasse le seul cas de DigiCert.
Elle illustre un principe fondamental de la cybersécurité moderne : la sécurité d’une application ne doit jamais dépendre uniquement de son emplacement réseau.
Dans le cas présent, le système était initialement protégé par une restriction réseau. Lorsque cette protection a disparu lors de la migration, plusieurs contrôles applicatifs insuffisants ont permis à un compte externe de consulter des informations.
DigiCert le reconnaît explicitement dans ses enseignements tirés de l’incident : les changements d’accessibilité réseau des systèmes internes doivent systématiquement faire l’objet d’une revue de sécurité.
L’entreprise souligne également que les autorisations d’une application ne doivent pas être déléguées à sa seule position sur le réseau.
Autrement dit, même lorsqu’une application est normalement accessible uniquement depuis un réseau privé, chaque endpoint doit continuer à vérifier les droits de l’utilisateur qui tente d’y accéder.
Une surveillance insuffisante a retardé la détection
Le deuxième enseignement concerne la détection.
DigiCert reconnaît que la surveillance des comptes et des activités sur ce système n’était pas suffisante après la migration.
Le système ne disposait notamment pas d’alertes adaptées pour détecter efficacement :
- la création de comptes inattendus ;
- les accès effectués par des comptes non prévus ;
- des volumes anormaux de requêtes ;
- les consultations inhabituelles de fichiers.
Cette faiblesse explique en partie pourquoi la présence de comptes externes avait été constatée avant que l’accès aux données ne soit correctement identifié.
DigiCert a depuis ajouté des mécanismes de surveillance au niveau applicatif, notamment des alertes concernant l’accès aux fichiers et les volumes de requêtes.
L’entreprise a également renforcé son dispositif de gestion des changements réseau.
DigiCert a désactivé l’auto-inscription et renforcé son architecture
Plusieurs mesures correctives ont été mises en œuvre.
DigiCert indique notamment avoir :
- bloqué le point d’entrée permettant l’inscription externe ;
- déployé une correction empêchant les comptes non associés à une application d’accéder aux données ;
- limité l’accès des systèmes internes au trafic VPN ;
- déplacé les endpoints encore exposés vers des load balancers utilisant des adresses IP privées ;
- désactivé définitivement la fonctionnalité d’auto-inscription sur les instances concernées ;
- réinitialisé les mots de passe des utilisateurs du système ;
- renforcé la surveillance des accès ;
- réalisé un test d’intrusion ;
- effectué une revue du modèle de permissions ;
- imposé une validation de sécurité pour les modifications de l’accessibilité réseau.
Au 30 octobre 2026, DigiCert indiquait avoir terminé sa revue des permissions et confirmé que les endpoints vérifiaient désormais l’association à une application et le rôle de l’utilisateur avant d’autoriser l’accès.
Deux actions restaient toutefois ouvertes dans le rapport publié par l’entreprise : un audit interne destiné à confirmer qu’aucun serveur d’origine n’était accessible depuis Internet et une dernière revue des alertes concernant les créations de comptes inattendues. Ces deux actions avaient une échéance fixée au 6 novembre 2026.
Quel risque pour les clients concernés ?
Même si les certificats et les comptes DigiCert n’ont pas été compromis, l’exposition de coordonnées professionnelles et, dans certains cas, de documents d’identité peut présenter un risque important.
Les informations professionnelles peuvent notamment être utilisées pour préparer des campagnes de phishing ciblées.
Un attaquant connaissant le nom d’un interlocuteur, son adresse e-mail professionnelle, son numéro de téléphone et son lien avec une entreprise peut élaborer des messages beaucoup plus crédibles.
La présence éventuelle de documents d’identité augmente encore le risque pour les personnes concernées.
Il faut donc s’attendre à ce que les personnes ayant reçu une notification de DigiCert soient particulièrement vigilantes face aux messages prétendant provenir de l’entreprise.
La CISA recommande notamment de se méfier des communications qui demandent des informations personnelles ou incitent à cliquer rapidement sur un lien.
Les entreprises doivent-elles prendre des mesures ?
Pour les entreprises utilisant DigiCert, aucune mesure de remplacement des certificats actifs n’est requise sur la base des informations actuellement publiées par DigiCert.
En revanche, les organisations doivent rester attentives aux tentatives d’hameçonnage utilisant les informations potentiellement exposées.
Une bonne pratique consiste notamment à informer les collaborateurs qui ont pu fournir leurs coordonnées ou leurs documents d’identité lors d’une procédure de validation.
Les équipes de sécurité peuvent également renforcer temporairement la surveillance des messages utilisant les marques DigiCert, CertCentral ou DigiCert ONE.
Il est préférable d’accéder directement aux plateformes officielles plutôt que de suivre un lien reçu par e-mail.
La documentation officielle de DigiCert indique notamment que CertCentral permet de gérer les certificats et les accès associés à leur cycle de vie.
Que doivent retenir les responsables cybersécurité ?
L’incident DigiCert fournit plusieurs enseignements applicables à pratiquement toutes les organisations.
1. Toute migration doit déclencher une revue de sécurité
Une modification réseau ou cloud peut transformer une application interne en service accessible depuis Internet.
Il faut donc vérifier systématiquement la surface d’exposition avant et après chaque migration.
2. Le réseau ne doit jamais remplacer l’autorisation applicative
Un système interne doit continuer à appliquer des contrôles d’accès stricts même s’il est supposé être protégé par un VPN, un pare-feu ou un WAF.
Chaque endpoint sensible doit vérifier l’identité, le rôle et les permissions de l’utilisateur.
3. Les fonctions inutilisées doivent être désactivées
Une fonctionnalité d’auto-inscription qui n’est pas nécessaire sur un système interne ne devrait pas rester active.
La réduction de la surface d’attaque passe aussi par la suppression des fonctions inutilisées.
4. Les comptes inattendus doivent déclencher une alerte
La création d’un compte qui ne correspond pas au processus habituel de provisioning doit être immédiatement signalée aux équipes de sécurité.
Il est également nécessaire de conserver suffisamment de journaux pour déterminer non seulement si un compte a été créé, mais aussi quelles données il a consultées.
5. Les données sensibles doivent être conservées le moins longtemps possible
L’incident rappelle enfin un principe important de protection des données : une information sensible qui n’est plus nécessaire ne devrait pas rester indéfiniment dans une archive accessible.
Les entreprises doivent régulièrement réévaluer la durée de conservation des copies de pièces d’identité et autres informations personnelles.
En cas de fuite, la CISA recommande notamment de préserver les journaux et les éléments nécessaires à l’analyse forensique, d’identifier précisément les informations exposées et d’informer les personnes concernées lorsque leurs données personnelles sont impliquées.
Pas de CVE ni de score CVSS pour cet incident
Contrairement à une vulnérabilité logicielle classique, cet événement n’est pas associé dans le rapport de DigiCert à un identifiant CVE ou à un score CVSS.
Le problème décrit est avant tout un incident de sécurité résultant d’une combinaison de mauvaise configuration réseau, de contrôle d’accès insuffisant et de surveillance inadéquate.
Il serait donc trompeur de lui attribuer un score CVSS ou de présenter l’événement comme l’exploitation d’une vulnérabilité logicielle référencée dans une base CVE.
Le rapport de DigiCert le classe comme un incident d’accès non autorisé à un système métier interne.
Conclusion
La fuite de données confirmée par DigiCert illustre parfaitement les risques liés aux changements d’infrastructure lorsqu’ils ne sont pas accompagnés d’une analyse de sécurité complète.
Une migration réalisée en février 2025 a rendu accessible depuis Internet un système interne qui devait rester protégé par VPN. Une fonction d’auto-inscription laissée active et un modèle d’autorisation insuffisamment restrictif ont ensuite permis à un compte externe de consulter une partie des archives.
Les données exposées comprennent principalement des coordonnées professionnelles. Dans une faible proportion des comptes concernés, elles pouvaient également inclure des documents d’identité ou des justificatifs contenant un nom et une adresse.
L’élément rassurant est que les services de certification DigiCert n’ont pas été compromis. Aucun certificat n’a été émis, modifié ou révoqué à la suite de l’incident, et DigiCert indique que CertCentral, DigiCert ONE et les identifiants clients restent sécurisés.
Pour les entreprises, la principale leçon est ailleurs : une infrastructure interne ne peut pas être considérée comme sûre uniquement parce qu’elle se trouve derrière un réseau privé. Chaque changement d’exposition doit être réévalué, chaque compte doit être correctement autorisé et chaque accès aux données sensibles doit être surveillé.
C’est précisément la combinaison de ces contrôles qui permet d’éviter qu’une simple erreur de configuration ne se transforme en fuite de données.
SOURCE : DigiCert
