Trois signaux, une même faiblesse
L’histoire “Grok apps expose security gaps” ne se limite pas à quelques applications publiées trop vite. Dans les dernières 72 heures, plusieurs sources ont décrit trois risques liés par une même logique: des applications Grok ouvertes sans connexion, une faille Chrome CVE-2026-125350 déjà exploitée, et GhostFrame, un framework visant les environnements VMware ESXi après compromission , , . Ces incidents touchent trois couches essentielles: la création rapide d’applications, le navigateur qui sert de porte d’entrée au travail cloud, et l’hyperviseur qui concentre les charges critiques.
Le point commun est la confiance accordée par défaut. Un utilisateur peut créer et publier une application plus vite qu’une équipe sécurité ne peut la recenser. Une faille de navigateur peut toucher un parc immense avant que les détails techniques ne soient publics. Un hôte ESXi compromis peut donner un accès indirect à de nombreuses machines virtuelles sans que l’attaquant ait besoin de les compromettre une par une , , . Ce n’est pas une leçon abstraite: l’identité, la gestion des correctifs, la segmentation et la protection des secrets deviennent des contrôles de première ligne.
Ce que Claroc affirme avoir trouvé dans les applications Grok
La société de sécurité Claroc dit avoir testé 37 571 applications créées avec Grok encore en ligne, et en avoir trouvé 35 578 accessibles à toute personne disposant de l’adresse, sans demande de connexion . Cela représente 94,7 % des applications vérifiées . Claroc précise que beaucoup étaient des jeux, des pages simples ou des calculateurs, mais estime qu’environ une sur dix contenait des informations internes, des données personnelles ou d’autres éléments sensibles .
Les exemples cités montrent pourquoi ces petites applications ne doivent pas être traitées comme de simples brouillons. Claroc évoque notamment un annuaire de personnel hospitalier, un briefing de soins intensifs concernant un patient, une liste d’inspection de cuisine de navire, un tableau de service de pompiers et une feuille de temps d’un prestataire dont le code téléchargé par le navigateur contenait des mots de passe en clair pour 18 comptes . FrameSignal rapporte aussi que Claroc a identifié des données internes appartenant à 30 organisations en plus de SpaceXSI et X, dont six entreprises du Fortune 500 .
L’écosystème du créateur de Grok a également été concerné. Claroc affirme que 24 applications ouvertes avaient été créées par des employés de SpaceXSI et de X, avec notamment un plan d’intégration, une carte de territoires commerciaux et des propositions publicitaires . D’après FrameSignal, SpaceXSI a retiré ces 24 applications après les signalements de Claroc les 8 et 9 novembre, mais n’avait pas indiqué, au moment de la publication de Claroc, qu’elle préviendrait les propriétaires des autres applications exposées .
La position rapportée de SpaceXSI est que les applications Grok restent privées jusqu’à ce que leur créateur choisisse de les publier, et que la publication exige plusieurs étapes . La critique de Claroc porte sur un point plus précis: dans le flux observé, le réglage d’accès proposé favorisait “Anyone with the link”, c’est-à-dire l’accès par toute personne possédant le lien , . Pour des données médicales, commerciales, opérationnelles ou personnelles, l’obscurité d’une URL ne constitue pas un contrôle d’accès.
Le vrai problème: l’application fantôme générée par IA
Le risque ne se résume pas à un mauvais clic. Les outils de création par IA fusionnent expression du besoin, génération de code, déploiement et partage dans une seule conversation. C’est utile, mais cela contourne les étapes où les organisations inséraient traditionnellement des contrôles: dépôt de code, revue, scan de secrets, intégration SSO, journalisation, validation de changement et tests de sécurité.
Les constats de Claroc montrent comment une donnée sensible peut passer d’un document, d’un tableur ou d’un prompt à une application web publique sans entrer dans une chaîne logicielle normale . Si l’application est publiée sur un sous-domaine et repose sur le secret du lien, l’entreprise peut même ignorer son existence. Or les journaux DNS passifs, l’indexation, l’historique de navigation, les outils de scan de liens et les transferts de messages peuvent tous rendre ce lien moins secret qu’il n’y paraît.
Les premières mesures sont claires. Les organisations doivent inventorier les applications générées par IA, imposer l’authentification pour tout contenu interne ou personnel, révoquer les identifiants exposés et interdire les secrets dans le code côté client. Elles doivent aussi surveiller les plateformes d’app building comme elles surveillent déjà le SaaS fantôme: découverte d’usage, classification des données et application d’une politique d’identité avant publication.
Chrome rappelle que le navigateur reste une cible majeure
La couche navigateur a envoyé son propre avertissement. Google a publié des mises à jour d’urgence pour CVE-2026-125350, une vulnérabilité use-after-free de gravité élevée dans le composant XML de Chrome, et a reconnu qu’un exploit existait déjà dans la nature . BleepingComputer rapporte qu’il s’agit du huitième zero-day Chrome exploité connu depuis le début de 2026 .
Les versions corrigées indiquées pour le canal stable desktop sont Chrome 157.0.8103.50/.51 pour Windows et macOS, et 157.0.8103.50 pour Linux . The Register souligne également que Google limite l’accès aux détails techniques tant qu’une majorité d’utilisateurs n’a pas installé le correctif, une pratique destinée à réduire les reprises d’exploitation par d’autres acteurs .
Pour les entreprises, il ne suffit pas de dire aux utilisateurs de mettre à jour. Chrome peut télécharger automatiquement un correctif, mais celui-ci ne protège réellement qu’après redémarrage du navigateur. Les sessions longues, les postes personnels, les environnements VDI, les kiosques et les machines rarement redémarrées peuvent rester vulnérables alors même que le correctif est disponible. Les équipes IT doivent donc imposer des délais de relance, vérifier la version réellement exécutée et traiter le navigateur comme un composant critique de l’infrastructure cloud.
GhostFrame attaque le centre de gravité virtualisé
Au niveau infrastructure, Recorded Future Insikt Group décrit GhostFrame comme un framework post-compromission jusqu’ici non documenté pour hôtes VMware ESXi . L’outil n’est pas présenté comme une méthode d’intrusion initiale: l’opérateur doit déjà disposer d’un accès root à l’hôte ESXi pour déployer l’implant . Mais une fois ce seuil franchi, l’effet de levier est considérable.
L’implant de GhostFrame, nommé vmhostd-core, s’installe dans /opt/vmhostd-core et modifie /etc/rc.local.d/local.sh pour persister; il désactive aussi de façon répétée le pare-feu ESXi et le contrôle execInstalledOnly, selon Recorded Future . Le framework peut énumérer les machines virtuelles, modifier leur état d’alimentation, créer ou supprimer des snapshots, activer l’accès VNC, exposer le client HTML ESXi via un tunnel et utiliser un composant SOCKS5 pour pivoter dans le réseau .
La dimension vol d’identifiants est particulièrement préoccupante. Recorded Future indique que GhostFrame intègre notamment sdkmon et VMkatz pour intercepter des connexions ESXi et extraire des éléments d’authentification Windows depuis des snapshots mémoire, des disques virtuels ou des datastores . Dans son briefing du 11 novembre, Cyware résume l’enjeu: un seul hôte ESXi compromis peut devenir une plateforme de contrôle pour de nombreuses VM et un point de collecte d’identifiants dans tout l’environnement .
Recorded Future relie l’activité observée à TAG-218, un groupe dont les opérations recoupent celles du rançongiciel Settra, et indique que l’infrastructure associée ciblait des appliances VPN SonicWall, Palo Alto Networks et Fortinet aux États-Unis et en Europe entre fin août et octobre 2026 . Le chemin d’attaque est important: un accès en périphérie via VPN peut mener à l’hyperviseur, et l’hyperviseur peut ensuite donner accès à de nombreux serveurs.
La priorité: rendre l’exposition visible
Ces trois sujets concernent des technologies différentes, mais la réponse défensive suit la même logique. Il faut d’abord découvrir ce qui existe: applications Grok inconnues, versions Chrome non relancées, hôtes ESXi insuffisamment surveillés. Il faut ensuite rendre l’identité explicite: “toute personne avec le lien” n’est pas un modèle d’autorisation pour des données sensibles, et l’accès d’administration ESXi doit être isolé et réservé à des chemins contrôlés. Enfin, les secrets ne doivent pas se trouver là où un navigateur, un client web ou un attaquant placé au niveau hyperviseur peut les lire.
Pour Grok et les outils similaires, les équipes sécurité devraient mettre en place un processus adapté à la vitesse de ces plateformes: découverte automatique, réglages privés par défaut, SSO obligatoire, blocage des mots de passe et jetons dans le code généré, et revue avant publication. Pour Chrome, l’objectif est l’application effective du correctif, avec preuve de redémarrage. Pour ESXi, les défenseurs doivent rechercher /opt/vmhostd-core, les modifications suspectes de local.sh, un processus se faisant passer pour vmhostd, les désactivations répétées de contrôles de sécurité et les connexions sortantes quasi simultanées vers les ports signalés par Recorded Future .
La conclusion est inconfortable mais simple: le “vibe coding” ne peut pas compter sur une “vibe security”. Les outils qui accélèrent la création, la navigation et la consolidation de l’infrastructure peuvent aussi multiplier les erreurs à grande échelle. Il ne s’agit pas d’abandonner l’IA, les navigateurs ou la virtualisation, mais de traiter leurs réglages par défaut comme des décisions de sécurité, leurs journaux comme des signaux critiques et leur vitesse comme une raison d’automatiser les garde-fous avant que la prochaine exposition ne soit générée.
Commentaires
Sois le premier à commenter.