Plus d’une trentaine de modèles de firewalls Firebox de WatchGuard sont exposés à une vulnérabilité de connexion VPN. Le correctif proposé ne garantit cependant pas une protection totale.
Le fournisseur de solutions de sécurité WatchGuard a corrigé un problème critique (CVE-2025-9242, score CVSS 9.3 ) affectant plus d’une trentaine de pare-feux Firebox actuels et anciens. Les versions vulnérables sont les suivantes : 2025.1 (T115-W, T125, T125-W, T145, T145-W et T185), 12.x (T20, T25, T40, T45, T55, T70, T80, T85, M270, M290, M370, M390, M470, M570, M590, M670, M690, M440, M4600, M4800, M5600, M5800, Firebox Cloud, Firebox NV5 et FireboxV), 12.5.x (T15 et T35), 12.3.1 (modèles FIPS) et 11.x. Des correctifs sont respectivement à appliquer : 2025.1.1, 12.11.4, 12.5.13 et 12.3.1_Update3 (B722811), sauf pour la 11.x en fin de vie.
Cette faille, de type écriture hors limites dans le processus iked du système d’exploitation WatchGuard Fireware, permet à un attaquant distant non authentifié d’exécuter du code arbitraire. Elle touche les configurations VPN utilisant le protocole IKEv2 [Internet Key Exchange v2], y compris celles des firewalls en succursale – très répandus dans les PME – dont le réseau est configuré avec une passerelle de pair dynamique. Bien qu’aucune preuve d’exploitation n’ait à ce jour été rapportée, il est conseillé d’appliquer les correctifs dès que possible. Les pirates tentés d’exploiter cette faille pourraient cibler le daemon IKE vulnérable à l’aide d’une attaque spécifique via les ports VPN UDP 500 ou UDP 4500 des pare-feux Firebox.
Un scénario d’exploitation possible malgré le correctif
L’application du correctif ne garantit cependant pas une totale protection. « Si le Firebox était précédemment configuré avec le VPN utilisateur mobile avec IKEv2 ou un VPN de succursale utilisant IKEv2 vers une passerelle de pair dynamique et que ces deux configurations ont depuis été supprimées, ce Firebox peut toujours être vulnérable si un VPN de succursale vers une passerelle de pair statique est toujours configuré », prévient la société. Comment une telle anomalie est-elle possible ? On peut supposer que le système d’exploitation Fireware enregistre les configurations IKE de manière persistante, même après les redémarrages, ce qui peut servir à des fins malveillantes. Pour les clients ayant configuré les VPN de leurs succursales comme une passerelle de pair statique, mais qui ne peuvent pas effectuer de mise à jour immédiate pour des raisons opérationnelles, WatchGuard propose des mesures d’atténuation, décrites dans l’article de la base de connaissances intitulé « Accès sécurisé aux VPN de succursales utilisant IPSec et IKEv2 ».
Pare-feux et VPN sont des cibles de choix
Les clients doivent prendre cette mise à jour très au sérieux. Les pare-feux, et en particulier les VPN, sont désormais constamment pris pour cible par les cybercriminels, ce qui rend encore plus crucial le maintien à jour de leur sécurité. Début août, SonicWall avait demandé à ces clients de désactiver la fonction SSLVPN des firewall Gen 7, soupçonnée de contenir une faille de type zero day exploitée par le groupe de ransomware Akira, selon les experts d’Artic Wolf Labs. La semaine dernière, l’Australian Cyber Security Centre avait d’ailleurs déclaré avoir constaté une augmentation des tentatives d’exploitation par le groupe de ransomware Akira ciblant ce type de vulnérabilité. Début 2025, Fortinet a prévenu les utilisateurs de pare-feux FortiGate et leur avait demandé d’examiner minutieusement leurs systèmes pour éviter tout risque de compromission suite à la diffusion de données de configuration et d’informations d’identification VPN volées il y a deux ans.
L’agent IA de codage en ligne de commande de Google est vulnérable à des attaques par injection de prompts. Elle ouvre la voie à de possibles vols de données incluant des mots de passe et des clés API.
Si les agents IA de codage ont le vent en poupe, les questions autour de leur maturité et de leur sécurité se posent. Preuve en est, la découverte par des chercheurs d’une faille dans Gemini CLI de Google. De type injection de prompts, elle peut être exploitée par des pirates pour voler des données sensibles dont des identifiants, mots de passe et des clés API, sans que les programmeurs s’en aperçoivent. Lancé le 25 juin dernier, cet agent de codage intègre le LLM du fournisseur à des outils traditionnels de lignes de commandes incluant PowerShell ou Bash. Cela permet aux codeurs d’utiliser des prompts en langage naturel pour accélérer les tâches comme l’analyse et le débogage de code, la génération de documentation, et la compréhension de nouveaux répertoires. Deux jours après le lancement de cet outil, Tracebit révèle au fournisseur une première faiblesse que les développeurs pouvaient rencontrer en travaillant sur des dépôts de code open source non vérifiés. Dans leur PoC, des chercheurs ont montré que des prompts malveillants étaient poussés via de simples fichiers readme.md GNU (public licence) laissant croire qu’ils faisaient partie de repository open source.
Les chercheurs ont ensuite découvert d’autres failles potentiellement exploitables ensemble pour exécuter des commandes shell malveillantes. Le premier est que Gemini CLI octroie la capacité aux utilisateurs d’exécuter certaines commandes fréquentes, comme grep [pour rechercher et relier des patterns de texte dans des fichiers contenant des expressions régulières, ndlr], et éviter de constants avertissements d’autorisation. C’est un service utile, sauf quand le système est incapable de distinguer des commandes grep légitimes ou se faisant passer comme tel. Comme la vérification effectuée est simpliste, cela permettrait à un attaquant d’exécuter n’importe quelle commande malveillante qu’ils veulent sans avoir à re-prompter.
Des lignes de commandes camouflables
“Cela pourrait inclure une commande grep suivie d’une autre pour exfiltrer discrètement toutes les variables de l’environnement utilisateur, contenant potentiellement des secrets, à un serveur distant. Cette commande compromise pourrait faire n’importe quoi comme installer un shell distant, effacer des fichiers…”, explique Sam Cox, co-fondateur et CTO de Tracebit. Une fois validée, celle-ci pourrait alors être exécutée mais l’utilisateur ne pourrait-il pas la remarquer comme elle tourne dans son interface de ligne de commandes ? Si tel était le cas, cela permettrait de mettre à jour l’activité de l’attaquant. Malheureusement, Tracebit a découvert que ces lignes de commandes pourraient être cachées dans Gemini CLI en utilisant des caractères blancs pour les rendre invisibles à l’oeil. “C’est une combinaison d’injection de prompt, d’un manque de considération d’expérience utilisateur ne permettant pas de révéler les commandes à risque et leur insuffisante validation. Tout cela combiné, les effets sont significatifs et indétectables”, poursuit M. Cox. Ce même type d’attaque ne marche pas avec des outils concurrents : “Lorsque l’on essaye ce type d’attaque contre d’autres outils de codage IA, nous avons trouvé de multiples couches de protections qui les rendent inopérantes”.
Les outils IA sont un bon moyen d’accélérer et d’automatiser les tâches fastidieuses et consommatrices de temps. Cependant, ils font également la même chose pour aider les attaquants à préparer leur injection de prompt. L’exploit documenté par Tracebit repose sur des hypothèses non dénuées de fondement, selon lesquelles un attaquant pourrait exploiter ces failles dans des conditions réelles. Parallèlement, la chasse contre ce type de vulnérabilités est déjà lancée pour un large éventail de contexte et d’outils.
Un avertissement en cas de non usage du mode sandboxing
Ces trous de sécurité dans Gemini CLI ne seront sans doute pas les derniers. Ils ont été évalués par Google comme étant de gravité élevée (V1) et nécessitant une correction prioritaire (P1), et ont été corrigés dans la version 0.1.14 de Gemini CLI publiée le 25 juillet. Au-delà de la mise à jour, le meilleur conseil est toujours d’exécuter les outils en mode sandbox afin de les isoler du système hôte comme a pu le souligner la firme de Mountain View : “Notre modèle de sécurité pour la CLI est axé sur la fourniture d’un sandboxing robuste et multicouches. Nous proposons des intégrations avec Docker, Podman et macOS Seatbelt, et fournissons même des conteneurs pré-construits que Gemini CLI peut utiliser automatiquement pour une protection transparente”, a déclaré l’équipe du programme de divulgation des vulnérabilités de Google à Tracebit. “Pour tout utilisateur qui choisit de ne pas utiliser le sandboxing, nous nous assurons que cela soit clairement indiqué en affichant un avertissement permanent en rouge tout au long de sa session”.
Des attaques par hameçonnage ont été menées sur des comptes de gestionnaire de paquets (npm) Javascript pour servir à déployer des malwares mais également installer des portes dérobées.
Dans une dernière attaque supply chain découverte par des chercheurs en sécurité de Bluesky, des attaquants ont ciblé la semaine dernière une variété de gestionnaires de paquets (npm) Javascript. Certains ont été compromis pour distribuer des malwares : toute personne téléchargeant ces packages pourraient avoir été exposés à une attaque supply chain à moins de disposer des dernières mises à jour. Dans un exemple daté du 19 juillet, des attaquants ont réussi à camoufler dans le npm Javascript is un malware passé inaperçu pendant six heures. C’est Jordan Harband, ingénieur logiciel chez Bluesky, qui a alerté sur l’attaque : “Sachez que la v3.3.1 de npmjs.com/is comporte un malware à cause d’un autre compte de gestionnaire de package qui a été piraté”. La version infectée a été retirée par les administrateurs npm et la dernière version v3.3.0 a été ajoutée. Depuis, une version 3.3.2 a été publiée à la place alors qu’une autre version compromise, 5.0.0, a aussi été enlevée. “L’ancien propriétaire du paquet supprimé m’a contacté par courriel pour demander sa réintégration. Tout semblait normal, j’ai accepté – agacé par le fait que le npm supprime un propriétaire sans prévenir les autres – et le lendemain matin la version infectée était publiée”, explique M. Harband.
L’utilitaire is propose un runtime de validation de données externes et de vérification d’erreurs. On ne sait pas combien de packages auraient été mis à jour avec la version infectée par malware, ni pendant combien de temps il était en ligne. Mais le fait qu’il ait été téléchargé près de 2,8 millions de fois chaque semaine jusqu’à aujourd’hui donne un indice de l’intérêt que les pirates lui portent. Malheureusement, cette campagne baptisée Scavenger a également ciblé plusieurs autres bibliothèques de test JavaScript populaires avec la même tactique de phishing. Selon le fournisseur en solutions de sécurisation de la supply chain Socket, les packages affectés incluent aussi eslint-config-prettier, eslint-plugin-prettier, synckit@0.11.9, @pkgr/core@0.2.8, napi-postinstall@0.3.1, et got-fetch.
Npm, un terrain de chasse pour les cybercriminels
Cette compromission fait partie d’une campagne supply chain plus large. Assembler les pièces d’un tel puzzle prend beaucoup de temps, et les attaquants en tiennent bien compte. Un problème évident réside dans la possibilité de recourir à l’ingénierie sociale et de pirater les comptes de gestionnaires de paquets avec des techniques classiques d’hameçonnage. Etant donné leur importance, cela constitue une menace potentielle pour tous ceux utilisant des packages npm. Pour compliquer encore plus la situation, le malware est passé entre les mailles de la détection de nombre de clients anti-malware sur VirusTotal. Il est clair que les personnes derrière ces campagnes malveillantes sont déterminées à infiltrer les supply chains et perçoivent le npm comme un bon terrain de chasse. Les escrocs démontrent que quand ils attaquent des paquets compromis, le malware qu’ils implantent peut être puissant. “L’attaque par package npm is n’était pas juste un sujet de DLL spécifiquement Windows. Elle utilise un chargeur de malware Javascript multi-plateformes. Celui-ci tourne entièrement dans Javascript sur les versions 12 et postérieures de Node.js pour macOS, Linux et Windows, et conserve un canal ouvert direct de commande et de contrôle”, fait savoir Tom Hyslip, expert en cybersécurité et cybercriminalité à l’université de Floride Sud.
Mais pourquoi des packages npm ? Selon Max Gannon, analyste chez Cofense éditeur de solutions anti-phishing, ces gestionnaires de paquets sont simplement des exemples de comptes avec des privilèges élevés à large portée. “Plutôt que de s’efforcer de compromettre une seule entreprise sans être sûrs du résultat, les cybercriminels peuvent compromettre un seul développeur et finir par diffuser leur logiciel malveillant dans des centaines, voire des milliers d’autres entreprises”, poursuit M. Gannon. “Même s’il faut dix fois plus de temps pour compromettre un développeur, le gain peut être bien supérieur à ce qui aurait pu être obtenu en compromettant dix autres entreprises au cours de la même période.”
Des mesures à prendre
Selon M. Hyslip, au lieu de rechercher à adapter l’authentification multifacteurs pour les comptes des gestionnaires de paquets, les développeurs devraient s’attarder sur leurs dépendances en utilisant package-lock.json pour stopper les mises à jour malveillantes appliquées sur l’arbre des dépendances que les développeurs ne voient pas. Une autre bonne idée est de recourir à des outils pour tracer les versions installées tout en faisant le rapprochement avec celles dont les vulnérabilités sont connues.
Des outils peuvent être utilisés pour analyser les packages avant installation, attester des versions différentes entre plusieurs répertoires… Les développeurs ne devraient jamais installer de nouvelles versions des packages sans vérifier au préalable si elles sont dans la liste des plateformes de distribution les plus visées. En mai par exemple, Socket a identifié 60 packages npm malveillants, tandis qu’en juin deux packages corrompus de plus ont été découverts en train d’installer des portes dérobées. Prendre le temps de vérifier les mises à jour de paquets doit constituer un réflexe selon M. Ganon : “Dans les logiciels on dit souvent de patcher tôt et souvent. Malheureusement dans le cas des packages cela les rend plus vulnérables aux attaques SCM”.
Des chercheurs ont découvert des faiblesses de sécurité dans la discrète application TM SGNL utilisée par l’ancien conseiller à la sécurité nationale Mike Waltz. Son éditeur israélien a par ailleurs été lui-même récemment victime d’un piratage.
Décidément l’administration Trump a quelques soucis avec l’utilisation des messageries sécurisées. Après l’épisode du Signalgate qui a précipité le départ de Mike Walz, conseiller à la sécurité nationale, c’est l’usage d’une application nommée TM SGNL de la société israélienne TeleMessage qui fait débat. Il s’agit une version modifiée de l’application Signal, plus connue, qui ont mis dans l’embarras des hauts fonctionnaires de l’administration en mars dernier, lorsque le journaliste Jeffrey Goldberg de The Atlantic a été accidentellement ajouté par M. Waltz à une discussion classifiée. Quand ce dernier a été photographié en train d’utiliser TM SGNL, des chercheurs ont commencé à essayer de trouver des informations sur ce service. Contrairement à Signal, l’application n’est pas publique et ne peut être téléchargée à partir de l’App Store d’Apple ou du Play Store de Google. Micah Lee, ingénieur logiciel et ancien journaliste de The Intercept, a finalement réussi à traquer le code source de TM SGNL, découvrant au moins une vulnérabilité grave, l’utilisation d’identifiants codés en dur.
Cela a mis en évidence la question liée à la sécurité de l’application. Cependant, depuis ce moment, M. Lee et le journaliste Joseph Cox ont été contactés par un hacker qui a fourni des preuves que la société derrière TM SGNL, TeleMessage, avait elle-même subi une violation de données, ont-ils affirmé dans un article de 404media. « Les données volées par le pirate contiennent le contenu de certains messages privés et chats de groupe envoyés à l’aide de son clone Signal, ainsi que des versions modifiées de WhatsApp, Telegram et WeChat », indiquent M. Lee et M. Cox. « Les informations comprennent le contenu apparent des messages, les noms et les coordonnées des fonctionnaires, les noms d’utilisateur et les mots de passe du panneau de gestion de TeleMessage, ainsi que des indications sur les agences et les entreprises qui pourraient être clientes de TeleMessage », ont-ils ajouté. Selon le spécialiste en cybersécurité interrogé, non identifié, cette violation a pris « environ 15 à 20 minutes » et « n’a pas demandé beaucoup d’efforts. »
Aucun contrôle public
Si le scandale du « Signalgate » du mois de mars dernier a été marqué par la négligence, la révélation que M. Waltz et d’autres utilisent désormais une application dont personne ou presque n’a entendu parler auparavant est une affaire tout à fait étrange. Dans une série d’articles de blog publiés ce week-end, M. Lee a commencé à lever le voile sur une application utilisée par certaines des personnes les plus haut-placées de l’administration américaine, bien qu’elle semble n’avoir fait l’objet d’aucun audit. C’est probablement la première révélation : l’attrait de l’application semble résider dans sa discrétion. Son code est basé sur celui de Signal sous licence GNU General Public License version 3 (GPLv3) et envoie et reçoit des messages via l’infrastructure serveur de Signal. Comme l’application officielle, ces messages sont également chiffrés de bout en bout (E2EE). Cependant, dans une vidéo explicative, les créateurs de l’application ont déclaré que TM SGNL a été modifiée pour ajouter la possibilité d’archiver les messages. M. Lee a supposé que cela signifiait copier les messages en clair avant qu’ils ne soient chiffrés par TM SGNL, après quoi ils sont envoyés vers un serveur d’archivage dans le cloud. Une découverte qui poussé au passage Signal a sortir le parapluie en faisant savoir dans une courte déclaration « ne pas pouvoir garantir les propriétés relatives à la protection de la vie privée ou à la sécurité des versions non officielles de son application. »
Les messages dans TM SGNL sont donc chiffrés de bout en bout, mais pas sécurisés de bout en bout, car ils existent à deux endroits : sur le terminal (où réside la clé privée de l’utilisateur) et ailleurs (où une clé accessible distincte est utilisée). Cet archivage pourrait être la raison pour laquelle TM SGNL est utilisé : il permet aux fonctionnaires de se conformer aux règles relatives à la conservation des documents gouvernementaux. Mais un pirate pourrait-il cibler ces archives ? Bien qu’il n’y ait aucune preuve que cela se soit produit, selon M. Lee et M. Cox, le serveur que le hacker a violé se trouvait sur le même serveur AWS que celui utilisé pour l’archivage : « En examinant le code source de l’application Signal modifiée de TeleMessage pour Android, 404 Media a confirmé que l’application envoie des données de message à ce point final. Ce dernier a également envoyé une requête HTTP à ce serveur pour confirmer qu’il était en ligne », ont déclaré M. Lee et M. Cox. Ce seul fait devrait soulever de sérieuses questions en matière de sécurité. En outre, M. Lee a découvert que TM SGNL utilise des identifiants codés en dur. Il s’agit d’une faille assez courante, mais elle est incroyablement négligente et poserait un risque de sécurité immédiat si un pirate mettait la main sur le code source. « Le fait que M. Waltz utilise la version TeleMessage de Signal met en évidence la tension et la complexité associées au fait que de hauts fonctionnaires communiquent sur des sujets sensibles à l’aide d’une application qui peut être configurée pour faire disparaître les messages : Les fonctionnaires sont tenus de conserver des enregistrements de leurs communications, mais l’archivage, s’il n’est pas géré correctement, peut potentiellement introduire des risques de sécurité pour ces messages », a noté M. Cox dans un autre article.
La question la plus profonde est de savoir pourquoi tant de fonctionnaires semblent enclins à utiliser des applications telles que Signal ou TM SGNL, alors qu’il existe des systèmes gouvernementaux sécurisés dédiés et éprouvés. Les spéculations à ce sujet abondent. Ce qui est clair, cependant, c’est que quelle que soit la raison, elle a conduit les fonctionnaires à faire des suppositions étonnamment risquées sur la sécurité des applications pour smartphones qui doivent être réévaluées.
Empêtré dans une affaire de violation de données depuis plusieurs semaines, Oracle a prévenu ses clients que le piratage ne concernait pas sa plateforme Cloud Infrastructure mais des serveurs obsolètes. Mais plusieurs experts remettent en cause ce scénario.
Trois semaines après Oracle s’en tient à sa position, à savoir que sa principale plateforme OCI n’est pas impliquée, mais la confusion aurait peut-être pu être évitée grâce à une meilleure communication. Subir une violation est un défi énorme pour n’importe quelle organisation, mais il est parfois bien moindre que les problèmes de communication avec les clients, les journalistes et l’armée de chercheurs intéressés prêts à lever toute ambiguïté. Des semaines après que la faille a été rendue publique, ces ambiguïtés n’ont toujours pas été levées.” >la mise en ligne par un pirate de données prétendument issues de la compromission d’un serveur en production de service SSO d’Oracle, le fournisseur n’en démord pas. Malgré la confirmation de fuite de données par des clients, le fournisseur continue à minimiser la violation de données dont il a été victime, insistant dans un courriel envoyé aux clients cette semaine que le piratage n’a pas impliqué sa plate-forme principale, Oracle Cloud Infrastructure (OCI). Normalement, un tel démenti devrait mettre fin à l’histoire, mais les circonstances de cette violation et la réponse confuse de big red à ce sujet au cours des dernières semaines ont amené certains à remettre en question le compte-rendu de l’incident par l’entreprise. Le courriel de cette semaine affirmait que l’incident concernait « deux serveurs obsolètes » sans lien avec OCI ou les environnements cloud des clients.
« Oracle souhaite affirmer sans équivoque qu’Oracle Cloud – également connu sous le nom d’Oracle Cloud Infrastructure ou OCI – n’a PAS subi de violation de sécurité », indique la lettre. « Aucun environnement client OCI n’a été pénétré. Aucune donnée de client OCI n’a été consultée ou volée. Aucun service OCI n’a été interrompu ou compromis de quelque manière que ce soit », poursuit la lettre. Aucun mot de passe utilisable n’a été exposé car ils étaient « chiffrés et/ou hachés [….] Par conséquent, le pirate n’a pas été en mesure d’accéder aux environnements ou aux données des clients », conclut l’e-mail.
Des informations personnelles d’identification hackées
Mais si les « deux serveurs obsolètes » ne faisaient pas partie du système OCI, de quoi faisaient-ils partie ? Et à quelles données clients le pirate a-t-il eu accès, le cas échéant ? À ce stade, les opinions des chercheurs en sécurité et les contre-affirmations d’Oracle commencent à diverger. L’existence d’une brèche quelconque a été rendue publique pour la première fois en mars, lorsqu’un pirate utilisant le pseudonyme « rose87168 » a rendu public sur un forum de brèches le vol de six millions d’identifiants SSO et LDAP, parmi d’autres données sensibles, prétendument dérobées à la plateforme cloud de l’éditeur. Si c’est vrai, ce serait un gros problème car les identifiants SSO et LDAP, même hachés avec compétence, ne sont pas des éléments qu’un fournisseur de services cloud ou un client souhaiterait voir entre les mains d’un tiers.
Le pirate a déclaré à Bleeping Computer qu’il avait accédé au système Oracle en février, après quoi il avait tenté (en vain) de l’extorquer en échange de la non-divulgation des données. Mais même si les hachs restaient sécurisés, d’autres données sensibles pourraient être utilisées pour monter des attaques ciblées, a fait remarquer la société de sécurité Trustwave : « L’ensemble des données comprend des PII (informations personnelles d’identification), telles que les noms et prénoms, les noms d’affichage complets, les adresses électroniques, les fonctions, les numéros de département, les numéros de téléphone, les numéros de portable et même les coordonnées du domicile », écrivent les chercheurs de Trustwave, qui soulignent que les conséquences d’une telle violation pourraient être coûteuses. « Pour les entreprises concernées, une fuite comme celle-ci pourrait entraîner des responsabilités en cas de violation de données, des sanctions réglementaires, des atteintes à la réputation, des perturbations opérationnelles et une érosion à long terme de la confiance des clients », écrivent-ils.
Une ambiguïté persistante pas levée
Big red a par la suite démenti l’allégation de violation, déclarant aux médias : « Les informations d’identification publiées ne concernent pas l’Oracle Cloud. Aucun client d’Oracle Cloud n’a été victime d’une violation ou n’a perdu de données. » Au début du mois d’avril, l’entreprise a légèrement changé de tactique, admettant avoir été victime d’une violation tout en insistant sur le fait que les données avaient été extraites d’un « environnement existant » (alias Oracle Classic) datant de 2017. La société avait commencé à contacter ses clients, mentionnant que le FBI et CrowdStrike enquêtaient sur l’incident qui est venu s’ajouter à une autre violation de données – décrite comme un événement de cybersécurité – affectant sa filiale spécialisée dans les soins de santé, Health. Jusqu’ici, tout va bien en ce qui concerne les démentis d’Oracle, sauf que le pirate a ensuite partagé des données montrant son accès à login.us2.oraclecloud.com, un service qui fait partie d’Access Manager, le système IAM de l’entreprise utilisé pour contrôler l’accès aux systèmes hébergés par Oracle. Il est également apparu que certaines des données divulguées semblaient dater de 2024 ou 2025, mettant en doute l’affirmation d’Oracle selon laquelle elles étaient anciennes.
La principale plateforme OCI d’Oracle a-t-elle été violée ou non ? Tout le monde n’est pas convaincu par les dénégations catégoriques de l’entreprise. Selon Kevin Beaumont, éminent chercheur en sécurité, l’entreprise a essentiellement joué sur les mots pour différencier les serveurs Oracle Classic dont elle admet qu’ils ont été violés et les serveurs OCI, dont elle maintient qu’ils ne l’ont pas été. « Oracle a rebadgé les anciens services Oracle Cloud en Oracle Classic. Oracle Classic a l’incident de sécurité », a noté Beaumont dans une dissection de l’incident et de la réponse d’Oracle sur Medium. « Oracle nie qu’il s’agit d’Oracle Cloud en utilisant cet argument – mais il s’agit toujours de services Oracle Cloud, qu’Oracle gère. Cela fait partie de son travail de jouer sur les mots. » La société américaine a également contacté discrètement plusieurs clients pour confirmer l’existence d’une sorte de violation, a-t-il ajouté. Les parties intéressées ont donc le sentiment insatisfaisant que quelque chose de fâcheux s’est produit, sans savoir exactement de quoi il s’agit.
Pour l’instant, Oracle s’en tient à sa position, à savoir que sa principale plateforme OCI n’est pas impliquée, mais la confusion aurait peut-être pu être évitée grâce à une meilleure communication. Subir une violation est un défi énorme pour n’importe quelle entreprise, mais il est parfois bien moindre que les problèmes de communication avec les clients, les journalistes et l’armée de chercheurs intéressés prêts à lever toute ambiguïté. Des semaines après que la faille a été rendue publique, ces ambiguïtés n’ont toujours pas été levées.