Near Ai Corrige Faille Sglang Et Relance Cloud

Imaginez un instant que votre service d’intelligence artificielle, celui-là même qui promettait une confidentialité renforcée grâce à des environnements d’exécution sécurisés, se retrouve brièvement à la merci d’un code malveillant. C’est exactement ce qui s’est produit chez Near Ai au début du mois de novembre. Une vulnérabilité dans le moteur d’inférence open source Sglang a ouvert une brèche. En quelques heures, un attaquant a pu s’introduire, explorer une partie de l’infrastructure et récupérer des informations concernant une centaine d’utilisateurs. Aujourd’hui, le service Cloud est de nouveau opérationnel, les correctifs sont déployés et les personnes concernées ont été informées. Mais cette histoire soulève des questions bien plus larges sur la solidité réelle du computing confidentiel lorsqu’il repose sur des composants logiciels non parfaits.

Comment une faille logicielle a momentanément ouvert les portes de Near Ai

Tout a commencé le 8 novembre. Un acteur non autorisé a exploité une faille d’exécution de code à distance présente dans Sglang, le moteur d’inférence utilisé par Near Ai sur ses serveurs. Cette vulnérabilité lui a permis d’exécuter du code sur un serveur d’inférence, puis de se déplacer vers d’autres parties de l’infrastructure interne. L’équipe de sécurité a rapidement détecté l’intrusion, fermé les accès et lancé une investigation forensique complète.

Selon le rapport publié le lendemain, l’attaquant a réussi à atteindre un système interne lié à l’ancien service Private Chat, désormais abandonné. C’est depuis ce point qu’il a pu télécharger des informations concernant environ cent comptes utilisateurs. Les données exposées comprenaient des adresses e-mail, des noms, et pour certains comptes des détails sur les plans d’abonnement ainsi que les soldes. Heureusement, les conversations stockées et les fichiers téléversés n’ont montré aucun signe d’accès.

Parallèlement, dix-huit agents IA fonctionnant sur une version plus ancienne de la plateforme Near Ai Agents ont été touchés. Ces agents ne tournaient pas à l’intérieur d’un environnement d’exécution de confiance (TEE), ce qui les rendait plus vulnérables. L’attaquant a pu récupérer leurs historiques de discussion, leurs paramètres de configuration et leurs journaux d’activité. Deux clients du service Cloud ont vu leurs clés d’API exposées via ces logs. Near Ai a immédiatement révoqué ces identifiants.

Le rôle central de Sglang dans l’architecture de Near Ai

Sglang est un moteur d’inférence open source de plus en plus utilisé dans le domaine de l’intelligence artificielle générative. Near Ai l’avait intégré pour gérer le traitement des requêtes sur ses serveurs. Le problème ne venait pas du principe même de l’inférence, mais d’une faille de sécurité présente dans la version utilisée au moment de l’attaque.

Ce qui rend l’affaire particulièrement intéressante, c’est que Near Ai mise fortement sur le computing confidentiel. Les environnements d’exécution de confiance (TEE) sont conçus pour isoler les données sensibles même vis-à-vis de l’opérateur de l’infrastructure. En théorie, ni Near Ai ni le fournisseur de serveurs ne devraient pouvoir accéder au contenu des requêtes traitées en mode confidentiel. Pourtant, une vulnérabilité dans le logiciel qui tourne à l’intérieur de cet environnement sécurisé peut tout compromettre. C’est exactement ce qui s’est produit.

Dans son rapport, Near Ai souligne un point important : le computing confidentiel protège efficacement contre les accès externes à l’enclave, mais il ne peut rien faire si le code qui s’exécute à l’intérieur présente lui-même une faille critique. Cette nuance technique est souvent oubliée dans les communications marketing autour de la confidentialité renforcée.

Les mesures prises pour refermer la brèche et relancer le service

Dès la détection de l’intrusion, Near Ai a suspendu les opérations d’inférence Cloud. L’équipe a d’abord fermé l’accès de l’attaquant, puis a entrepris un travail systématique de sécurisation. Le correctif de la vulnérabilité Sglang a été appliqué sur l’ensemble des serveurs d’inférence. Toutes les sessions actives et les identifiants administratifs ont été révoqués. Les tokens des agents ont été renouvelés. Le service Private Chat, déjà en phase de fermeture, a été définitivement mis hors ligne.

Une revue forensique complète a été menée. Les utilisateurs dont les comptes ou les agents avaient été confirmés comme accessibles ont reçu un message personnalisé. Near Ai a précisé clairement : « Si vous n’avez pas reçu de communication de notre part, aucune action n’est nécessaire de votre côté. » Les clients concernés ont été contactés depuis l’adresse officielle de sécurité de l’entreprise. Les propriétaires des dix-huit agents touchés ont également reçu des notifications individuelles.

