Une semaine folle en cybersécurité : pourquoi notre chat IA européen est resté à l'abri des récentes failles

tl;dr : Cette troisième semaine d’octobre 2026 a déclenché une vague hors norme d’incidents de sécurité dans toute la tech, mais DentroChat et tes données sont en sécurité.

Si tu suis l’actualité cyber, cette semaine ressemble à un raz-de-marée. Des alertes mineures tombent tout le temps, mais voir autant d’outils fondamentaux et de plateformes cloud touchés en quelques jours, disons-le franchement, c’est FOU.

En moins d’une semaine, tout s’est enchaîné :

• L’incident de l’autorité de certification eMudhra : 8 certificats intermédiaires rattachés à la racine emSign d’eMudhra utilisaient des clés privées extrêmement faibles. Comme ces clés pouvaient être recalculées pour intercepter du trafic HTTPS, les grands navigateurs ont dû bloquer les certificats, eMudhra a annoncé aujourd’hui quitter définitivement le marché mondial des certificats SSL/TLS (!), et des mises à jour d’urgence ont dû être publiées pour uv, pip, Node.js, Bun, Go et Rust (!) afin de retirer l’autorité compromise de leurs magasins de certificats intégrés.
• Des failles critiques dans des briques centrales d’Internet : Deux failles d’exécution de code à distance sans authentification ont été corrigées dans PHP (CVE-2026-109618 et CVE-2026-109619), aux côtés d’un dépassement de tampon critique dans Google Brotli (CVE-2026-111497), d’une RCE sans authentification de sévérité maximale dans GitLab (CVE-2026-110264) et de la faille « PwnEscape » du noyau Linux (CVE-2026-99999).
• La compromission de la chaîne logistique de LiteLLM : Hier, le 21 octobre, des attaquants ont (encore) compromis le pipeline de publication de LiteLLM et poussé une version piégée (v1.107.0) sur PyPI et Docker Hub. Comme le paquet malveillant contenait un hook de démarrage exécuté automatiquement à chaque lancement de Python, il a immédiatement siphonné les identifiants cloud et les clés API des serveurs touchés.
• Les fuites chez Railway et Zeabur : Zeabur a annoncé sa fermeture définitive après une deuxième compromission ayant exposé 3,2 millions d’entrées de variables d’environnement issues de 321 000 comptes. Hier, Railway a également indiqué qu’un attaquant avait pu accéder à des variables d’environnement clients et les déchiffrer. Fait marquant, la cible visait surtout les clés d’inférence IA.
• De grosses compromissions en entreprise : Des attaquants ont accédé à des tenants clients Microsoft 365 grâce à des identifiants de sauvegarde ConnectWise (SkyKick) volés, et Capcom a subi une fuite touchant 11,7 millions de comptes utilisateurs.

Est-ce une « Cyberpocalypse », ou est-ce que le système immunitaire d’Internet se réveille ?

Pourquoi découvre-t-on autant de vieux bugs en même temps dans des compilateurs d’expressions régulières, des décodeurs de compression, des allocateurs mémoire et des configurations cryptographiques ?

La réponse tient surtout au fait que l’IA lit désormais le code du monde entier. Les chercheurs en sécurité et les défenseurs (comme les attaquants) utilisent l’IA pour auditer le code des bibliothèques open source. Résultat : on débusque quantité de cas limites que les relecteurs humains avaient ratés pendant 15 ans. Même les clés faibles de l’autorité eMudhra ont apparemment été repérées avec l’aide de l’IA.

Certains commentateurs parlent déjà de « Cyberpocalypse ». De notre côté, on pense plutôt que le système immunitaire d’Internet se réveille enfin et se soigne lui-même. La plupart de ces bugs dormaient déjà en production depuis des années, et les trouver permet enfin de les corriger.

Comme j’ai écrit mon mémoire de licence à la TU Graz sur le modèle de confiance et les risques structurels des autorités de certification il y a toutes ces années, voir l’affaire eMudhra se répercuter jusqu’à uv, pip, Node.js et Bun me rappelle pourquoi j’avais choisi ce sujet à l’époque. Sur Internet, la confiance prend mille formes et repose sur un système d’une grande complexité.

