Découverte d’une vulnérabilité d’exécution de code à distance non authentifiée dans OpenCode

 (cy.md)
3 points par GN⁺ 2026-01-13 | 1 commentaires | Partager sur WhatsApp
  • Une vulnérabilité critique d’exécution de code à distance permettant d’exécuter du code arbitraire sans authentification a été découverte dans les anciennes versions d’OpenCode
  • Les versions antérieures à la v1.1.10 lancent automatiquement un serveur HTTP qui permet, sans procédure d’authentification, l’exécution de commandes arbitraires, la lecture de fichiers et la création de sessions de terminal
  • Avant la v1.0.216, le simple fait de visiter un site web pouvait suffire à exécuter du code dans l’environnement local de l’utilisateur
  • Dans la dernière version (v1.1.10), le serveur est désactivé par défaut, mais il reste dépourvu d’authentification lorsqu’il est activé
  • Cette vulnérabilité a été enregistrée sous le nom CVE-2026-22812, et les développeurs comme les utilisateurs doivent mettre à jour immédiatement et vérifier leur configuration

Aperçu de la vulnérabilité

  • OpenCode est un assistant de codage IA open source qui, avant la v1.1.10, démarrait automatiquement un serveur HTTP (port par défaut 4096+) à l’exécution
    • Le serveur expose des endpoints tels que POST /session/:id/shell, POST /pty, GET /file/content
    • En l’absence de procédure d’authentification, tout client capable de s’y connecter peut exécuter du code avec les privilèges de l’utilisateur
  • Aucun indicateur visuel ne signale à l’utilisateur que le serveur est en cours d’exécution, ce qui rend son exposition difficile à détecter
  • La politique CORS est codée en dur sur *.opencode.ai, ce qui permet à des pages servies depuis opencode.ai ou un sous-domaine d’accéder à l’API du serveur
    • Si ce domaine est compromis ou présente une faille XSS, tous les utilisateurs dont le serveur est actif peuvent devenir des cibles

Vecteurs d’attaque

  • Avant la v1.0.216 : n’importe quel site web pouvait exécuter du code sur la machine locale d’un utilisateur exécutant OpenCode
  • Avant la v1.1.10 : un processus local ou une page localhost pouvait exécuter du code sans authentification
  • Dans toutes les versions lorsque le serveur est activé :
    • Les processus locaux et les pages localhost peuvent exécuter du code sans authentification
    • Avec le flag --mdns, tout appareil du réseau local peut y accéder
    • Aucun indicateur ne montre que le serveur tourne, si bien que l’utilisateur peut ignorer son exposition
    • Le domaine opencode.ai ou ses sous-domaines peuvent exécuter du code

Exemples d’attaque (Proof of Concept)

  • Attaque locale : lorsque le serveur est en cours d’exécution, un processus local peut créer une session avec la commande curl, puis exécuter la commande id > /tmp/pwned.txt
  • Attaque via navigateur (avant la v1.0.216) : une page web peut transmettre des commandes au serveur local via des requêtes fetch, puis télécharger et exécuter un script distant
    • Fonctionnement confirmé sur Firefox ; Chrome peut afficher une demande de confirmation utilisateur en raison de ses protections d’accès au réseau local

Mesures à prendre côté utilisateur

  • Vérifier la version avec opencode --version, puis mettre à jour vers la v1.1.10 ou une version ultérieure
  • Vérifier dans le fichier de configuration si les options server.port ou server.hostname sont activées
  • Ne pas utiliser le flag --mdns (liaison à 0.0.0.0, exposant le service à l’ensemble du réseau)
  • Si l’utilisation du serveur est indispensable, éviter d’accéder à opencode.ai et à ses sous-domaines
  • Garder à l’esprit que les processus locaux peuvent accéder au serveur sans authentification lorsqu’il est activé