Une fois ces opérations terminées, le service Cloud a pu être relancé. Les ingénieurs ont confirmé que les correctifs étaient en place et que les credentials sensibles avaient été remplacés. Near Ai a également signalé la vulnérabilité aux mainteneurs du projet Sglang afin que la communauté puisse en tirer les leçons.

Le computing confidentiel protège contre les accès venant de l’extérieur de l’environnement sécurisé, mais il ne peut empêcher une vulnérabilité présente dans les applications qui s’exécutent à l’intérieur de celui-ci.

Rapport de sécurité Near Ai

Ce que l’incident révèle sur les limites du computing confidentiel

Cette affaire met en lumière une réalité souvent sous-estimée. Les environnements d’exécution de confiance constituent une avancée significative pour la confidentialité des traitements d’intelligence artificielle. Ils empêchent l’opérateur de l’infrastructure et même le fournisseur de cloud de lire le contenu des requêtes. Cependant, ils ne créent pas une bulle magique autour du code applicatif.

Si le logiciel d’inférence lui-même contient une faille d’exécution de code distant, l’attaquant qui parvient à l’exploiter se retrouve à l’intérieur de l’enclave. À ce moment-là, les protections matérielles du TEE n’offrent plus de barrière. C’est précisément le scénario qui s’est déroulé chez Near Ai. L’attaquant a pu observer des requêtes traitées le 8 novembre, y compris certaines exécutées en mode confidentiel, même si le rapport ne précise pas le volume exact de données potentiellement consultées.

Cette limite n’est pas propre à Near Ai. Elle concerne l’ensemble des plateformes qui s’appuient sur des moteurs d’inférence open source ou propriétaires tournant dans des enclaves sécurisées. La surface d’attaque se déplace simplement : elle n’est plus centrée sur l’infrastructure, mais sur la qualité et la sécurité du code applicatif déployé à l’intérieur de l’environnement protégé.

Les agents legacy et le risque des versions anciennes

Un autre enseignement important de cet incident concerne les agents déployés sur d’anciennes versions de la plateforme. Les dix-huit agents touchés ne bénéficiaient pas de l’isolation matérielle offerte par les TEE. Ils tournaient dans un environnement plus classique, ce qui a facilité l’accès à leurs historiques, configurations et logs.

Ce type de situation n’est pas rare dans les plateformes en évolution rapide. Les équipes techniques avancent souvent plus vite que la migration complète de tous les déploiements existants. Les agents créés il y a plusieurs mois peuvent continuer de fonctionner sur une architecture qui n’intègre plus les dernières protections. L’incident de Near Ai rappelle qu’il est crucial de maintenir une politique stricte de mise à jour et, si nécessaire, de forcer la migration des charges de travail sensibles vers les environnements les plus sécurisés.

Deux clients ont vu leurs clés d’API exposées dans les journaux de ces agents. Même si Near Ai a réagi rapidement en révoquant ces credentials, l’épisode montre à quel point les logs peuvent devenir un vecteur de fuite d’informations sensibles lorsqu’ils ne sont pas correctement protégés ou nettoyés.

Le protocole Near et l’écosystème plus large restent intactes

Il est important de souligner que l’incident n’a eu aucun impact sur le protocole blockchain Near lui-même. Near Ai a clairement indiqué que ni la chaîne principale ni les autres services de l’écosystème n’avaient été touchés. La brèche restait confinée à l’infrastructure d’inférence de Near Ai et à certains systèmes internes liés à d’anciens services.

Cette distinction est essentielle. Near Ai est une initiative distincte qui s’appuie sur le protocole Near pour certaines fonctionnalités, notamment les paiements et le staking, mais son infrastructure de calcul est séparée. L’attaque n’a donc pas compromis la sécurité de la blockchain ni des actifs des utilisateurs du protocole.

Par coïncidence, cette même semaine, des chercheurs d’Elliptic ont identifié l’utilisation de tokens basés sur Near pour blanchir une partie des fonds liés au piratage de Binance. Environ 117 000 Near ont été acheminés via des pools de liquidité créés entre le 5 et le 7 novembre. Aucun lien n’a été établi entre ces activités de blanchiment et l’intrusion chez Near Ai. Les deux événements sont purement temporels.

Les leçons pour l’ensemble du secteur de l’IA décentralisée

