La cadena de suministro de software en jaque: el ataque a Cline que instaló OpenClaw sin permiso

Esta semana se confirmó otro episodio preocupante en la seguridad de la cadena de suministro de software: la herramienta de ayuda para programadores Cline CLI, un proyecto de código abierto que integra capacidades de inteligencia artificial, fue publicada en la red npm en una versión comprometida que incluía una instrucción para instalar de forma silenciosa el agente autónomo OpenClaw. El paquete afectado fue [email protected], y la publicación no autorizada se produjo el 17 de febrero de 2026 usando un token de publicación que, según los mantenedores, había sido comprometido. Puede consultarse el comunicado oficial en el aviso de seguridad del proyecto en GitHub: GHSA-9ppg-jx86-fqw7.

El paquete publicado incluía una modificación en package.json que añadía un script de postinstalación cuyo efecto fue ejecutar npm install -g openclaw@latest. Eso provocó que, durante un periodo de aproximadamente ocho horas entre las 3:26 y las 11:30 PT del 17 de febrero, cualquier desarrollador que instalara esa versión recibiera la instalación automática de OpenClaw en su entorno. Los responsables de Cline afirman que no se detectó otro código malicioso dentro del paquete, y que la instalación de OpenClaw no se diseñó ni autorizó; aún así, el hecho de que un agente autónomo pudiera distribuirse así genera inquietud.

Los mantenedores respondieron retirando la versión afectada y publicando rápidamente [email protected], además de desactivar el token comprometido y marcando la 2.3.0 como deprecada. También anunciaron cambios en su mecanismo de publicación que incorporan OpenID Connect (OIDC) desde GitHub Actions para reducir la dependencia de tokens estáticos y minimizar este tipo de riesgos. El flujo de noticias técnicas ha ido documentando la reacción y el alcance: por ejemplo, Microsoft Threat Intelligence señaló en su cuenta de X un aumento en las instalaciones de OpenClaw coincidente con el incidente (ver publicación), y firmas de seguridad han estimado que la versión comprometida se descargó miles de veces durante la ventana de exposición, según datos compartidos por StepSecurity.

Aunque OpenClaw en sí no se considera malware y, según el análisis de la firma Endor Labs, la publicación no contenía componentes que arrancaran servicios peligrosos de forma inmediata, este suceso es un recordatorio de que la instalación no deseada de software con privilegios puede convertirse en una puerta de entrada para ataques más graves. Como explicó el investigador Henrik Plate de Endor Labs, el impacto técnico inmediato puede ser limitado, pero la lección operativa es clara: los mantenedores deben forzar mecanismos de publicación confiables y los usuarios deben vigilar las atestaciones y firmas asociadas a las releases. El análisis completo de Endor Labs está disponible aquí: Endor Labs – análisis del incidente.

La investigación sobre cómo se obtuvo la capacidad de publicar la versión maliciosa apunta a una cadena de explotación más compleja que involucra agentes de IA utilizados en los flujos de trabajo de triage de issues. El investigador Adnan Khan detectó que el repositorio de Cline tenía un workflow que, al abrirse una incidencia, levantaba un agente Claude con acceso a la base de código y a herramientas adicionales para generar respuestas automáticas. Esa automatización, pensada para aligerar la carga de los mantenedores, otorgaba excesivos permisos al agente, y un título de issue cuidadosamente construido podía inducir a la IA a ejecutar comandos arbitrarios: una técnica que Khan bautizó como “Clinejection”. Su explicación técnica y pruebas están publicadas en su blog: Clinejection — análisis de Adnan Khan. El commit que introdujo el cambio susceptible de explotación también puede consultarse en el repositorio: commit de diciembre de 2025.

La secuencia de ataque descrita por Khan combina prompt injection contra agentes de IA con una técnica de envenenamiento de cache en GitHub Actions para lograr ejecución en un workflow de publicación con permisos elevados. El atacante primero provoca que el sistema de triage ejecute código malicioso, luego rellena la cache con datos que provocan la expulsión de entradas legítimas y coloca entradas “envenenadas” que coinciden con las claves usadas por los jobs nocturnos de publicación. Cuando la rutina de publicación nocturna se ejecuta y encuentra esas entradas manipuladas, recupera artefactos y credenciales que permiten a quien controla el flujo publicar artefactos en npm con tokens de producción. Khan ya había escrito sobre este tipo de riesgo en análisis previos sobre GitHub Actions cache poisoning: The monsters in your build cache.

Investigadores externos han confirmado que la cadena de explotación descrita fue, en esencia, la que derivó en la publicación de [email protected] con el script de postinstalación. Un informe técnico que resume hallazgos y correlaciones está disponible en el blog de MBG Security, que detalla cómo se llegó a aprovechar un token activo de publicación en npm para firmar y subir el paquete comprometido: MBG Security – investigación del compromiso. Complementariamente, el análisis y la cobertura del caso por medios de seguridad especializados ayudan a entender el panorama: socket.dev – análisis del ataque y una nota más generalista con reacciones de la industria en The Hacker News.

Más allá de los detalles técnicos inmediatos, la comunidad de seguridad observa una conclusión práctica: los agentes de IA incorporados a pipelines y automatizaciones no son actores neutrales; cuando reciben permisos amplios, actúan como componentes privilegiados del sistema. Chris Hughes, responsable de estrategia de seguridad en Zenity, sintetizó esta idea al subrayar que lo que antes se debatía en abstracto sobre la seguridad de agentes autónomos ahora tiene un coste operativo tangible y exige gobernanza y controles de acceso específicos. La nota con su declaración está recogida en la cobertura del incidente por The Hacker News.

Si usas Cline o administras repositorios que emplean automatizaciones similares, las medidas inmediatas que recomiendan los equipos de respuesta y los investigadores son claras: actualizar a la versión corregida, revisar el entorno por instalaciones inesperadas de OpenClaw y eliminar cualquier componente no requerido, rotar tokens y credenciales que podrían haber sido expuestas, y endurecer los workflows para que los agentes de IA no reciban permisos para ejecutar código con privilegios de publicación. También conviene adoptar OIDC para la publicación desde GitHub Actions y deshabilitar la publicación mediante tokens tradicionales cuando sea posible, así como añadir verificaciones de atestación y firmas en los pipelines de entrega.

Este incidente pone de relieve que la adopción de IA en desarrollo y operaciones trae beneficios, pero también introduce vectores novedosos de ataque. La seguridad de la cadena de suministro ya no es solo responsabilidad de los mantenedores de paquetes: involucra a equipos de infra, desarrolladores y a las propias plataformas que orquestan automatizaciones. Mantener la confianza en los paquetes que instalamos exige, ahora más que nunca, controles finos sobre quién o qué puede publicar, trazabilidad de las publicaciones y auditorías regulares de los flujos automatizados.