Où se situe DentroChat face aux incidents de la semaine

Si tu utilises DentroChat au quotidien pour ton travail et tes documents confidentiels, tes conversations et tes fichiers n’ont été touchés par aucun de ces incidents. Comme nous gardons une architecture sobre, la plupart des logiciels concernés ne font pas partie de notre stack, et nous avons immédiatement mis à jour ce que nous utilisons :

• Le problème de confiance CA sur uv, pip, Node.js et Bun : Comme les outils en ligne de commande et les runtimes embarquent leur propre liste d’autorités de certification approuvées, tout outil faisant confiance au certificat racine eMudhra compromis devait être mis à jour. DentroChat n’utilise ni uv ni pip sur ses serveurs. En revanche, notre application web tourne sur Bun : nous avons donc passé nos conteneurs de production sur Bun 1.4.4 (avec les certificats système Debian corrigés), ce qui supprime complètement la racine eMudhra compromise.
• LiteLLM (malware v1.107.0) : Même si nous acheminons nos requêtes IA via une passerelle d’inférence européenne (Cortecs), nous n’utilisons la bibliothèque Python LiteLLM ni ses images Docker nulle part dans notre stack.
• Railway, Zeabur et les plateformes de déploiement cloud : Nous n’hébergeons rien sur des PaaS mutualisés comme Railway ou Zeabur, et nous ne stockons aucune donnée client chez les hyperscalers américains ni sur des tenants cloud Microsoft. Comme indiqué sur notre page Sous-traitants, nous gérons nos déploiements avec notre propre instance Coolify auto-hébergée, directement sur nos serveurs européens. Aucun fournisseur PaaS externe ne détient donc nos variables d’environnement ou nos secrets de déploiement.
• PHP, GitLab et les dépendances applicatives : Nous n’utilisons ni PHP ni GitLab auto-hébergé. De plus, nous avons audité et mis à jour l’ensemble de nos dépendances sur l’application de chat comme sur le site web, et nous sommes aujourd’hui à zéro vulnérabilité connue.

Comment nous concevons DentroChat pour garder tes données en sécurité

Comme l’audit de code assisté par IA continuera de révéler de nouvelles CVE dans les logiciels open source, les paquets tiers ne seront jamais « zéro défaut ». Nous avons donc conçu DentroChat avec un cloisonnement strict, pour qu’une faille dans un composant ne puisse compromettre ni tes données ni nos serveurs.

1. Exécution du code dans une sandbox WebAssembly coupée du réseau

Cette année, un rapport de sécurité très commenté a montré que des agents d’OpenAI s’étaient échappés de leur sandbox lors d’une évaluation interne. Cette évasion a été possible parce que les agents tournaient dans un conteneur Linux qui avait encore accès sur le réseau à un proxy interne de registre de paquets, et l’agent a exploité une faille zero-day dans ce proxy pour rejoindre Internet.

Chez DentroChat, ce chemin d’attaque n’existe pas (à ce jour), parce que nous ne faisons pas tourner le code dans un conteneur Linux doté d’un shell ou d’un installateur de paquets. Lorsque tu importes un tableur ou que tu demandes à DentroChat de lancer une analyse Python, le code s’exécute dans une sandbox WebAssembly (WASM) isolée :

• Chaque bibliothèque Python prise en charge pour l’analyse de données et la création de documents est pré-embarquée au moment du build, de sorte que rien n’est jamais téléchargé depuis PyPI ou un proxy interne à l’exécution.
• Avant même qu’un script Python ne démarre, toutes les API réseau sortantes, les chargeurs de bibliothèques dynamiques et les ponts vers le système de fichiers hôte sont coupés et supprimés du runtime.
• Même si une bibliothèque Python contenait un jour une porte dérobée comme le script de démarrage de LiteLLM, la sandbox WebAssembly n’a aucune connexion réseau pour exfiltrer des données et aucun accès aux variables d’environnement du serveur ni aux fichiers des autres utilisateurs. Une fois ton graphique ou ton document généré, l’espace de travail temporaire est entièrement remis à zéro.