L’incident de Near Ai arrive à un moment où de nombreuses plateformes cherchent à combiner intelligence artificielle et technologies blockchain. L’objectif est souvent double : permettre des paiements décentralisés pour l’accès aux modèles et offrir des garanties de confidentialité via le computing confidentiel. Cette combinaison est séduisante, mais elle introduit de nouvelles surfaces d’attaque.

Le fondateur de Near, Illia Polosukhin, avait d’ailleurs alerté en octobre sur la multiplication des vulnérabilités logicielles dans l’infrastructure internet et avait plaidé pour un recours plus systématique à des systèmes de sécurité assistés par l’intelligence artificielle. L’ironie de la situation n’échappera à personne : une plateforme d’IA se retrouve confrontée à une faille dans l’un de ses composants logiciels clés.

Pour les utilisateurs, l’épisode rappelle l’importance de quelques bonnes pratiques élémentaires. Ne jamais réutiliser les mêmes clés d’API sur plusieurs services. Surveiller les communications officielles des plateformes. Traiter avec prudence tout message non sollicité mentionnant des détails de compte ou des soldes. Near Ai a d’ailleurs explicitement conseillé à ses utilisateurs de rester vigilants face à d’éventuelles tentatives d’ingénierie sociale exploitant les données exposées.

La transparence de Near Ai face à l’incident

On peut reconnaître à Near Ai une certaine transparence dans la gestion de cette crise. L’entreprise a publié un rapport de sécurité relativement détaillé, a contacté les personnes touchées et a communiqué clairement sur l’absence d’impact pour ceux qui n’avaient pas reçu de message. Elle a également signalé la vulnérabilité au projet Sglang, ce qui montre une volonté de contribuer à la sécurité collective plutôt que de se contenter de colmater sa propre brèche.

Cette approche contraste avec certaines pratiques encore trop fréquentes dans le secteur, où les incidents sont minimisés ou révélés avec beaucoup de retard. En publiant rapidement les faits connus et en décrivant les mesures prises, Near Ai a limité le risque de rumeurs et a permis aux utilisateurs de prendre des décisions informées.

L’entreprise a également annoncé qu’elle renforcerait désormais ses revues de sécurité pour couvrir non seulement les composants d’inférence, mais aussi les services associés, les dépendances et les configurations de déploiement. C’est une évolution logique après un incident de cette nature.

Les perspectives pour Near Ai et le computing confidentiel

Malgré cet épisode, Near Ai continue de développer ses activités. En octobre, la plateforme avait dépassé le seuil d’un million de Near stakés dans un service permettant de financer l’inférence IA grâce aux récompenses de staking. Cette mécanique économique reste intacte, tout comme l’ambition de proposer des modèles hébergés avec des garanties de confidentialité.

L’incident servira probablement de catalyseur pour accélérer certaines améliorations. On peut s’attendre à un renforcement des processus de validation des composants open source, à une migration plus rapide des agents legacy vers des environnements TEE, et à une surveillance accrue des logs et des credentials. Ces évolutions sont nécessaires si Near Ai souhaite conserver la confiance de sa communauté.

Plus largement, l’affaire illustre les défis auxquels sont confrontées toutes les plateformes qui tentent de conjuguer performance d’inférence, confidentialité matérielle et ouverture aux technologies open source. Le chemin vers une IA véritablement confidentielle et sécurisée reste long. Chaque incident de ce type, s’il est traité avec transparence et rigueur, contribue à avancer un peu plus loin.

Ce que les utilisateurs doivent retenir

Pour la grande majorité des utilisateurs de Near Ai, l’incident n’a nécessité aucune action particulière. Seule une centaine de comptes ont vu leurs informations de base consultées, et les conversations ainsi que les fichiers n’ont pas été touchés. Les dix-huit agents legacy et les deux clés d’API exposées représentent un périmètre limité, même s’il n’est pas anodin.

Le service Cloud est de nouveau disponible. Les correctifs sont en place. Les credentials sensibles ont été renouvelés. Near Ai a contacté individuellement les personnes concernées et a publié un rapport clair. Dans l’immédiat, le principal risque réside plutôt dans d’éventuelles tentatives d’hameçonnage exploitant les adresses e-mail et les noms récupérés.

À plus long terme, cet événement devrait pousser l’ensemble du secteur à revoir la façon dont les composants d’inférence sont audités et déployés à l’intérieur des environnements de confiance. La promesse du computing confidentiel reste intacte, mais elle repose désormais sur une condition supplémentaire : la solidité du code qui tourne à l’intérieur de l’enclave.

Near Ai a traversé un moment difficile, mais l’a géré avec une relative clarté. L’épisode servira de référence pour d’autres plateformes confrontées à des situations similaires. Dans un domaine où la confiance est un actif aussi important que la technologie elle-même, la manière dont on gère une faille compte presque autant que le fait de l’avoir évitée.

