Risques de sécurité OpenClaw : deux avis à vérifier dans votre configuration
Vérifiez deux avis officiels OpenClaw, leurs versions concernées et leurs correctifs, puis comparez les accès réellement accordés à un agent Android.
- Deux avis officiels concernent OpenClaw avant la version 2026.8.1, chacun sous des conditions de configuration précises.
- Mettez à jour OpenClaw et ses clients d’exécution associés ; examinez aussi les approbations permanentes et les adresses de vos fournisseurs de modèles.
- L’audit de sécurité OpenClaw aide à relever les accès exposés, mais ses résultats demandent une revue et ne remplacent pas la vérification des correctifs.
- Comparez OpenClaw et FoneClaw selon les outils activés, les autorisations accordées, les demandes d’approbation et les résultats observables.
Vérifier les versions et les configurations concernées
Pour évaluer les risques de sécurité OpenClaw, commencez par la version installée et les fonctions effectivement configurées. Les deux avis ci-dessous concernent les versions antérieures à 2026.8.1 ; cette version est le premier correctif stable indiqué pour chacun. Leur existence ne signifie pas que toutes les installations OpenClaw sont touchées.
| Avis officiel | Versions et conditions concernées | Correctif |
|---|---|---|
| GHSA-3mq7-q27j-mq7q | OpenClaw avant 2026.8.1, avec une approbation permanente déjà accordée à une commande d’exécution. La correspondance portait sur ses arguments sans lier le répertoire de travail. | Mettre à jour OpenClaw et les clients natifs d’exécution associés vers 2026.8.1 ou une version ultérieure. |
| GHSA-vhpg-cq3w-v8p9 | OpenClaw avant 2026.8.1, avec une session épinglée à un fournisseur tiers compatible OpenAI, des métadonnées de modèle sans adresse de base explicite et un rechargement du modèle. | Mettre à jour vers 2026.8.1 ou une version ultérieure et renseigner explicitement l’adresse du fournisseur tiers. |
Dans le premier cas, une personne devait initialement choisir une approbation de type « toujours autoriser ». Le défaut permettait ensuite de réutiliser l’autorisation pour les mêmes arguments dans un autre répertoire de travail, où la commande pouvait toucher d’autres fichiers. En attendant la mise à jour, retirez les approbations permanentes sensibles au répertoire et approuvez chaque commande pour le dossier réellement visé. Il ne s’agit pas d’une exécution arbitraire qui se passerait de la première approbation.
Dans le second cas, la session pouvait conserver la clé API du fournisseur tiers tandis que le logiciel choisissait son adresse par défaut après le rechargement. Le risque portait alors sur l’envoi de cette clé d’authentification vers une destination inattendue. Avant la mise à jour, indiquez une adresse de base explicite pour chaque fournisseur tiers et évitez de poursuivre une session épinglée après un changement des valeurs par défaut du modèle. Si cette situation s’est effectivement produite, révoquez et remplacez la clé API concernée. L’avis ne démontre pas que toutes les clés API des utilisateurs ont été divulguées.
Auditer l’installation après les changements
Relevez la version d’OpenClaw et celle des clients natifs qui exécutent ses commandes, puis vérifiez que les composants concernés ont reçu le correctif. Passez en revue les approbations permanentes, les répertoires accessibles et les adresses configurées pour les fournisseurs de modèles. Une version corrigée traite les défauts décrits dans ces avis ; elle ne réduit pas automatiquement des accès que vous avez volontairement accordés.
La documentation officielle de l’audit de sécurité OpenClaw décrit ces commandes de consultation :
openclaw security audit
openclaw security audit --json
openclaw security audit --deepLa première présente les constats ; --json fournit une sortie structurée et --deep tente aussi de sonder une passerelle OpenClaw active. L’audit examine notamment les règles d’accès, l’exposition des outils et du navigateur, le réseau et l’authentification, les permissions des fichiers et les listes de plugins autorisés. Examinez les interfaces exposées, les personnes admises à envoyer des demandes et les secrets disponibles pour les tâches qui vous intéressent.
La variante --fix modifie certaines règles et permissions de fichiers : lisez les changements proposés avant de l’employer. Son périmètre est limité ; elle ne corrige pas à elle seule une installation obsolète ni tous les risques d’une configuration étendue. Après vos changements, relancez l’audit et consignez les constats restants. Un audit sans alerte ne constitue pas un test d’intrusion.
Comparer les accès réellement accordés
Un agent installé sur un serveur et un agent Android n’accèdent pas nécessairement aux mêmes ressources. Dans les deux cas, le risque dépend de ce qui est activé et autorisé pour une tâche donnée. OpenClaw dispose de moyens de durcissement, notamment des règles d’accès, des approbations et des possibilités d’isolation ; leur configuration compte davantage qu’une étiquette générale.
| Accès à examiner | Installation OpenClaw configurée | FoneClaw sur Android |
|---|---|---|
| Commandes, fichiers et réseau | Vérifier les outils d’exécution autorisés, les dossiers accessibles, les connexions et les secrets utilisables. | Vérifier les actions Android activées, les autorisations du système et la destination du contexte envoyé au modèle. |
| Applications et contenu visible | Vérifier les intégrations et comptes connectés à la tâche. | L’ouverture d’une app change l’écran actif ; une autre action peut lire son contenu d’accessibilité visible. Une capture d’écran relève d’une demande d’image distincte. |
| Actions à effet réel | Examiner les autorisations persistantes et les contrôles propres à chaque outil. | Une création d’événement, par exemple, a un effet externe. Le mode global d’approbation, les réglages par action et les autorisations Android déterminent les contrôles effectifs. |
Chez FoneClaw, l’ouverture d’app, la lecture du contenu visible et la capture d’image sont des capacités distinctes, avec des classifications de risque et des règles d’approbation différentes. Une classification n’est pas une certification de sécurité. Nos routes de modèle personnalisées ou passant par notre infrastructure peuvent traiter du contexte hors de l’appareil. La page Fonctionnalités FoneClaw présente les actions Android disponibles ; pour distinguer leur périmètre des limites d’un environnement isolé, consultez Sandbox d’agent IA et autorisations Android : trois limites à vérifier.
Vérifier un refus et son résultat
Un essai sans conséquence permet de vérifier les réglages avant une tâche importante. Sur le téléphone, notez l’app actuellement au premier plan, puis choisissez comme cible une autre app déjà installée et notez aussi son nom. Demandez à l’agent d’ouvrir cette app cible, mais refusez l’action si une approbation apparaît. Vérifiez que l’app initiale est toujours au premier plan et que la cible ne s’est pas ouverte. Examinez aussi ce qui se passe lorsque l’action est désactivée dans les réglages : la demande doit s’arrêter sans ouverture de l’app cible. Réactivez-la seulement pour une action que vous souhaitez réellement accomplir, puis contrôlez l’app ouverte.
Le même principe s’applique aux outils et approbations d’OpenClaw : vérifiez le refus dans votre configuration avant de confier à l’agent des fichiers ou identifiants sensibles. Une demande d’approbation montre qu’un contrôle existe, mais ne prouve pas à elle seule que la cible ou l’intention sont correctes. Relisez les paramètres de l’action et constatez son résultat. Pour organiser cette vérification autour des identités et des traces, notre guide Identité des agents IA : permissions, approbation par outil et piste d’audit apporte un cadre plus détaillé. Si vous ajoutez des compétences ou des extensions, Sécurité des compétences d’agents IA : pourquoi les permissions sur mobile doivent être vérifiées au moment de l’action traite leur confiance séparément.