Vulnérabilité d’élévation de privilèges dans OpenClaw (CVE-2026-33579)

 (nvd.nist.gov)
3 points par GN⁺ 27 일 전 | 1 commentaires | Partager sur WhatsApp
  • Une vulnérabilité d’élévation de privilèges permettant à des utilisateurs non administrateurs d’approuver des demandes de privilèges administrateur a été découverte dans les versions antérieures à OpenClaw 2026.3.28
  • Dans la commande /pair approve, l’omission de la transmission du scope empêche une vérification correcte de l’approbation, entraînant un problème d’autorisation incorrecte (CWE-863)
  • Cette vulnérabilité est évaluée à 8,6 selon CVSS v4.0 et 8,1 selon CVSS v3.1, soit dans les deux cas une sévérité élevée (HIGH)
  • Le code vulnérable se trouve dans extensions/device-pair/index.ts et src/infra/device-pairing.ts, et le problème a été corrigé dans la version 2026.3.28
  • Les utilisateurs et les administrateurs doivent mettre à jour vers une version corrigée et consulter l’avis de sécurité GitHub (GHSA-hc5h-pmr3-3497)

Aperçu de la vulnérabilité

  • Une vulnérabilité d’élévation de privilèges existe dans les versions d’OpenClaw antérieures à 2026.3.28
    • Sur le chemin de la commande /pair approve, le scope de l’appelant n’est pas transmis, ce qui empêche une vérification correcte de l’approbation
    • Un utilisateur disposant uniquement du droit de pairage peut, même sans privilèges administrateur, approuver des demandes d’appareil incluant un accès administrateur
    • Les emplacements de code vulnérables ont été identifiés dans extensions/device-pair/index.ts et src/infra/device-pairing.ts

Impact et sévérité

  • Score de 8,6 selon CVSS v4.0 (HIGH)

    • Vecteur : AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

  • Score de 8,1 selon CVSS v3.1 (HIGH)

    • Vecteur : AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
    • Classé comme CWE-863 (Incorrect Authorization)
    • En raison d’une vérification incorrecte des autorisations, des utilisateurs non administrateurs peuvent effectuer des opérations de niveau administrateur

Logiciels affectés

  • Parmi les versions Node.js d’OpenClaw, toutes les versions antérieures à 2026.3.28 sont vulnérables
    • Identifiant CPE : cpe:2.3:a:openclaw:openclaw:*:*:*:*:*:node.js:*:*
    • Le problème est corrigé dans les versions ultérieures

Correctif et mesures recommandées

Historique des modifications

  • 2026-03-31 : enregistrement du nouveau CVE et ajout des informations CVSS par VulnCheck
  • 2026-04-01 : analyse initiale et ajout de la configuration CPE par le NIST
  • Principales modifications
    • Correction du vecteur CVSS v3.1
    • Ajout de CWE-863
    • Ajout des liens vers le correctif GitHub et l’avis de sécurité

Source et informations de gestion

  • ID CVE : CVE-2026-33579
  • Organisme de publication : NIST National Vulnerability Database (NVD)
  • Source de l’enregistrement : VulnCheck
  • Date de publication initiale : 31 mars 2026
  • Date de dernière modification : 1 avril 2026

À lire aussi

