Se han descubierto cinco vulnerabilidades de día cero en OpenClaw, una herramienta que integra agentes de IA en plataformas como Slack, Discord, Microsoft Teams, Matrix y Telegram. Estos fallos permitían a los atacantes evadir los límites de confianza y secuestrar el acceso a los agentes de IA, comprometiendo el modelo de listas de permitidos definido por los usuarios.

Cinco fallos de día cero en OpenClaw permitieron a los atacantes saltarse los límites de confianza y secuestrar el acceso a agentes de IA en múltiples plataformas de mensajería.

OpenClaw, que integra agentes de IA con servicios como Slack, Discord, Microsoft Teams, Matrix y Telegram, depende en gran medida de listas de permitidos definidas por el usuario para determinar quién puede interactuar con un agente.

Este modelo de confianza asume que solo las identidades aprobadas explícitamente pueden emitir comandos a agentes que podrían tener acceso a datos sensibles, APIs internas o capacidades de ejecución a nivel de sistema.

Sin embargo, Philip Garabandic descubrió que este modelo de confianza falla debido a una resolución de identidad incorrecta durante el procesamiento de la lista de permitidos.

Cinco 0-Days de OpenClaw

Las vulnerabilidades provienen de un fallo de diseño recurrente en el que los identificadores legibles para humanos, como los nombres de pantalla, se resuelven en IDs de usuario estables durante la inicialización del servicio.

Debido a que los nombres de pantalla son mutables en la mayoría de las plataformas de chat, los atacantes pueden suplantar a usuarios de confianza simplemente cambiando su nombre para que coincida con una identidad en la lista de permitidos.

Este problema se identificó inicialmente en la integración de OpenClaw con Telegram y se parcheó bajo el aviso GHSA-mj5r-hh7j-4gxf.

A pesar de la corrección, la misma causa raíz persistió en cinco extensiones de canal adicionales, específicamente Slack, Discord, Matrix, Zalo y Microsoft Teams.

Cada implementación reintrodujo de forma independiente el mismo patrón inseguro, lo que pone de relieve un problema más amplio en el desarrollo distribuido y la aplicación inconsistente de la seguridad.

En el núcleo de la vulnerabilidad hay un proceso de resolución de inicio defectuoso. Mientras que las comprobaciones en tiempo de ejecución suelen validar IDs de usuario estables, la lógica de inicialización resuelve las entradas de la lista de permitidos mediante búsquedas de directorio basadas en campos mutables como displayName o username.

Si un atacante cambia su nombre de pantalla para que coincida con un usuario permitido antes de que se reinicie el servicio, el sistema puede vincular incorrectamente el ID del atacante en la lista de confianza.

Una vez que esto ocurre, el atacante obtiene el control total sobre las interacciones del agente mientras que el usuario legítimo es excluido silenciosamente.

Las vulnerabilidades fueron identificadas utilizando una herramienta de análisis estático especializada impulsada por IA llamada agentgg, que genera detectores personalizados basados en avisos históricos.

Al analizar vulnerabilidades previas de OpenClaw, la herramienta desarrolló una lógica de detección dirigida para antipatrones recurrentes, identificando finalmente un fallo replicado en múltiples módulos.

Cada hallazgo ha sido reconocido y abordado por los mantenedores de OpenClaw, con correcciones que imponen una coincidencia estricta basada en ID y dejan la resolución basada en nombres tras indicadores de configuración explícitos.

Desde una perspectiva de seguridad, esta clase de vulnerabilidad se alinea con CWE-639, que describe la omisión de la autorización a través de identificadores controlados por el usuario.

El impacto es particularmente grave en entornos de agentes de IA, donde el acceso comprometido puede traducirse en la ejecución de comandos arbitrarios, la exfiltración de datos o el movimiento lateral dentro de los sistemas integrados.

Según Philip Garabandic, el incidente resalta que parchear un solo componente no elimina la clase de vulnerabilidad subyacente.

Sin mecanismos de detección sistémicos, el mismo fallo puede propagarse silenciosamente a través de implementaciones paralelas.

Al convertir los datos de incidentes pasados en flujos de trabajo de detección automatizados, las organizaciones pueden prevenir fallos repetidos y fortalecer los límites de confianza en arquitecturas impulsadas por IA cada vez más complejas.