Nouvelles fonctionnalités de l'IA/du fournisseur qui modifient également les hypothèses de sécurité.

La même version ajoute ou étend le support pour :

• Prise en charge du fournisseur Kilo Gateway et routage du modèle par défaut (y compris les références à Claude Opus 4.6)
• Normalisation de la sténographie du modèle Vercel AI Gateway
• Soutien au Moonshot/Kimi pour recherche_web et les flux des fournisseurs de vidéo
• Remplacement des paramètres par agent et réglage du comportement du cache
• Nettoyage de session et contrôle du budget disque

Il s'agit là de fonctionnalités utiles et productives. Elles élargissent également la surface de configuration et le nombre de points d'intégration où les informations d'identification, les règles de routage, les journaux et les résultats des outils doivent être gérés. Dans les systèmes d'agents, la "surface de fonctionnalité" et la "surface d'attaque" croissent souvent ensemble. (GitHub)

Pourquoi la modification du système HSTS est une bonne chose, mais pas suffisante en soi

L'ajout d'un support HSTS optionnel est une étape de durcissement bienvenue. L'ajout de la prise en charge optionnelle de HSTS est une étape de durcissement bienvenue. Strict-Transport-Sécurité indique aux navigateurs d'utiliser HTTPS pour les futures requêtes adressées à un hôte, réduisant ainsi l'exposition au downgrade/MITM après l'apprentissage de la politique. La référence du MDN est très claire sur ce comportement. (MDN Web Docs)

Cela dit, les équipes chargées de la sécurité ne doivent pas en déduire que le risque de transport est résolu.

Ce que le système HSTS permet de faire

• Réduit le risque de déclassement du protocole pour les clients du navigateur après la mise en cache de la politique.
• Permet d'imposer un comportement HTTPS uniquement pour les demandes ultérieures.
• Alignement sur les valeurs par défaut sécurisées pour les déploiements de passerelles HTTPS directes

Ce que HSTS ne résout pas

• C'est le cas pas assainir les sorties d'outils non sûres
• C'est le cas pas Correction de l'authentification faible sur les plugins/webhooks
• C'est le cas pas empêcher l'utilisation abusive du SSRF ou du réseau interne
• C'est le cas pas atténuer l'injection rapide dans le contenu des compétences ou le contenu du site web
• C'est le cas pas arrêt des fuites de secrets via les logs/config snapshots/telemetry

C'est le problème récurrent de la sécurité des agents d'IA : un contrôle de sécurité web valide et utile peut être mis en œuvre correctement, alors que les voies les plus risquées se trouvent ailleurs (invocation d'outils, authentification de plugins, écosystèmes de compétences, réutilisation de la mémoire/du journal, ou actions réseau pilotées par l'agent).

Les CVE dont les ingénieurs en sécurité doivent encore se préoccuper lors de l'évaluation de cette version

Même si la version 2026.2.23 n'est pas en soi une "CVE bundle release", les défenseurs devraient l'interpréter dans le contexte des récentes vulnérabilités d'OpenClaw et de la trajectoire de renforcement plus large qui s'est accélérée en février 2026.

Vous trouverez ci-dessous les CVE récents les plus pertinents, documentés publiquement dans la base de données NVD et largement discutés dans les discussions sur la sécurité au sein d'OpenClaw.

CVE-2026-26322 et la passerelle gatewayUrl problème de confiance

La NVD décrit CVE-2026-26322 comme un problème (antérieur à OpenClaw 2026.2.14) où l'outil Gateway acceptait un gatewayUrl sans restrictions suffisantes, ce qui permet à l'hôte OpenClaw de tenter d'établir des connexions WebSocket sortantes avec des cibles spécifiées par l'utilisateur dans certaines conditions d'invocation de l'outil. (NVD)

Il ne s'agit pas simplement d'un "autre bogue SSRF" au sens traditionnel d'une application web. Dans une plateforme d'agents, un chemin de connexion sortant compatible avec WebSocket peut devenir une primitive du plan de contrôle adjacente à l'exécution, en fonction des services en aval qui font confiance et de la manière dont l'agent/le moteur d'exécution utilise les données renvoyées.

