Vulnerabilidades

OpenClaw anterior a 2026.3.11 contiene una vulnerabilidad de omisión de lista de permitidos de ejecución donde matchesExecAllowlistPattern normaliza incorrectamente patrones con minúsculas y coincidencia de glob que coincide en exceso en rutas POSIX. Los atacantes pueden explotar la coincidencia del comodín ? a través de segmentos de ruta para ejecutar comandos o rutas no previstos por los operadores.

OpenClaw anterior a 2026.3.12 contiene una vulnerabilidad de omisión de autenticación en el modo de webhook de Feishu cuando solo se configura verificationToken sin encryptKey, lo que permite la aceptación de eventos falsificados. Atacantes de red no autenticados pueden inyectar eventos falsificados de Feishu y desencadenar la ejecución de herramientas posteriores al alcanzar el punto final del webhook.

OpenClaw anterior a 2026.3.12 contiene una vulnerabilidad de autorización débil en el modo de lista de permitidos de Zalouser que coincide con nombres de visualización de grupos mutables en lugar de identificadores de grupo estables. Los atacantes pueden crear grupos con nombres idénticos a los grupos en la lista de permitidos para eludir la autorización del canal y redirigir mensajes de grupos no deseados al agente.

OpenClaw anterior a 2026.3.11 contiene una vulnerabilidad de integridad de aprobación donde las aprobaciones de system.run no logran vincular operandos de archivo mutables para ciertos ejecutores de scripts como tsx y jiti. Los atacantes pueden obtener aprobación para comandos de script benignos, reescribir scripts referenciados en disco y ejecutar código modificado bajo el contexto de ejecución aprobado.

OpenClaw anterior a 2026.3.11 contiene una vulnerabilidad de escape de sandbox de sesión en la herramienta session_status que permite a los subagentes en sandbox acceder al estado de sesión padre o hermano. Los atacantes pueden proporcionar valores arbitrarios de sessionKey para leer o modificar datos de sesión fuera de su ámbito de sandbox, incluyendo anulaciones de modelo persistidas.

OpenClaw anterior a 2026.3.11 contiene una vulnerabilidad de omisión de autorización que permite a los llamantes con alcance de escritura acceder a la lógica de restablecimiento de sesión solo para administradores. Los atacantes con alcance operator.write pueden emitir solicitudes de agente que contengan los comandos de barra inclinada /new o /reset para restablecer el estado de conversación objetivo sin poseer privilegios operator.admin.

OpenClaw anterior a 2026.3.11 contiene una vulnerabilidad de escalada de privilegios en device.token.rotate que permite a los llamadores con alcance operator.pairing acuñar tokens con alcances más amplios al no restringir los alcances recién acuñados al conjunto de alcances actual del llamador. Los atacantes pueden obtener tokens operator.admin para dispositivos emparejados y lograr ejecución remota de código en nodos conectados a través de system.run u obtener acceso no autorizado de gateway-admin.

OpenClaw anterior a 2026.3.11 contiene una vulnerabilidad de omisión de autorización en la ingesta de reacciones de gremios de Discord que no aplica las comprobaciones de lista blanca de usuarios y roles de miembros. Los miembros del gremio no incluidos en la lista blanca pueden desencadenar eventos de reacción aceptados como eventos de sistema de confianza, inyectando texto de reacción en el contexto de sesión posterior.

OpenClaw anterior a 2026.3.12 contiene una vulnerabilidad de omisión de autorización donde los eventos de reacción de Feishu con chat_type omitido se clasifican erróneamente como conversaciones p2p en lugar de chats de grupo. Los atacantes pueden explotar esta clasificación errónea para omitir las protecciones groupAllowFrom y requireMention en eventos derivados de reacciones de chats de grupo.

OpenClaw anterior a 2026.3.12 contiene una vulnerabilidad de control de acceso insuficiente en los manejadores de comandos /config y /debug que permite a no propietarios con autorización de comandos acceder a superficies solo para propietarios. Atacantes con autorización de comandos pueden leer o modificar configuraciones privilegiadas restringidas a los propietarios al explotar la falta de comprobaciones de permisos a nivel de propietario.

OpenClaw anterior a 2026.3.11 contiene una vulnerabilidad de bypass de límite de sandbox que permite a los subagentes hoja acceder a la superficie de control de los subagentes y resolver contra el alcance del solicitante padre en lugar de su propio árbol de sesión. Un trabajador hoja en sandbox con bajos privilegios puede dirigir o terminar ejecuciones hermanas y causar la ejecución con políticas de herramientas más amplias al explotar comprobaciones de autorización insuficientes en las solicitudes de control de subagentes.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> rust_binder: llamar a set_notification_done() sin el bloqueo de proc<br /> <br /> Considere la siguiente secuencia de eventos en un oyente de muerte:<br /> 1. El proceso remoto muere y envía un mensaje BR_DEAD_BINDER.<br /> 2. El proceso local invoca el comando BC_CLEAR_DEATH_NOTIFICATION.<br /> 3. El proceso local luego invoca el BC_DEAD_BINDER_DONE.<br /> Entonces, el kernel responderá al comando BC_DEAD_BINDER_DONE con una<br /> respuesta BR_CLEAR_DEATH_NOTIFICATION_DONE usando push_work_if_looper().<br /> <br /> Sin embargo, esto puede resultar en un interbloqueo si el hilo actual no es un<br /> looper. Esto se debe a que dead_binder_done() aún mantiene el bloqueo de proc<br /> durante set_notification_done(), que llamó a push_work_if_looper().<br /> Normalmente, push_work_if_looper() toma el bloqueo de hilo, lo cual está bien tomar<br /> bajo el bloqueo de proc. Pero si el hilo actual no es un looper,<br /> entonces recurre a entregar la respuesta a la cola de trabajo del proceso,<br /> lo que implica tomar el bloqueo de proc. Dado que el bloqueo de proc ya está<br /> retenido, esto es un interbloqueo.<br /> <br /> Solucione esto liberando el bloqueo de proc durante set_notification_done(). No<br /> fue intencional que se mantuviera durante esa función para empezar.<br /> <br /> No creo que esto ocurra nunca en Android porque BC_DEAD_BINDER_DONE<br /> solo se invoca en respuesta a mensajes BR_DEAD_BINDER, y el kernel<br /> siempre entrega BR_DEAD_BINDER a un looper. Así que no hay ningún escenario donde<br /> el espacio de usuario de Android llame a BC_DEAD_BINDER_DONE en un hilo que no sea un looper.