Les clients de DigiCert sont confrontés à un risque lié à une fuite qu’un simple changement de mot de passe ne peut pas résoudre : l’exposition de pièces d’identité.
DigiCert, l’une des autorités de certification les plus importantes au monde, a confirmé qu’un tiers non autorisé avait accédé à un système interne d’archivage métier, exposant des fiches de coordonnées clients et des documents d’identification personnelle. La fuite découle d’une migration d’infrastructure effectuée en février 2025, qui a accidentellement exposé un système interne à Internet pendant plus de 16 mois.
L’entreprise affirme que ses services d’autorité de certification, les identifiants de connexion de ses clients et les certificats délivrés n’ont pas été affectés. Les informations clients exposées pourraient néanmoins faciliter des tentatives d’hameçonnage ciblé ou d’usurpation d’identité.
Comment une archive interne s’est retrouvée sur le Web
L’exposition a commencé le 4 févr. 2025, lorsque DigiCert a déplacé une archive métier interne d’un segment réseau restreint par VPN vers une autre zone de disponibilité, rendant accidentellement le système accessible depuis l’extérieur. En même temps que le déplacement du serveur, une fonctionnalité d’auto-inscription destinée à d’autres applications a elle aussi été exposée par inadvertance.
Des utilisateurs externes pouvaient créer des comptes sans authentification multifacteur (MFA), normalement obligatoire pour le personnel. Bien que ces comptes ne disposent d’aucun rôle applicatif attribué, une faille de permissions leur accordait par défaut un accès en lecture seule aux fichiers clients archivés.
DigiCert a repéré des comptes n’appartenant pas à l’entreprise le 18 juin 2026 et a placé le système derrière un pare-feu applicatif afin de bloquer les nouvelles inscriptions externes. Le personnel a d’abord conclu que les comptes sans application attribuée ne pouvaient pas accéder aux données.
Un signalement transmis par l’intermédiaire de son programme de recherche en sécurité encadré a suivi le 21 juin. DigiCert a déployé une correction des autorisations le 2 juillet et confirmé l’accès non autorisé aux données archivées le 19 oct.
« L’incident a d’abord été traité comme un problème de création de comptes plutôt que comme un événement d’accès aux données », a reconnu DigiCert dans son signalement d’incident sur Bugzilla de Mozilla.
| Étape de l’incident | Date consignée | Détail opérationnel clé |
|---|---|---|
| Début de l’exposition | 4 févr. 2025 | Le serveur est déplacé d’un segment VPN vers une zone de disponibilité externe. |
| Accès non autorisé | 27 juin – 2 juil. 2026 | Période confirmée d’accès non autorisé aux données en lecture seule. |
| Correction de la faille | 2 juil. 2026 | Correctif d’autorisation déployé pour mettre fin à l’accès externe. |
| Fuite confirmée | 19 oct. 2026 | L’enquête confirme un accès non autorisé aux données et détermine que l’incident doit être signalé. |
Les documents d’identité exposés créent des risques durables
La plupart des dossiers exposés se limitaient à des coordonnées professionnelles classiques :
- Noms
- Adresses e-mail professionnelles
- Numéros de téléphone
- Adresses professionnelles physiques
Cependant, une petite minorité de dossiers clients contenait des documents de vérification d’identité fournis lors de l’examen des certificats, comme des permis de conduire, des passeports et des factures de services publics.
Comme l’architecte cloud Fabian Bader l’a publié sur X au sujet de l’avis de fuite : « Merci @digicert d’avoir limité votre fuite de données à l’ensemble de mes données personnelles identifiables et potentiellement à tous les documents de vérification que j’ai fournis pour mon certificat. »
DigiCert a précisé que le compte ne pouvait pas modifier les dossiers, approuver les validations ni délivrer de certificats.
Ce que les clients et les équipes de sécurité doivent vérifier
Les clients concernés doivent contacter DigiCert par un canal d’assistance connu afin de déterminer quels dossiers et documents étaient impliqués. Les organisations doivent identifier les employés ou représentants clients concernés et adapter leur réponse aux informations exposées.
Méfiez-vous des demandes inattendues de renvoi de justificatifs d’identité, d’approbation de modifications de certificats ou de transmission des informations de compte. Vérifiez ces demandes de manière indépendante. Il s’agit de précautions contre une utilisation abusive potentielle ; la divulgation ne permet pas d’établir qu’une fraude ultérieure s’est produite.
Si une pièce d’identité officielle a été exposée, consultez l’autorité émettrice pour savoir comment signaler l’incident et s’il convient de la remplacer. Un remplacement peut modifier le numéro du document, mais il ne peut pas récupérer les copies existantes ni modifier toutes les informations personnelles qu’elles contiennent.
Pour les équipes de sécurité, l’incident fournit également des vérifications précises à effectuer sur les archives internes :
Domaine à examiner | Élément à vérifier |
|---|---|
| Permissions des applications | Les comptes sans rôle approuvé ne peuvent pas récupérer de dossiers ni de fichiers. |
| Fonctionnalités d’inscription | Les systèmes internes ne peuvent pas hériter de fonctions d’inscription publique inutiles. |
| Modifications de l’infrastructure | Les contrôles de migration incluent l’accessibilité externe et les contrôles d’accès aux applications. |
| Surveillance | La création inattendue de comptes et les volumes inhabituels d’accès aux fichiers déclenchent une enquête. |
| Conservation des données | Les documents d’identité sont soumis à une durée de conservation et à une procédure de suppression documentées. |
Testez les permissions avec des comptes nouvellement créés et des comptes sans rôle attribué. Incluez des requêtes directes vers les points de terminaison des fichiers : une interface restreinte ne prouve pas que les enregistrements sous-jacents sont protégés.
La faille de Zeabur et les conseils aux clients en cas d’incident mettent également en évidence la nécessité de vérifier la récupération sur l’ensemble des systèmes concernés. Avant de clore une exposition d’archive, déterminez quels comptes pouvaient accéder à quels enregistrements, conservez les journaux pertinents et confirmez que les contrôles corrigés refusent les accès non autorisés.
En savoir plus : la réponse à une fuite dépend des informations exposées. L’incident mSecure explique quels comptes et identifiants stockés les clients doivent prioritairement protéger.