Pourquoi cela est-il plus important pour les agents d'intelligence artificielle que pour les applications web ordinaires ?

Dans une application web standard, le SSRF menace généralement :

• points de terminaison des métadonnées
• API internes
• consoles d'administration
• points d'extrémité pour la découverte des services

Dans l'exécution d'un agent d'intelligence artificielle, un comportement de type SSRF peut également se manifester :

• les outils sur lesquels l'agent s'appuie
• fournisseur/passerelle chemins d'acheminement
• sources de données résumées ultérieurement par l'agent
• les services internes dont les réponses deviennent instructions ou contexte

L'OWASP fournit toujours les bonnes orientations fondamentales en matière de SSRF (listes d'autorisations, contrôles du réseau, validation, segmentation), mais l'aspect spécifique à l'IA est que les sens sémantique du contenu récupéré est également important, et pas seulement la destination du réseau. (Série d'aide-mémoire de l'OWASP)

CVE-2026-26319 et pourquoi l'authentification optionnelle des plugins n'est jamais "optionnelle" en production

La NVD décrit CVE-2026-26319 comme l'absence d'authentification du webhook dans l'option @openclaw/voice-call Gestionnaire de webhook Telnyx lorsque telnyx.publicKey n'est pas configuré, ce qui permet d'activer les événements Telnyx forgés dans les versions concernées (2026.2.13 et ci-dessous). (NVD)

Ce type de problème est fréquent dans les écosystèmes en évolution rapide : un plugin prend en charge la vérification sécurisée, mais la réalité du déploiement dérive vers un "mode de test temporaire" et y reste.

Ce que les équipes de sécurité devraient apprendre de cette CVE

Si une fonctionnalité dépend d'une clé de vérification pour l'authenticité (ici, les signatures Telnyx Ed25519), les systèmes de production doivent appliquer une posture de fermeture en cas d'échec :

• si la configuration de vérification est manquante, rejeter les demandes
• si l'extrémité est exposée, supposer que du trafic non sollicité arrivera
• si les événements webhook peuvent déclencher des flux de travail, les traiter comme des données privilégiées

Dans un environnement d'agents, les faux événements sont particulièrement dangereux car ils ne se contentent pas de "créer de mauvais enregistrements" - ils peuvent déclencher des flux de travail, des appels d'outils ou des actions de suivi.

CVE-2026-26323 montre que la chaîne d'approvisionnement n'est pas seulement constituée de dépendances, mais aussi d'outils de maintenance et de chemins d'accès à l'information.

La NVD décrit CVE-2026-26323 comme un problème d'injection de commande dans le script du mainteneur/développeur scripts/update-clawtributors.ts les versions concernées 2026.1.8 à travers 2026.2.13avec un risque pour les contributeurs/mainteneurs/CI qui exécutent le script sur une sortie contenant des métadonnées de livraison malveillantes. (NVD)

Il s'agit d'un bon rappel que les examens de sécurité modernes devraient inclure :

• l'outillage des contributeurs
• scripts de libération
• Scripts d'aide à l'IC
• "automatisation des développeurs "internes seulement

Pourquoi ? Parce que les scripts internes peuvent devenir proches de la production s'ils modifient les artefacts de publication, publient des paquets ou écrivent des métadonnées consommées par les utilisateurs.

Cela est d'autant plus important dans les projets ayant de grandes communautés et une cadence de publication rapide. La page de publication de GitHub montre qu'OpenClaw est passé rapidement d'une version à l'autre fin février 2026 (y compris 2026.2.22, 2026.2.23 et 2026.2.24 en succession rapprochée). Une cadence rapide est bénéfique pour l'envoi de correctifs, mais elle accroît également l'importance de l'ingénierie des versions renforcées. (GitHub)

CVE-2026-26326 et la version de l'ère de l'agent de "debug output leaked secrets".

