Ce que RingCentral a réellement confirmé
Le bulletin de sécurité du Trust Center de RingCentral, daté du 28 juillet 2026 et classé de gravité ÉLEVÉE, indique que l'entreprise "a récemment découvert qu'elle était la cible d'une campagne d'ingénierie sociale sophistiquée" et qu'elle "a immédiatement pris des mesures pour stopper l'activité non autorisée" avec l'aide d'un cabinet de forensique externe. Le bulletin ajoute: "cet incident a affecté les données d'une part limitée des clients de RingCentral, et nous communiquons directement avec les clients concernés. Si RingCentral ne vous a pas contacté, vous n'êtes pas concerné."
Le groupe d'extorsion ShinyHunters avait revendiqué l'attaque un jour plus tôt, le 27 juillet 2026, affirmant avoir dérobé 623 Go de données, puis a publié une archive de 280 Go après le refus de paiement de RingCentral. Have I Been Pwned a traité cette archive et l'a ajoutée à sa base de données le 13 août 2026: environ 1,6 million d'adresses email uniques, ainsi que des noms, des numéros de téléphone et des adresses physiques. RingCentral a été explicite: la faille n'a atteint ni RingEX, ni RingCentral Contact Center, ni RingCX, ni aucun autre service central, qui "continuent de fonctionner sans interruption."
Un schéma de fournisseurs, pas de victimes
En 2026, ShinyHunters a répété le même scénario contre un fournisseur SaaS après l'autre: instances clients de Salesforce, données clients hébergées sur Snowflake et déploiements Oracle PeopleSoft, le groupe chiffrant lui-même le butin cumulé de ses campagnes à plus de 1,5 milliard d'enregistrements. RingCentral est le dernier nom de cette liste, et la méthode que l'entreprise elle-même décrit, une personne convaincue de céder un accès, plutôt qu'une faille que l'attaquant devait chercher, correspond à une tendance plus large de 2026: des campagnes de vishing et d'ingénierie sociale qui réussissent contre des employés disposant d'un accès privilégié chez le fournisseur, et non chez le client.
Cette distinction compte pour quiconque évalue RingCentral comme fournisseur. Un client peut corriger son propre logiciel et faire tourner ses propres identifiants, mais il n'a aucun moyen de tester, ni même de voir, à quel point le personnel de support et d'administration d'un fournisseur résiste à un appel convaincant. La cible, ici, c'était le personnel de RingCentral, pas son code.
Le vide dans le registre de risque fournisseur
Les entités financières soumises au règlement européen sur la résilience opérationnelle numérique doivent, en vertu des articles 28 à 30 du DORA, tenir un registre d'informations couvrant chaque prestataire TIC et évaluer le risque que chacun fait peser sur leur propre résilience. Les entités essentielles et importantes au titre de la directive NIS2 portent une obligation parallèle, à l'article 21, de gérer le risque cyber de la chaîne d'approvisionnement, y compris les pratiques de sécurité de leurs fournisseurs directs. Les deux cadres présupposent que l'entité régulée puisse obtenir d'un fournisseur assez de détails pour réellement évaluer son risque.
Le bulletin de RingCentral ne précise ni le poste de l'employé concerné, ni le système interne atteint par l'attaquant, ni quel contrôle, authentification multifacteur, vérification par rappel, contrôle d'identité au support, a échoué pour qu'un appel téléphonique se transforme en faille. Une banque allemande, un groupe hospitalier néerlandais ou un assureur britannique qui liste RingCentral dans son registre de prestataires TIC n'a rien de concret à ajouter à cette entrée, sinon qu'un incident a eu lieu. Le questionnaire fournisseur habituel, une attestation SOC 2, un certificat de chiffrement au repos, un résumé de pentest, teste précisément les contrôles techniques qui n'ont jamais été sollicités dans un incident qui a commencé et fini par une conversation.
Ce qu'un opérateur devrait vraiment changer
La solution pratique n'est pas une nouvelle paperasse de chiffrement. Les opérateurs qui dépendent de RingCentral, ou de tout autre fournisseur UCaaS ou CCaaS servant des clients régulés, devraient demander directement au fournisseur s'il mène ses propres tests simulés d'ingénierie sociale contre le personnel de support et d'administration, et traiter la réponse, ou le refus de répondre, comme une entrée à part entière de leur propre registre de risque.
Les renouvellements de contrat après cette divulgation sont le moment d'ajouter une clause précise: un droit à une analyse technique post-incident, pas une déclaration marketing, dans un délai fixe après tout incident confirmé. Sans cette clause, la prochaine notification de faille d'un fournisseur ressemblera exactement à celle-ci, complète et conforme sur le papier, mais inutile pour le seul document, le registre de risque, que la réglementation exige réellement qu'un opérateur tienne à jour.
À lire ensuite: 45 601 failles, 171 sont vraiment exploitées | Un seul message a atteint les clés SSH