1 commentaires

 
GN⁺ 27 일 전
Avis Hacker News

  • Je suis le créateur d’OpenClaw
    Ce problème était bien un bug d’élévation de privilèges, mais on n’était pas au niveau de « n’importe quel message Telegram/Discord permet de prendre le contrôle de toutes les instances »
    La cause était un correctif incomplet, et le chemin de commande du plugin /pair approve appelait la fonction d’approbation sans callerScopes, ce qui permettait de contourner le scope ceiling
    Autrement dit, un client qui avait déjà un accès à la gateway pouvait approuver des permissions plus larges via la commande /pair approve latest (par ex. operator.admin)
    Ce n’était pas un problème spécifique à Telegram ou à un fournisseur de messagerie, mais une vulnérabilité dans la logique commune du gestionnaire de commandes des plugins
    Dans le cas de Telegram, la politique DM par défaut bloque les inconnus, donc il était impossible d’obtenir des privilèges admin « avec un seul message »
    Tant qu’on l’utilise comme assistant personnel, le risque réel est très faible, et je suis actuellement en train de renforcer la base de code avec des ingénieurs de Nvidia, ByteDance, Tencent et OpenAI

    • Je me demande s’il serait possible d’expliquer davantage les statistiques de l’OP
      Je voudrais vérifier si l’affirmation « plus de 135k instances OpenClaw sont exposées publiquement, et 63 % d’entre elles tournent sans authentification, donc n’importe qui peut envoyer une demande de pairage » est vraie
      Si c’est exact, cela donne une image du risque complètement différente de celle décrite par l’auteur
    • Je me demande ce que signifie concrètement « travailler avec Nvidia, ByteDance, Tencent, OpenAI »
      Est-ce qu’il y a des contrats avec ces entreprises, ou bien s’agit-il simplement d’employés de ces sociétés qui ont contribué à l’open source ?
    • « Nvidia, ByteDance, Tencent, OpenAI ? Waouh ! »
      Surprise de voir de si grandes entreprises impliquées
    • Réaction mi-sérieuse mi-blague : « Le code n’est pas déjà un problème résolu ? »
      Avec en plus une satire de l’IA du style : « il suffit de demander à Claude Code de “renforcer la sécurité”, non ? »

  • Partage du lien days-since-openclaw-cve.com
    Le site affirme qu’en moyenne 1,8 CVE par jour sont signalées depuis la sortie d’OpenClaw

    • Ce chiffre paraît vraiment terrible
      Bien sûr, un projet très médiatisé comme OpenClaw peut voir davantage de vulnérabilités découvertes, mais « 1,8 par jour », intuitivement, c’est énorme
      Cela amène à se demander si une personne raisonnable ne devrait pas tout simplement éviter ce logiciel

  • Partage d’un lien vers une copie archivée d’un post Reddit original supprimé

    • Il a probablement été supprimé parce qu’il a été considéré comme du spam IA
      Les autres publications de l’auteur étaient elles aussi des promotions de projets IA
    • Mentionne qu’il va « ajouter ce lien au texte en haut »

  • Je n’utilise pas OpenClaw, mais je lance Claude Code et Codex dans un compte utilisateur macOS limité
    Via un script become-agent [cmd ...], je les exécute avec sudo dans ce compte restreint pour qu’ils ne puissent pas accéder à mes variables d’environnement ni à mes répertoires
    C’est moins complexe qu’un sandbox-exec complet tout en restant sûr
    Les systèmes Unix sont à l’origine très solides pour ce type de séparation multi-utilisateur

    • À mon avis, le sandboxing au niveau du noyau est important
      J’utilise un outil appelé greywall pour isoler le système de fichiers et le réseau au niveau des syscalls (basé sur Landlock + Seccomp + eBPF)
      En revanche, je ne suis pas d’accord avec l’idée que « Unix n’a pas été conçu pour exécuter ce genre d’agents »
    • Avec l’outil open source de conteneurs d’Apple, on peut démarrer une VM Linux en moins de 100 ms sans privilèges root
      Et avec l’Apple Virtualization Framework, on peut aussi lancer des VM macOS avec un Apple ID distinct

  • Je suis surpris que des gens utilisent encore OpenClaw
    Je pensais que tout le monde était déjà passé à Nanoclaw ou Nemoclaw ; je me demande si c’est juste par simple inertie

    • J’utilise Hermes
      Quel que soit l’agent, il doit tourner dans une sandbox
      Lien GitHub de Hermes
    • NemoClaw n’est qu’un wrapper de sécurité pour OpenClaw, pas un remplaçant
    • Quelqu’un dit franchement : « OpenClaw n’est pas terrible, mais la plupart des gens ne le savent pas »

  • Je pense que c’est un résultat prévisible
    Il est stupide que des personnes sans connaissances en sécurité exposent leurs instances, mais en même temps c’est formidable que n’importe qui puisse faire des expériences IT intéressantes
    Au fond, c’est une question d’équilibre entre liberté et risque — comme réparer soi-même sa voiture : c’est amusant, mais si on se trompe on peut provoquer un gros accident
    En ce moment, sécurité, vie privée et climat sont tous en recul, mais les humains continuent à privilégier le désir de « construire des choses cool »

    • Le problème, c’est que beaucoup de gens ne perçoivent même pas ces risques
    • Comme dans « l’exemple de la voiture », une mauvaise configuration peut aussi nuire aux autres
      Un utilisateur sans connaissances en sécurité peut mettre Internet tout entier en danger
      Au final, c’est toute la société qui paie le prix des expérimentations irresponsables

  • L’auteur a l’impression que les réactions dans le fil /r/sysadmin ressemblent exactement aux conversations typiques d’administrateurs système qu’il a toujours connues

  • Le titre semble un peu putaclic et exagéré
    En réalité, le danger n’existe que si OpenClaw tourne sur un serveur exposé publiquement
    Si 135 000 instances publiques sur 500 000 sont concernées, proportionnellement ce n’est pas si énorme

    • « Un cinquième, quand on parle de sécurité, c’est déjà “pas mal” »
    • « Au-delà de 25 %, on peut largement dire “probablement oui” », ajoute quelqu’un
    • Le chiffre de « 135k instances » paraît peu fiable
    • Un commentaire exprime son scepticisme en plaisantant : « la statistique des 35 % est inventée »
    • Malgré tout, si 65 % tournent sans authentification, cela reste dangereux
      Même si le titre est exagéré, s’il renforce la vigilance en matière de sécurité, cela a quand même de la valeur

  • Quelqu’un dit que « le danger n’existe que lorsque l’instance OpenClaw est exposée sur Internet »

    • Mais il est signalé que, jusqu’à récemment, la configuration par défaut bindait sur 0.0.0.0
      Si un utilisateur pense que son routeur va le protéger, il ne devrait pas utiliser OpenClaw
      Des liens vers l’issue et le commit concernés sont partagés

  • Quelqu’un affirme que « par défaut, ce n’est pas une configuration qui expose des privilèges administrateur à Internet »