Calendrier de divulgation

  • 2025-11-17 : premier signalement par e-mail, aucune réponse
  • 2025-12-27 : soumission d’un GitHub Security Advisory, aucune réponse
  • 2025-12-29 : publication du signalement par un autre utilisateur
  • 2025-12-30 : application d’une restriction CORS dans la v1.0.216
  • 2026-01-09 : désactivation du serveur par défaut dans la v1.1.10
  • 2026-01-11 : divulgation complète

Actions recommandées

  • Limiter CORS au strict minimum de domaines nécessaires (appliqué dans la v1.0.216)
  • Désactiver le serveur par défaut (appliqué dans la v1.1.10)
  • Ajouter une procédure d’authentification à toutes les requêtes du serveur
  • Fournir à l’utilisateur un indicateur clair lorsque le serveur est en cours d’exécution
  • Documenter explicitement que l’option --mdns effectue une liaison sur 0.0.0.0
  • Appliquer TLS aux communications réseau
  • Publier officiellement le GitHub Security Advisory et le CVE-2026-22812
  • Renforcer la surveillance des e-mails de signalement de sécurité et des alertes GHSA
  • Clarifier la relation de confiance entre les mainteneurs d’OpenCode, opencode.ai et les utilisateurs

Références

  • CVE : CVE-2026-22812
  • Package concerné : npm opencode-ai
  • Dernières informations et contact : cy.md

À lire aussi