La NVD décrit CVE-2026-26326 comme une question de divulgation d'informations lorsque compétences.statut pourrait exposer les valeurs de configuration brutes résolues dans les vérifications d'exigences aux opérateur.lire clients avant la version 2026.2.14y compris les chemins liés aux exigences de configuration des compétences. La correction ne renvoie plus les valeurs brutes résolues et réduit la portée d'une exigence liée à la discorde. (NVD)

C'est exactement le genre de bogue qui est sous-estimé dans les systèmes d'agents.

Dans les systèmes traditionnels, une "fuite d'état" est déjà grave. Dans les systèmes d'agents d'IA, la situation peut être pire car :

• les secrets peuvent débloquer plusieurs systèmes SaaS (courrier, chat, nuage, fournisseurs de modèles)
• les valeurs fuitées peuvent être copiées dans les journaux, les tickets ou les conversations AI
• les rôles en "lecture seule" peuvent être suffisants pour l'exfiltration et le pivotement

Les améliorations de la rédaction de 2026.2.23 en config.get doivent être lus dans ce même contexte : l'écosystème apprend (à juste titre) que les fonctions d'introspection et de débogage nécessitent une hygiène secrète plus stricte. (GitHub)

La menace dans son ensemble : la publication a lieu au milieu d'un test de résistance de la sécurité de l'écosystème.

La raison pour laquelle cette version est importante n'est pas seulement ce qui a changé dans la base de code. C'est qu'OpenClaw est désormais soumis à de fortes pressions adverses dans le monde réel, et ce à plusieurs niveaux.

Les compétences malveillantes et les abus de marché constituent désormais un risque courant.

Le site Hacker News a fait état des résultats de 341 compétences malicieuses ClawHub L'article décrit des campagnes qui utilisent de faux prérequis et l'ingénierie sociale pour diffuser des logiciels malveillants ou des voleurs, y compris des comportements liés à macOS AMOS et des thèmes liés au vol d'informations d'identification. L'article souligne également le modèle de marché ouvert d'OpenClaw et l'ajout ultérieur d'une option de rapport / de seuils de masquage automatique. (The Hacker News)

Cela est important car de nombreux utilisateurs considèrent encore mentalement les "compétences" comme quelque chose de plus proche des modèles ou des invites, alors qu'en pratique, elles peuvent fonctionner comme des artefacts adjacents à l'exécution qui influencent les utilisateurs et les agents pour qu'ils exécutent des commandes.

L'exposition à l'échelle de l'internet modifie l'urgence des correctifs

Des rapports récents ont également mis en évidence des dizaines de milliers d'instances OpenClaw exposées (le résumé des résultats de la recherche cite les conclusions de SecurityScorecard et plus de 40 000 déploiements exposés). Même si les chiffres exacts varient en fonction de la fenêtre de balayage et de la méthode de prise d'empreinte, la conclusion opérationnelle est la même : une fois qu'une plateforme est exposée à l'internet à cette échelle, les faiblesses de configuration et les CVE connus deviennent des opportunités d'exploitation de masse. (Magazine Infosecurity)

L'injection rapide reste la condition de base

La récente couverture par Verge des incidents d'injection rapide liés à OpenClaw/Cline est un autre signe que la sécurité des agents d'intelligence artificielle ne peut pas être réduite à des CVE. L'injection d'invites et les défaillances au niveau de la limite entre les instructions et les données restent un risque opérationnel réel dans tout flux de travail où les agents consomment du contenu externe et peuvent exécuter des actions. (The Verge)

Ce que les équipes de sécurité doivent faire après la mise à jour vers la version 2026.2.23

La bonne réponse à cette version n'est pas "mettez à jour et passez à autre chose". C'est "mettre à jour, puis vérifier les nouvelles conditions limites".

Voici une liste de contrôle pratique qui correspond à la version et à l'environnement actuel des menaces.

Mise à niveau, puis vérification explicite des hypothèses de version et d'édition

Utiliser un processus de validation des rejets qui enregistre :