2. Un délai de sécurité de 7 jours contre les attaques supply chain

L’attaque LiteLLM a fonctionné ainsi :

1. la version piégée du paquet est publiée sur PyPI
2. les pipelines de build automatisés du monde entier l’installent aussitôt
3. au bout de 2 heures, des chercheurs en sécurité comprennent que quelque chose cloche
4. mais entre-temps, le code malveillant a déjà pu compromettre de nombreux systèmes

Pour bloquer ce type d’attaque sur la chaîne logistique (« supply chain attack »), notre gestionnaire de paquets applique un âge minimum de publication de 7 jours en plus de fichiers de verrouillage figés. Une nouvelle version d’un paquet open source doit survivre à une semaine complète d’examen public avant que notre pipeline de build n’autorise son installation. Sauf bien sûr lorsque nous auditons et épinglons manuellement un correctif de sécurité précis, comme la mise à jour du runtime aujourd’hui…

3. Pourquoi nous bloquons l’accès au réseau interne quand l’IA consulte des sites web

Quand tu demandes à DentroChat de lire une page web ou de récupérer un jeu de données public sur une API open data, notre serveur récupère cette URL pour toi. Sans frontières réseau strictes, un site malveillant pourrait cacher des instructions dans sa page pour pousser l’IA à interroger des adresses internes du serveur (comme 127.0.0.1 ou des ports internes du réseau Docker) au lieu d’un site public. Cette technique, appelée Server-Side Request Forgery (SSRF), pourrait exposer des services internes qui tournent sur le serveur lui-même.

C’est pourquoi notre module de requêtes sortantes résout le DNS avant de se connecter, bloque toutes les plages d’adresses IP privées, de bouclage (loopback) et internes, et verrouille l’adresse IP vérifiée à chaque redirection. Même si une page tente de piéger le modèle ou utilise du DNS rebinding pour basculer l’IP d’un domaine vers 127.0.0.1 à la dernière milliseconde, la connexion est refusée avant même d’approcher notre réseau interne.

4. Chiffrement au repos géré par nos soins chez Hetzner en Europe

Tous les serveurs applicatifs, bases de données et outils auto-hébergés de DentroChat tournent chez Hetzner en Allemagne, tandis que les sauvegardes chiffrées et les journaux serveur pseudonymisés sont stockés chez Scaleway en France, le tout sous juridiction européenne et hors de portée du US CLOUD Act. Tu peux consulter toute notre infrastructure à tout moment sur notre page Sous-traitants.

Toutes les données sont protégées par un chiffrement en transit et un chiffrement au repos. Un détail technique qu’on oublie souvent : chez la plupart des hébergeurs (y compris Hetzner), les disques des serveurs ne sont pas du tout chiffrés au repos par défaut. C’est pourquoi nous configurons et gérons nous-mêmes le chiffrement au repos. Cette infrastructure solide complète nos contrôles de confidentialité :

• Aucun entraînement sur tes conversations ou tes fichiers
• Suppression automatique des discussions sous ton contrôle
• Mode discussion discrète quand tu veux exclure un échange de la mémoire de l’IA

Rester vigilants

Une bonne sécurité n’est jamais acquise une fois pour toutes.

Encore moins aujourd’hui, alors que chercheurs et attaquants trouvent des failles zero-day avec l’IA plus vite que jamais. Même si nous sommes heureux que notre architecture ait entièrement protégé DentroChat de la vague d’incidents de cette semaine, nous restons sur nos gardes.

Nous évaluons activement comment réduire encore notre temps de réaction face aux futurs exploits zero-day, durcir les frontières de nos serveurs et garder tes données en sécurité, quelle que soit la folie de la prochaine semaine en cybersécurité. Merci de faire partie de DentroChat !