1 commentaires

 
GN⁺ 2026-01-13
Réactions sur Hacker News

  • En tant que mainteneur, il reconnaît ne pas avoir bien géré la réponse à ce rapport de sécurité
    L’usage a explosé, les problèmes se sont accumulés, et il prévoit de rencontrer des experts cette semaine pour lancer un programme de bug bounty et un audit de sécurité

    • Plutôt que de dépenser de l’argent dans un bug bounty ou un audit, il faudrait investir dans la réorganisation de l’organisation et la formation des employés
      Il est plus important que toute l’équipe comprenne et applique le guide OWASP sur l’Insecure Design
    • Au départ, la réaction semblait positive, mais le fait que les personnes ayant signalé la vulnérabilité n’aient reçu aucune réponse malgré plusieurs relances est préoccupant
      Comme OpenCode est un agent de code open source bien connu, il est possible que la faille ait déjà été exploitée
      Il faudrait au minimum exécuter le modèle dans un environnement sandboxé comme gVisor
      Sans réaction rapide, davantage d’attaquants risquent de se mettre à chercher d’autres vulnérabilités RCE
    • Le projet a grandi si vite qu’on semble être arrivé au moment où la gestion de l’organisation devient plus importante que le développement du code
      Certains se demandent s’ils s’inspirent aussi de principes d’organisation anarchistes
    • Sinon, on ne peut pas simplement demander à Claude de corriger les problèmes de sécurité ?
    • Le fait de partager la situation honnêtement et d’assumer ses responsabilités est apprécié. Ce n’est pas facile, merci pour cette transparence

  • Beaucoup de gens exécutent des outils comme OpenCode en local sans séparation des privilèges
    Les plugins aussi sont généralement conçus en partant du principe d’un accès illimité, et la consommation de ressources est élevée
    Le minimum serait de l’exécuter dans un dev-container ou une VM, puis de ne monter que les fichiers nécessaires via SSHFS ou Samba
    Si c’est trop contraignant, un VPS à 5 dollars par mois peut aussi faire l’affaire

    • Certains demandent des explications plus concrètes sur la configuration d’un dev-container ou d’une VM
    • Claude demande une autorisation à chaque exécution, ce qui le rend un peu plus sûr sur ce point
    • Pour le sandboxing IA, sprites.dev de fly.io semble plutôt bon
      Pour lancer un serveur avec qemu, quickemu est recommandé
      La fonction SSH remote de zed est aussi utile pour l’utiliser avec Claude Code ou OpenCode

  • Le correctif CORS a bloqué l’exploitation depuis des sites web externes, mais le vrai problème reste une architecture permettant l’exécution de code sur localhost
    Neovim utilise par défaut des sockets de domaine, et le démon SSH de VS Code comporte une procédure d’authentification
    Un serveur local qui exécute les entrées client sans authentification constitue une vulnérabilité LCE (Local Code Execution),
    et si l’accès devient possible via des requêtes navigateur, cela s’étend en RCE (Remote Code Execution)

  • C’est choquant d’avoir mis dans un outil CLI un endpoint HTTP permettant du RCE sans authentification, puis d’y avoir ajouté en plus un contournement de CORS

    • Les labos d’IA devraient peut-être arrêter d’entraîner leurs modèles sur du code de tutoriels
    • Vu à quel point le serveur était ouvert, ce qui surprend presque, c’est que la politique CORS n’ait pas été *
    • Certains ont réagi en disant que cela ressemblait à du « code fait juste à l’instinct »

  • Le calendrier de divulgation de la vulnérabilité pose problème
    Elle a été signalée le 2025-11-17, sans réponse malgré plusieurs prises de contact

    • Maintenant, les développeurs semblent la prendre sérieusement en main
      Voir ce commentaire sur l’issue GitHub
    • Certains ont aussi plaisanté : « en ce moment tout le monde fait du vibe coding, donc les problèmes de sécurité donnent de mauvaises vibes »

  • Même si le serveur est désactivé par défaut, cela reste grave dès qu’il est activé
    N’importe quelle page web pouvait exécuter du code sur localhost, et même lancer des processus locaux sans authentification
    Rien n’indique clairement à l’utilisateur si le serveur tourne ou non
    Les applications TUI inspirent généralement confiance précisément parce qu’elles ne font pas ce genre de choses, et cette affaire a fortement abîmé cette confiance

    • Certains ont demandé pourquoi le fait que ce soit une application TUI posait particulièrement problème
    • En alternative, Factory Droid a été cité comme une option correcte

  • Le fait qu’OpenCode soit soutenu par YC (Y Combinator) surprend
    On s’attendrait à ce que YC encourage une meilleure culture de la sécurité

    • Certains ont réagi avec cynisme en disant que pour YC, au fond, tout tourne autour de l’argent
    • Un ancien exemple est celui de Flock, également passé par YC, qui avait hardcodé des mots de passe 53 fois
      Voir ce commentaire
    • L’ironie est renforcée par le fait qu’OpenCode développe aussi un produit de fournisseur d’authentification

  • Certains pensaient qu’OpenCode était un projet bénévole, avant de découvrir qu’il s’agit en réalité d’un projet d’entreprise soutenu par de gros investisseurs

    • En plus du dépôt GitHub officiel, il existait aussi un projet concurrent créé par l’équipe de charm.sh
    • Il s’agissait probablement de projets comme crush, roocode ou kilo, qui n’ont pas encore de gros soutiens financiers

  • Certains ont arrêté de l’utiliser parce qu’on continuait à ajouter des fonctionnalités tout en négligeant la maintenance de base
    L’objectif était d’utiliser plusieurs modèles en parallèle, mais le partage de contexte est inefficace, ce qui limite fortement l’intérêt pratique
    Ils utilisent maintenant Claude Code et Codex en parallèle
    Malgré cela, le besoin d’une plateforme ouverte capable d’intégrer plusieurs modèles reste important

    • La combinaison ampcode(lien) et Crush(lien) + z.ai GLM est recommandée
      ampcode permet de créer gratuitement de petits scripts, et Crush+GLM suit bien les plans produits par Claude ou Codex
    • D’autres soulignent qu’il est plus difficile de maintenir la discipline des revues et du contrôle qualité que d’ajouter de nouvelles fonctionnalités

  • Au départ, certains aimaient Aider, mais comme la maintenance est quasiment absente, ils rencontrent souvent des problèmes
    En envisageant d’installer OpenCode, cette affaire les a fait hésiter
    Il est surprenant qu’il existe si peu d’assistants CLI LLM open source non dépendants d’un modèle