• version installée d'OpenClaw
• compétences/plugins activés
• les interfaces exposées (interface utilisateur, API, passerelle, points de terminaison des webhooks)
• les informations d'identification du fournisseur sont configurées
• proxy/tunnel/chemins d'exposition publics
• configuration du proxy inverse et des en-têtes

Ne croyez pas qu'un changement de version corrige automatiquement les problèmes de déploiement :

• vous faites marcher les fourches
• vous conservez les anciennes clés de configuration
• vous exposez des plugins optionnels
• vous passez par des serveurs mandataires personnalisés
• vous épinglez des conteneurs/images plus anciens

Traiter HSTS comme une étape de durcissement du transport, et non comme un programme de sécurité

Si vous déployez le protocole HTTPS directement auprès des utilisateurs finaux, l'activation de l'option Strict-Transport-Sécurité est une bonne chose. Mais validez votre chemin de déploiement :

• HTTPS se termine là où vous pensez qu'il se termine
• aucune régression de contenu mixte ne perturbe l'interface utilisateur
• les domaines de mise en scène/de test ne sont pas accidentellement préchargés par HSTS d'une manière qui nuit aux opérations
• votre proxy inverse et la passerelle OpenClaw ne dupliquent pas les en-têtes.

Un exemple minimal de Nginx (à adapter à votre environnement) :

serveur {
    listen 443 ssl http2 ;
    nom_du_serveur openclaw.example.com ;

    ssl_certificate /etc/letsencrypt/live/openclaw.example.com/fullchain.pem ;
    ssl_certificate_key /etc/letsencrypt/live/enclaw.example.com/privkey.pem ;

    # HSTS : à utiliser avec précaution lors du déploiement ; commencer plus bas si nécessaire
    add_header Strict-Transport-Security "max-age=31536000 ; includeSubDomains" always ;

    location / {
        proxy_pass ;
        proxy_set_header Host $host ;
        proxy_set_header X-Forwarded-Proto https ;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for ;
    }
}

Pourquoi cette prudence ? Parce que HSTS améliore le comportement du navigateur en matière de transport, mais ne compense pas les problèmes de confiance au niveau de la couche applicative. La description de MDN est claire : il influence les futures requêtes du navigateur vers l'hôte. (MDN Web Docs)

Ré-audit de toute fonctionnalité de plugin/webhook qui peut fonctionner en "mode commodité".

CVE-2026-26319 est un parfait rappel à ce sujet. Si votre déploiement inclut des webhooks, des intégrations vocales, des connecteurs de robots ou des actions pilotées par des événements :

• exiger la vérification de la signature
• rejeter les événements non signés/invalides
• enregistrer les échecs d'authentification avec des limites de débit
• isoler les auditeurs de webhook des réseaux internes privilégiés
• examiner si le point d'accès doit être public ou non

Un modèle générique de vérification d'un webhook (pseudocode) ressemble à ceci :

def handle_webhook(request) :
    signature = request.headers.get("X-Signature-Ed25519")
    timestamp = request.headers.get("X-Timestamp")

    si pas la signature ou pas l'horodatage :
        return {"error" : "missing signature headers"}, 401

    if not verify_signature(public_key=TELNYX_PUBLIC_KEY, request=request) :
        return {"error" : "signature non valide"}, 401

    event = parse_json(request.body)

    # Facultatif : protection contre le rejeu
    si is_replay(event, timestamp) :
        return {"error" : "replay detected"}, 409

    # Mise en file d'attente d'un événement minimal pour traitement en aval
    enqueue_event(event)
    return {"status" : "ok"}, 202

L'essentiel est d'ordre architectural : s'authentifier avant d'analyser/utiliser/déclencher.

Verrouiller le SSRF et la joignabilité du réseau pilotée par l'agent à l'aide de contrôles en couches

Les notes de version d'OpenClaw mentionnent explicitement un changement de politique SSRF par défaut dans la version 2026.2.23. Cela devrait entraîner une révision de la politique, et pas seulement une migration de la configuration. (GitHub)