L’histoire de cette faille Sglang n’est pas seulement celle d’une intrusion technique. C’est aussi celle d’une plateforme qui, en quelques jours, a dû passer de la détection à la remediation, de la suspension à la relance, et de la communication interne à la transparence publique. Pour les observateurs du secteur crypto et IA, c’est un cas d’école qui mérite d’être suivi de près dans les mois à venir.

Les implications plus larges pour la sécurité des services d’IA

Au-delà de Near Ai, cet incident invite à réfléchir sur la chaîne de confiance complète des services d’intelligence artificielle. Les utilisateurs confient souvent des données sensibles, des prompts, des historiques de conversation et parfois des clés d’API à ces plateformes. Lorsque l’architecture repose sur des composants open source, la responsabilité de la sécurité se partage entre le projet upstream et l’opérateur qui déploie le logiciel.

Dans le cas de Sglang, Near Ai a signalé la vulnérabilité aux mainteneurs. C’est une bonne pratique. Mais elle pose aussi la question de la cadence des audits de sécurité sur les moteurs d’inférence de plus en plus critiques. Plus ces outils deviennent centraux dans l’écosystème de l’IA, plus les enjeux liés à leur robustesse augmentent.

Les plateformes qui promettent du computing confidentiel devront désormais intégrer explicitement dans leur discours le fait que la protection matérielle ne suffit pas. Elles devront aussi démontrer qu’elles audient régulièrement le code qui s’exécute à l’intérieur des enclaves, qu’elles disposent de processus de mise à jour rapides et qu’elles sont capables de détecter et de contenir une intrusion même lorsqu’elle se produit depuis l’intérieur de l’environnement protégé.

Un regard sur la communication de crise dans le Web3

La manière dont Near Ai a géré la communication autour de l’incident mérite également d’être analysée. Dans l’univers crypto, trop d’équipes choisissent encore le silence ou les formules vagues lorsqu’un problème de sécurité survient. Ici, le rapport a été publié rapidement, les faits ont été exposés avec un niveau de détail raisonnable, et les utilisateurs ont reçu des instructions claires.

Cette transparence relative contribue à préserver la confiance à long terme. Les utilisateurs acceptent mieux un incident lorsqu’ils comprennent ce qui s’est passé, ce qui a été touché et ce qui a été fait pour y remédier. À l’inverse, le manque d’information génère des spéculations et des rumeurs qui peuvent faire plus de dégâts que l’attaque elle-même.

Near Ai a également pris soin de distinguer clairement ce qui relevait de son infrastructure Cloud et ce qui concernait le protocole Near. Cette clarification était importante pour éviter toute confusion dans une communauté où les liens entre les différentes couches de l’écosystème ne sont pas toujours évidents pour tous les participants.

Vers une maturité accrue des plateformes d’IA on-chain

L’écosystème de l’IA décentralisée est encore jeune. Les plateformes comme Near Ai explorent des modèles économiques nouveaux, des architectures techniques hybrides et des promesses de confidentialité ambitieuses. Les incidents de sécurité font partie du processus de maturation. Ce qui compte, c’est la capacité à en tirer des enseignements concrets et à améliorer les défenses.

Dans les mois qui viennent, on peut s’attendre à ce que Near Ai et d’autres acteurs similaires renforcent leurs processus de sécurité logicielle, accélèrent les migrations vers des environnements plus isolés et communiquent davantage sur les audits réalisés. Les utilisateurs, de leur côté, gagneront à rester attentifs aux rapports de sécurité et à adopter des pratiques de gestion des credentials plus rigoureuses.

La faille Sglang exploitée chez Near Ai restera un rappel utile : même les technologies les plus avancées en matière de confidentialité matérielle ne dispensent pas d’une hygiène logicielle irréprochable. Dans le monde de l’intelligence artificielle et de la blockchain, la sécurité se construit couche après couche. Une seule faiblesse peut suffire à compromettre l’ensemble de l’édifice, au moins temporairement.

Aujourd’hui, le service Cloud de Near Ai tourne à nouveau. Les utilisateurs non contactés n’ont rien à faire. Les personnes concernées ont été informées. L’attaque a été contenue. Mais l’épisode laisse derrière lui une question essentielle pour tout le secteur : comment garantir que le code qui s’exécute à l’intérieur des environnements de confiance reste lui-même digne de confiance ? La réponse à cette interrogation déterminera en grande partie la crédibilité des prochaines générations de services d’IA confidentielle.