Au cours de l’année écoulée, @pewdiepie est devenu l’un des plus visibles défenseurs de l’informatique privée et auto-hébergée, et c’est un véritable plaisir à observer.
Ce qui avait commencé fin 2025 comme une expérience amusante – un setup maison avec des GPU moddés faisant tourner des modèles open source, des chatbots votant en « conseil », du calcul offert à la recherche sur le repliement des protéines – a mûri sur environ douze mois en quelque chose doté d’une mission claire.
Le 31 mai 2026, ce projet est arrivé sous le nom d’Odysseus, un espace de travail IA gratuit, open source et auto-hébergé, qu’il a présenté sans détour comme une attaque contre le modèle d’abonnement : local d’abord, confidentialité d’abord, aucune télémétrie, vos données restent sur votre matériau au lieu de filer vers une poignée de grandes entreprises.
Pour quelqu’un avec une telle portée, mettre l’inférence locale devant un public grand public et non technique, c’est exactement ce que le monde de la vie privée attendait depuis des années, et je suis de tout cœur avec ce projet.
Je suis aussi la personne qui, en testant mon propre déploiement autorisé, a trouvé le moyen de prendre le contrôle de l’un de ces serveurs en un seul clic. Les deux choses ne sont pas en contradiction. Un logiciel aussi ambitieux, livré aussi rapidement, dans une catégorie aussi nouvelle, c’est exactement là que se nichent les bugs de sécurité intéressants, et les découvrir tôt est ce qui permet au projet de devenir digne de confiance plus tard.
Donc, dans un esprit d’entraide, voici la chaîne complète, expliquée depuis le début, avec ce qu’elle dit de l’époque que nous construisons.
une porte sans serrure, et un port qui n’avait l’air que de ça
Odysseus peut déléguer des tâches lourdes à des machines GPU distantes via SSH, la manière standard pour un ordinateur d’exécuter des commandes sur un autre.
Une poignée de ses endpoints internes sont donc autorisés à toucher un shell de commande – la ligne de commande brute où, si on peut l’atteindre, on peut faire faire presque n’importe quoi à la machine.
Logiquement, presque tous ces endpoints commencent par vérifier que l’appelant est un administrateur.
L’exception est un petit endpoint discret dont le travail est de lister les paquets Python installés sur un serveur distant, et c’est là que tout se détraque.
Le premier problème est que cet endpoint ne reçoit jamais les informations nécessaires pour identifier son appelant, donc il n’effectue aucun contrôle d’admin et ne peut même pas, en principe.
La seule chose qui le protège est la règle générale de l’application exigeant d’être connecté, ce qui signifie que n’importe quel compte – y compris celui qu’un inconnu vient de créer il y a une minute – peut atteindre une porte touchant au shell, alors que tous ses endpoints frères la gardent soigneusement.
La cause racine structurelle : un gestionnaire qui ne peut pas voir qui appelle ne peut pas imposer qui est autorisé, comme illustré ci-dessous.
Seul, cela pourrait être survivable, mais il y a un second problème dans la manière dont cet endpoint effectue son vrai travail, et c’est le cœur de toute l’attaque.
Pour savoir quels paquets sont installés sur une machine distante, le programme écrit une instruction sous forme d’une seule ligne de texte brut et passe cette ligne à une partie du système appelée le shell, dont le travail est de lire la ligne et de l’exécuter.
La façon la plus simple de se représenter le shell est comme un assistant qui suit les instructions écrites de manière totalement littérale, où quelques signes de ponctuation ont une signification particulière.
Celui qui compte ici est le point-virgule, que le shell interprète comme « cette instruction est terminée, passe à la suivante », donc une seule ligne avec des points-virgules est exécutée comme plusieurs commandes à la suite.
À cause de cela, les programmes prudents prennent tout ce qu’une personne a tapé et l’entourent de guillemets avant de le passer au shell – c’est la façon pour le shell de recevoir l’ordre de traiter ces caractères comme du texte ordinaire, sans pouvoir être exécutés comme des commandes.
Le développeur a fait cela correctement pour le nom du serveur et pour la commande envoyée, donc ces entrées étaient sûres.
Le numéro de port, en revanche, a été inséré dans la ligne à nu, sans guillemets, en partant de l’hypothèse raisonnable qu’un port est toujours un nombre et qu’un nombre ne peut pas faire de mal. (Le chemin de l’environnement virtuel a été concaténé de la même façon sans guillemets, pour la même raison.)
La faille dans cette hypothèse est que le port n’est pas obligé d’être un nombre. Il arrive sous forme de texte brut directement extrait de l’adresse web, et celui qui fait la requête décide de ce qu’il contient.
Donc, à la place de 22, un attaquant écrit 22; id; hostname #.
Le shell lit la première partie, tente de se connecter, échoue sans dommage, puis atteint le premier point-virgule et exécute docilement les deux commandes de l’attaquant, tandis que le # à la fin lui dit d’ignorer le texte restant qui était censé suivre.
Un point-virgule transforme « lister les paquets sur une machine distante » en « exécuter mes commandes sur cette machine ».
Pour y parvenir, il ne faut rien de plus qu’une session connectée et une adresse web forgée :
La requête renvoie un HTTP 200 avec le JSON des paquets normal – pendant que les commandes injectées s’exécutent côté serveur.
Les commandes que j’ai glissées étaient des sondes inoffensives, et quand leur sortie est revenue en nommant le compte de service du serveur lui-même, cela a confirmé que mes instructions s’étaient exécutées sur la machine.
Mettez les deux failles ensemble et le tableau local tient en une phrase : tout utilisateur connecté peut exécuter les commandes de son choix sur le serveur.
Le risque à grande échelle est accentué par ce qui rend Odysseus excitant.
Si un créateur avec cent millions d’abonnés intègre avec succès un large public non technique dans l’auto-hébergement, le résultat est des milliers d’instances similaires, configurées de manière similaire, exposées de manière similaire, ce qui est une monoculture, et les monocultures sont ce que les vers adorent.
@ashnichrist l’a bien dit.
le transformer en un seul clic
Un bug que « tout utilisateur connecté » peut déclencher semble encore nécessiter un initié malveillant, et l’étape suivante supprime même cette exigence, car elle fait en sorte que le navigateur de la victime exécute lui-même l’attaque.
La technique est la falsification de requête intersite (CSRF), et elle repose sur une habitude silencieuse du navigateur.
Une fois que vous êtes connecté à un site, votre navigateur stocke un petit jeton et l’attache automatiquement aux requêtes destinées à ce site, uniquement en fonction de la destination de la requête, sans tenir compte de la page qui l’a déclenchée.
Odysseus a configuré ce jeton avec la politique SameSite=Lax, qui est le réglage par défaut raisonnable et empêche le jeton de circuler sur des requêtes furtives en arrière-plan – mais l’envoie délibérément lors d’une navigation de premier niveau, c’est-à-dire un clic ordinaire qui déplace votre onglet entier.
Comme l’endpoint vulnérable répond à un simple lien, n’effectue aucune vérification de l’origine de la requête et n’utilise pas de jeton anti-falsification, un attaquant n’a qu’à héberger une page avec un bouton attractif.
Pour la démonstration, j’ai construit exactement cela – une page hommage à CoComelon joyeuse, adaptée aux enfants et surtout fidèle à l’univers – couleurs de comptines, Comic Sans, un gros bouton « play ».
Le bouton n’est pas un lien vers une chanson. Son gestionnaire de clic ouvre la cible réelle dans une toute petite fenêtre contextuelle jetable, de sorte que la requête malveillante se produit comme une navigation de premier niveau – transportant le cookie de session SameSite=Lax – sans voler le focus, puis se ferme automatiquement un instant plus tard. L’adresse qu’il ouvre est simplement l’endpoint des paquets avec la commande glissée dans le « port » :
Pendant que ce clic atterrit, la page leurre fait un spectacle pour la caméra : l’illustration CoComelon stroboscope sur l’écran comme un flash de bouche, et un terminal se tape tout seul en narrant chaque étape de la prise de contrôle. (Le texte du terminal est une narration mise en scène pour la démo ; l’exécution réelle est la requête silencieuse que la popup vient de faire.)
Pour rendre l’impact concret, ce seul clic a fait trois choses : il a réécrit l’interface servie pour une défiguration visuelle évidente (un overlay plein écran « 🍉 ton Odysseus a été CoComelonisé 🍉 », des icônes de pastèque, un titre d’application modifié), il a lu tout ce que l’utilisateur du service pouvait lire, et – de façon la plus durable – il a écrit un compte administrateur caché directement dans le auth.json de l’application.
La cerise sur le gâteau : un redémarrage nettoie le désordre apparent et conserve le compte de l’attaquant.
Voici une démo en direct.
pourquoi c’est le pire type de bug à avoir dans un outil agentique
La raison pour laquelle une compromission d’une seule instance devrait vous inquiéter en 2026 est qu’une instance s’arrête rarement là, et le ver qui a défini l’année montre pourquoi.
Shai-Hulud, le ver npm auto-propageant vu pour la première fois en septembre 2025 et revenant en vagues plus importantes depuis, exécute une boucle brutalement simple – un script malveillant au moment de l’installation s’exécute dès qu’un paquet est installé, scanne la machine à la recherche de secrets tels que des jetons npm et GitHub, des clés SSH et des identifiants cloud, puis utilise ces identifiants volés pour publier des versions backdoorées des autres paquets de la victime, de sorte que chaque nouvelle installation devient le prochain point de départ sans effort supplémentaire de la part de l’attaquant.
La leçon à retenir est que la tâche la plus difficile pour un ver est de collecter des identifiants et de trouver un moyen de passer à la machine suivante.
Un assistant IA agentique offre à un ver
ces deux choses
gratuitement, car détenir des secrets puissants et contacter d’autres machines est son but même.
Le seul clic contre Odysseus a rapporté bien plus que l’exécution de code. Il a livré un coffre pré-collecté de clés API stockées, la base de données, la configuration et l’accès SSH que l’outil utilise pour se connecter aux serveurs GPU distants qu’il gère. C’est exactement le carburant sur lequel fonctionne une attaque auto-propageante, assis au même endroit avec l’étiquette tournée vers l’extérieur, et le manuel pour l’utiliser existe déjà dans la nature.
ce que tout cela signifie
Ce qui me frappe le plus, c’est que le bug qui a réellement pris le serveur est ancien. Les injections de commandes et les falsifications de requêtes ont des correctifs classiques qu’un développeur de 2005 reconnaîtrait, et ils vivaient à l’intérieur de l’un des logiciels IA grand public les plus avant-gardistes – ce qui est le schéma dans toute l’industrie cette année, où les vulnérabilités IA vedettes s’avèrent être des failles classiques nichées dans des outils flambant neufs.
La frontière a laissé ces fondamentaux pleinement en vigueur, puis a empilé par-dessus une couche puissante, rapide et souvent trop fiable, et a connecté cette couche à tout ce que vous possédez.
la sonnette qui n’était pas encore câblée
Il y a encore un détail dont il faut tirer une leçon, car c’est la partie qui concerne le moins le code.
Quand j’ai d’abord voulu signaler ce problème, il y avait une politique de sécurité dans le dépôt – une politique réfléchie, avec des conseils de déploiement sensés.
Mais sa section de signalement dirigeait les éventuels rapporteurs vers « les avis de sécurité GitHub si disponibles », et au début ce canal privé n’était tout simplement pas ouvert.
La chose la plus sensible qu’un inconnu pouvait trouver sur le projet n’avait aucun endroit privé où atterrir. Cette lacune a depuis été comblée – la chaîne d’injection de commandes est maintenant suivie par un avis critique, et les correctifs ont été fusionnés – mais l’absence initiale est révélatrice.
Heureusement, j’ai réussi à discuter avec l’un des mainteneurs, qui a ouvert la fonctionnalité des avis de sécurité – et j’ai depuis soumis un certain nombre d’autres correctifs.
Mais à part cela… c’est un signe des temps.
Les projets passent maintenant d’un hobby sur un GPU domestique à un public de cent millions de personnes en l’espace d’une seule annonce, et l’infrastructure de sécurité – une boîte de réception privée pour les mauvaises nouvelles, un workflow d’avis, l’habitude de traiter les sorties de modèles comme hostiles – est en retard sur le code, qui lui-même est en retard sur le public.
Cet ordre est exactement l’inverse de ce dont un adversaire a besoin.
Une large base de fans confiante, largement non technique, installant le même logiciel la même semaine, dirigée vers lui par quelqu’un en qui ils ont déjà confiance, est la cible la plus attrayante qui soit – immense, uniforme et déjà convaincue.
C’est exactement la monoculture qu’un ver veut, avec le tapis de bienvenue déjà déroulé.
Donc, la partie encourageante de cette histoire n’est pas que le code était parfait – il ne l’était pas – mais que le projet a câblé la sonnette et livré les correctifs en environ un jour après avoir entendu frapper.
Pour un logiciel qui va aussi vite, devant un public de cette taille, ce réflexe – ouvrir un canal privé, répondre rapidement, corriger ouvertement – vaut plus que d’avoir eu un bilan irréprochable au départ. C’est, en fin de compte, ainsi que la confiance dans l’auto-hébergement se gagne vraiment.
Pour l’instant… c’est tout, les amis !
https://x.com/Grummz/status/2061300454907371953
https://x.com/ashnichrist/status/2061481763516399737