L'aide-mémoire SSRF de l'OWASP reste une base solide pour la validation de la destination et la segmentation du réseau. Dans les déploiements d'agents, il convient d'ajouter des contrôles spécifiques à l'IA (Série d'aide-mémoire de l'OWASP)

Couches de contrôle recommandées

Une esquisse de politique pratique d'autorisation/refus

politique_réseau :
  default_outbound : deny
  allow_dns : true
  allow_https :
    - api.anthropic.com
    - *.openrouter.ai
    - api.openai.com
    - votre-approved-saas.exemple
  deny_cidrs :
    - 127.0.0.0/8
    - 10.0.0.0/8
    - 172.16.0.0/12
    - 192.168.0.0/16
    - 169.254.0.0/16 # metadata/link-local
  websocket :
    allowlist_only : true

Même si la surface de configuration exacte d'OpenClaw diffère, il s'agit du bon modèle mental.

Traiter les "compétences" comme un code et non comme un contenu

Les incidents de ClawHub sont un avertissement pour toutes les équipes qui laissent les utilisateurs installer des compétences OpenClaw tierces. Le rapport de THN décrit des compétences malveillantes qui se font passer pour des outils utiles tout en utilisant de fausses conditions préalables et l'ingénierie sociale pour amener les utilisateurs à exécuter des commandes qui récupèrent des logiciels malveillants. (The Hacker News)

Cela signifie que votre processus d'examen doit couvrir les deux :

• ce que fait la compétence
• ce que la compétence demande à l'utilisateur de faire

Politique de gouvernance des compétences minimales pour les déploiements sérieux

• désactiver les installations de places de marché publiques par défaut sur les déploiements gérés
• tenir une liste interne des compétences examinées
• exiger un examen du code et des vérifications de la provenance
• bannir les compétences qui demandent aux utilisateurs d'exécuter manuellement des commandes shell pendant l'installation
• bac à sable ou conteneurisation des chemins d'exécution des outils à risque
• séparer les agents de test des agents de production
• surveiller les connexions sortantes après l'installation de nouvelles compétences
• changer les informations d'identification après une activité suspecte de la part de l'utilisateur

Si votre modèle de sécurité traite toujours les SKILL.md comme de la "simple documentation", vous êtes derrière le modèle de la menace.

Empêcher les fuites de secrets dans les journaux, les vues d'état et la télémétrie

Les récentes CVE d'OpenClaw et les améliorations apportées à la rédaction du document 2026.2.23 vont toutes deux dans le même sens : l'introspection et l'observabilité sont puissantes, mais dangereuses en l'absence d'une minimisation stricte des données et d'une rédaction. (NVD)

Les orientations officielles d'OpenTelemetry sont utiles à cet égard : elles indiquent explicitement qu'il incombe aux utilisateurs de comprendre ce qui est sensible dans leur contexte et de le protéger, et recommandent la minimisation des données ainsi que des processeurs capables de supprimer, de filtrer, d'expurger ou de transformer les champs sensibles. (OpenTelemetry)

Ce qu'il faut expurger par défaut dans un environnement OpenClaw

• Clés API (fournisseurs de modèles, plateformes d'automatisation, SaaS)
• secrets de webhook et clés de vérification de signature
• Jetons d'accès/de rafraîchissement OAuth
• jetons de session et cookies
• identifiants du connecteur de chat/mail
• Clés SSH et identifiants cloud
• les identifiants des utilisateurs ne sont pas nécessaires pour l'observabilité
• inviter du contenu qui peut inclure des données professionnelles privées

Exemple d'approche de rédaction du collecteur OpenTelemetry (à titre d'illustration)

processeurs :
  attributes/redact_sensitive :
    actions :
      - key : api.key
        action : delete
      - key : authorization
        action : delete
      - clé : user.email
        action : hash
      - clé : session.token
        action : delete

  transform/scrub_patterns :
    error_mode : ignore
    log_statements :
      - context : log
        statements :
          - replace_pattern(body, "(?i)bearer\\\\s+[A-Za-z0-9\\\\-\\\\._~\\\\+\\\\/]+=*", "Bearer [REDACTED]")
          - replace_pattern(body, "(?i)(api[_-]?key\\\\s*[:=]\\\\s*)[^\\\\s,;]+", "$1[REDACTED]")

