Une fuite de données liée à WIRED a exposé les données de plus de 2,3 millions d’abonnés.
L’incident a été rendu public le 25 déc. 2025, lorsqu’un groupe de cybercriminels a publié une base de données qu’il affirmait avoir extraite directement des systèmes de Condé Nast.
« Nous avons… identifié des identifiants d’abonnés légitimes pour wired.com dans des journaux mondiaux d’infection par des infostealers », ont déclaré les chercheurs.
Quelles données ont été exposées lors de la fuite de WIRED
L’ensemble de données divulgué comprend environ 2,3 millions d’adresses e-mail, près de 286 000 noms d’abonnés, plus de 100 000 adresses postales et plus de 32 000 numéros de téléphone.
Les enregistrements apparaissent au format JSON et comprennent des identifiants utilisateur, des dates de création de compte allant de 2011 à 2022, ainsi que des horodatages d’activité datant au plus tard du 8 sept. 2025.
Les captures d’écran publiées sur BreachForums et Breach Stars suggèrent que les données sont partagées entre les publications de Condé Nast, notamment Vogue, Vanity Fair, GQ et Architectural Digest.
Les chercheurs en sécurité de Hudson Rock ont validé l’authenticité des données de WIRED en les corrélant avec les journaux d’infostealers RedLine et Raccoon, et ont constaté un fort recoupement avec des identifiants déjà compromis.
Bien qu’aucun mot de passe ni donnée de carte bancaire ne figure dans la fuite initiale, les informations personnelles identifiables (PII) exposées accroissent le risque d’hameçonnage, de prise de contrôle de comptes, de divulgation malveillante de données personnelles et d’attaques par ingénierie sociale.
Les IDOR et les contrôles d’accès défaillants à l’origine de la fuite
Selon l’analyse des chercheurs, la fuite provenait de références directes à des objets non sécurisées (IDOR), une catégorie de failles de contrôle d’accès qui permettent aux attaquants d’accéder à des objets du backend en manipulant simplement des identifiants contrôlés par l’utilisateur, tels que des identifiants de compte ou de profil.
Dans ce cas, les profils d’abonnés étaient indexés par des identifiants séquentiels prévisibles, ce qui les rendait vulnérables à l’énumération.
En parcourant systématiquement ces identifiants, les attaquants ont pu interroger les interfaces de programmation d’application (API) sous-jacentes et récupérer des données d’abonnés à grande échelle.
Comme le backend n’appliquait pas systématiquement les contrôles d’autorisation, le système ne vérifiait pas correctement, avant de renvoyer les données, que le demandeur était autorisé à accéder à chaque profil.
Le risque était amplifié par des contrôles d’accès défaillants sur les points d’accès de gestion des comptes.
Les chercheurs indiquent que certains points d’accès chargés de gérer les mises à jour des profils ne disposaient pas de mesures de protection suffisantes en matière d’authentification et d’autorisation.
Par conséquent, les utilisateurs non authentifiés pouvaient non seulement consulter des données sensibles d’abonnés, mais aussi, dans certains cas, modifier des attributs de profil tels que les adresses e-mail et les mots de passe.
Ensemble, ces faiblesses ont permis aux attaquants d’exfiltrer des données en masse sans effectuer un parcours d’authentification complet.
Renforcer les systèmes d’identité contre les abus
Les mesures suivantes présentent les actions que les équipes de sécurité peuvent prendre pour renforcer les systèmes de comptes, limiter l’ampleur d’une compromission et détecter les abus.
- Auditer et faire respecter l’autorisation au niveau des objets pour toutes les API afin de prévenir les accès de type IDOR et l’exposition non autorisée de données.
- Mettre en place une limitation du débit, une régulation des requêtes et des règles de passerelle d’API ou des règles WAF afin de détecter et de bloquer l’énumération et l’extraction de données à grande échelle.
- Remplacer les identifiants séquentiels par des identifiants d’objet impossibles à deviner et segmenter les systèmes d’identité partagés afin de réduire la surface d’attaque et l’ampleur d’une compromission.
- Exiger l’authentification multifacteur pour les connexions et les actions sensibles telles que les changements d’adresse e-mail, les réinitialisations de mot de passe et les mises à jour de profil.
- Améliorer la surveillance et la journalisation des services d’identité afin d’identifier les schémas d’accès anormaux.
Ensemble, ces mesures contribuent à renforcer la résilience des systèmes d’identité et de comptes face aux abus ciblés comme aux abus à grande échelle.
Quand l’échelle des systèmes d’identité devient un risque de sécurité
L’incident rappelle un risque courant dans les environnements d’édition numérique et de SaaS, où les architectures d’identité centralisées favorisent l’efficacité et le passage à l’échelle, mais peuvent aussi amplifier l’impact des faiblesses de contrôle d’accès lorsqu’elles surviennent.
Ces défaillances découlent souvent d’une application incohérente des autorisations plutôt que de techniques d’attaque sophistiquées.
Par conséquent, de nombreuses organisations se tournent de plus en plus vers des architectures zero trust afin d’éliminer la confiance implicite et d’appliquer systématiquement les autorisations à toutes les couches d’identité et d’accès.