service :
  pipelines :
    logs :
      processeurs : [attributes/redact_sensitive, transform/scrub_patterns]

Aucun modèle de rédaction n'est suffisant, mais "tout collecter et nettoyer plus tard" n'est pas une valeur sûre par défaut pour les systèmes d'agents.

Revoir les interfaces utilisateur et les surfaces d'administration à la recherche de XSS et d'hypothèses de rendu peu sûres.

Même si la version actuelle ne fait pas la une des journaux à cause de XSS, les déploiements d'OpenClaw comprennent souvent des panneaux d'administration, des journaux, des vues de métadonnées de compétences et des historiques de messages qui peuvent finir par rendre un contenu contrôlé par l'attaquant.

L'aide-mémoire de l'OWASP sur la prévention des XSS reste le bon point de référence : utiliser correctement les protections du cadre, éviter les API de rendu non sûres et appliquer le codage/sanitisation de la sortie en fonction du contexte. L'aide-mémoire mentionne explicitement les échappatoires les plus courantes des frameworks (y compris l'API de React dangereusementSetInnerHTML) et pourquoi aucune technique ne résout à elle seule le problème des XSS. (Série d'aide-mémoire de l'OWASP)

Ceci est particulièrement important pour les outils d'IA car :

• les journaux et les transcriptions peuvent contenir des chaînes de caractères contradictoires
• les descriptions des compétences sont fournies par l'utilisateur
• les résultats de la recherche sur le web peuvent être affichés et résumés
• les administrateurs font souvent trop confiance aux "tableaux de bord internes".

La vraie leçon de 2026.2.23 : la sécurité d'OpenClaw est désormais un problème de système

Si vous considérez la version 2026.2.23 uniquement comme une mise à jour du produit, vous ne verrez pas le changement le plus important.

Ce communiqué présente un projet qui est :

• l'expédition d'améliorations significatives en matière de durcissement,
• étendre rapidement les capacités des modèles/fournisseurs,
• et réagir à un écosystème d'attaquants qui évolue rapidement.

Cette combinaison est précisément la raison pour laquelle les défenseurs ont besoin d'une vision systémique.

La limite de sécurité a été déplacée

L'ancienne frontière était approximativement :

• serveur d'application
• base de données
• navigateur

La nouvelle frontière d'OpenClaw est plus proche de :

• autorisations locales d'exécution et du système d'exploitation
• cadre d'invocation d'outils
• fournisseur/route passerelle
• plugins/webhooks/connecteurs
• marché des compétences contenu + ingénierie sociale
• logs/memory/transcripts réutilisés comme contexte de l'agent
• sortie du navigateur/réseau des flux de travail contrôlés par l'agent

Une version comme la 2026.2.23 améliore certaines parties de cette frontière. Elle ne la réduit pas à un objet unique pouvant faire l'objet de correctifs.

Les erreurs courantes que les équipes commettent après avoir lu l'annonce de publication

Quelques erreurs prévisibles méritent d'être signalées car elles créent une fausse confiance.

Erreur 1 : "Des en-têtes de sécurité ont été ajoutés, la passerelle est donc sécurisée".

HSTS est utile. Il ne remplace pas l'authentification, les contrôles SSRF, le renforcement des plugins ou l'hygiène des secrets. (GitHub)

Erreur 2 : "Nous sommes sur une version plus récente, donc les CVE de février n'ont plus d'importance".

Ils sont toujours importants parce qu'ils révèlent des modèles de conception et d'échec opérationnel que vous pouvez reproduire ailleurs (webhooks, vues d'état, routage d'outils, automatisation des mainteneurs). (NVD)

Erreur 3 : "Nous n'installons pas de compétences douteuses, le risque ClawHub ne s'applique donc pas à nous".

Si les utilisateurs peuvent s'installer à partir d'une place de marché publique, ou si les équipes copient/collent des commandes d'installation à partir de documents tiers, vous êtes toujours exposé à la même catégorie de risque. La couverture de THN montre que le modèle d'attaque s'appuie fortement sur l'ingénierie sociale par le biais de "prérequis", et pas seulement sur l'exécution pure de code à l'intérieur du paquet de compétences. (The Hacker News)

Erreur 4 : "La télémétrie aide à répondre aux incidents, il faut donc tout collecter".

Le fait de tout collecter sans rédiger ni minimiser les données crée une autre surface de violation. Les orientations d'OpenTelemetry placent explicitement la responsabilité de la classification et de la protection des données sensibles sur les épaules de ceux qui les mettent en œuvre. (OpenTelemetry)

Dernière prise de position

OpenClaw 2026.2.23 est une version significative. Elle améliore la posture de sécurité de plusieurs manières réelles, y compris les options de renforcement du transport, le comportement de rédaction de la configuration et les corrections liées aux fuites de raisonnement, tout en ajoutant des capacités de flux de travail utiles pour les fournisseurs et l'IA. (GitHub)

Mais le communiqué doit être lu dans son contexte :

• Les récentes CVE d'OpenClaw révèlent des problèmes récurrents en matière de confiance dans les passerelles, d'authentification des webhooks, d'outils de maintenance et de chemins de divulgation de secrets (NVD)
• des rapports récents montrent que l'écosystème est déjà soumis à une pression active par le biais de compétences malveillantes et de déploiements exposés, (The Hacker News)
• et le défi principal de la sécurité de l'IA-agent reste architectural : la frontière entre le contenu, l'instruction, la configuration et l'action est plus mince que ce à quoi la plupart des équipes sont habituées.

Si vous utilisez OpenClaw en production ou en semi-production, l'étape suivante ne consiste pas simplement à appliquer des correctifs. Il s'agit de vérifier le comportement post-mise à niveau de votre déploiement spécifique-L'accessibilité au réseau, l'authentification, la rédaction, la gouvernance des compétences et les flux de travail des opérateurs sont inclus.

C'est la différence entre "actualisé" et "durci".

Liens

• Manifeste de sécurité d'OpenClaw Sovereign AI : Un post-mortem complet et un guide de renforcement architectural pour OpenClaw AI (2026) (Penligent)
• Les personnes qui donnent à OpenClaw un accès racine à leur vie entière (Penligent)
• Plusieurs groupes de pirates exploitent des instances d'OpenClaw pour voler des clés d'API et déployer des logiciels malveillants (Penligent)
• Vulnérabilité de l'IA d'OpenClaw : Un guide étape par étape pour le RCE zéro-clic et l'injection indirecte (Penligent)
• Quand SKILL.md devient un installateur : Le manuel d'empoisonnement ClawHub d'OpenClaw (Penligent)
• Vulnérabilité OpenClaw "Log Poisoning" : Injection indirecte d'invites via les en-têtes WebSocket (corrigée dans 2026.2.13) (Penligent)
• Version GitHub d'OpenClaw v2026.2.23 (notes de version officielles) (GitHub)
• Page GitHub des versions d'OpenClaw (cadence des versions et chronologie des versions) (GitHub)
• NVD : CVE-2026-26322 (Passerelle gatewayUrl / (problème de cible WebSocket sortante) (NVD)
• NVD : CVE-2026-26319 (Problème de vérification de la signature du webhook Telnyx) (NVD)
• NVD : CVE-2026-26323 (injection de commande du script maintainer/dev) (NVD)
• NVD : CVE-2026-26326 (compétences.statut divulgation secrète) (NVD)
• Aide-mémoire de l'OWASP sur la prévention du SSRF (Série d'aide-mémoire de l'OWASP)
• Aide-mémoire de l'OWASP sur la prévention des XSS (Série d'aide-mémoire de l'OWASP)
• MDN Strict-Transport-Sécurité référence de l'en-tête (MDN Web Docs)
• OpenTelemetry : Traitement des données sensibles (guide officiel) (OpenTelemetry)