Clinejection: cómo un título de incidencia llegó al token de npm de Cline

El 9 de febrero de 2026, el investigador de seguridad Adnan Khan publicó un relato de una falla que había reportado en privado a Cline el 1 de enero: el asistente de programación con IA de código abierto había conectado un clasificador automático de incidencias, construido sobre la GitHub Action claude-code-action de Anthropic, a un prompt que pegaba directamente cualquier título de incidencia entrante de GitHub en las instrucciones del modelo. Cualquier cuenta de GitHub podía activarlo abriendo una incidencia, y en la reproducción de Khan, un título redactado como una instrucción hizo que el agente ejecutara un comando de shell dentro del flujo de trabajo. Luego rastreó la ruta desde ese punto de apoyo, pasando por el envenenamiento de caché de GitHub Actions, hasta las credenciales de publicación para VS Code Marketplace, OpenVSX y npm. Ocho días después de que Cline corrigiera el flujo de trabajo, se usó un token de publicación de npm que Cline creía haber rotado para publicar cline 2.3.0, que instalaba OpenClaw en todas las máquinas que instalaran el paquete. La entrada completa, con sus calificaciones de gravedad y confianza, se encuentra en el Orca AI Incident Archive, junto a los registros cercanos de la cadena de suministro del mismo periodo.

Dos fechas, no una

El archivo fecha este registro el 9 de febrero de 2026, con precisión de día, y ese es el día en que Khan publicó su artículo en adnanthekhan.com. No es el día en que apareció el paquete malicioso. La vulnerabilidad en sí se introdujo el 21 de diciembre de 2025, en un commit que añadió el flujo de trabajo de triaje al repositorio cline/cline, y permaneció activa hasta que Cline eliminó el flujo de trabajo el 9 de febrero. La publicación no autorizada en npm se produjo el 17 de febrero, ocho días después de la corrección y cuarenta y siete días después del primer informe privado de Khan.

Mantener esas dos fechas separadas importa, porque el hecho más trascendente del caso se encuentra en el intervalo entre ambas: la puerta se cerró el 9 de febrero, pero la llave que el intruso ya había copiado seguía funcionando el 17 de febrero. La propia corrección de Cline, enviada a Khan el 17 de febrero y reproducida en su publicación, lo dice directamente: «Cuando rotamos las credenciales el 9 de febrero, el token de publicación de npm no se revocó correctamente. Se eliminó el token equivocado y el expuesto permaneció activo».

La cadena: desde el título de un issue hasta un token de release

El archivo vulnerable era .github/workflows/claude-issue-triage.yml, que se ejecutaba con el evento issues e invocaba anthropics/claude-code-action@v1 con Claude Opus 4.5, fijado en el flujo de trabajo como claude-opus-4-5-20251101. Khan cita la configuración del flujo de trabajo: allowed_non_write_users estaba establecido en el comodín "*", por lo que cualquier cuenta de GitHub podía activar el agente simplemente abriendo una issue, y claude_args pasaba --allowedTools con Bash, Read, Write, Edit, Glob, Grep, WebFetch y WebSearch. Bash era el que importaba. Le daba al modelo ejecución de shell dentro de un flujo de trabajo que se ejecutaba en el contexto de la rama predeterminada.

La prueba de concepto de Khan utilizó un título que comenzaba con «Error de herramienta.» y continuaba con una instrucción para instalar un paquete auxiliar desde un commit específico antes de continuar con la clasificación. La referencia del commit apuntaba a un fork cuyo package.json incluía un script de preinstalación que ejecutaba un comando curl contra un punto final controlado por el atacante antes de que npm hubiera terminado de instalar nada. Como la instalación se ejecutó mediante la herramienta Bash, el modelo nunca inspeccionó lo que se ejecutó. Khan reprodujo esto en un espejo del repositorio de Cline e informa que el agente ejecutó la carga útil en todos los intentos.

La ejecución de código en el flujo de trabajo de triaje no constituye, por sí sola, acceso a credenciales de publicación. Ese paso provenía de una propiedad de GitHub Actions que Khan había documentado en una herramienta que publicó en 2024 llamada Cacheract: cualquier flujo de trabajo puede leer y escribir en la caché del repositorio con control total de las claves y versiones de caché, incluso un flujo de trabajo que nunca declara un paso de almacenamiento en caché. El trabajo de triaje se ejecutaba en la rama predeterminada, por lo que compartía un ámbito de caché con los trabajos de publicación nocturnos, que sí restauraban node_modules desde la caché y sí tenían los tokens de publicación.

Las entradas de caché son inmutables, así que un atacante no puede simplemente sobrescribir la entrada que restaurará un trabajo de publicación. La ruta de Khan para eludir eso fue explotar un cambio de política de GitHub del 20 de noviembre de 2025, que hizo que el servicio expulsara entradas de caché inmediatamente una vez que la caché de un repositorio superaba los 10 GB, usando el orden de uso menos reciente. Inunda la caché hasta superar los 10 GB y las entradas legítimas quedan fuera; reclama las claves liberadas con contenido envenenado, y el siguiente trabajo que las restaure ejecutará código del atacante. Cacheract automatiza toda la secuencia dentro de una sola ejecución de workflow, y persiste sobrescribiendo el action.yml de actions/checkout para que el paso posterior de la acción ejecute una carga útil al final de cada trabajo.

El último eslabón de la cadena es el trabajo nocturno, que se ejecuta aproximadamente a las 2:00 UTC, restaura el node_modules envenenado y detona. Lo que sale de ahí son VSCE_PAT, OVSX_PAT y NPM_RELEASE_TOKEN, las credenciales para VS Code Marketplace, OpenVSX y npm, respectivamente. Si cada eslabón se ejecutó contra el repositorio propio de Cline en ese orden es una cuestión aparte, que se aborda más abajo.

Por qué las credenciales nocturnas eran credenciales de producción

La objeción obvia es que las versiones nocturnas y de producción deberían usar secretos distintos. La respuesta de Khan es que la separación era nominal. OpenVSX y VS Code Marketplace vinculan un token de publicación a una identidad de editor, no a una extensión individual, y tanto la extensión estable como la nocturna de Cline se publicaron bajo la misma identidad, que Khan identifica en OpenVSX como saoudrizwan. En npm, el modelo de tokens de grano fino está vinculado a un paquete, y Cline publicó sus compilaciones CLI estable y nocturna en el mismo paquete cline. Por lo tanto, un token emitido para el trabajo nocturno podía publicar el artefacto de producción, que es exactamente lo que ocurrió ocho días después.

El propio planteamiento de Khan sobre el impacto se basa en la escala: cita el anuncio de Cline de que había superado los 5 millones de instalaciones y señala que una actualización de la extensión introducida mediante credenciales robadas se ejecuta en el contexto de cada desarrollador cuyo editor se actualiza automáticamente, con los permisos de ese desarrollador y cualesquiera claves, tokens y código fuente que haya en la máquina.

Lo que realmente se publicó y lo que hizo

El artefacto publicado era cline 2.3.0, y era pequeño. Las marcas de tiempo propias del registro npm sitúan 2.3.0 a las 11:26:51 UTC del 17 de febrero de 2026 y la versión limpia 2.4.0 a las 19:23:08 UTC del mismo día, una exposición que el aviso de Cline calcula en aproximadamente ocho horas, hasta que 2.3.0 quedó obsoleta a las 11:30 AM PT. El package.json del paquete contenía una línea añadida, un script postinstall que decía npm install -g openclaw@latest. El aviso de Cline, GHSA-9ppg-jx86-fqw7, afirma que no se modificó ningún otro archivo del paquete y que dist/cli.mjs es idéntico byte a byte a la compilación legítima 2.2.3.

OpenClaw es un framework de agentes de IA de código abierto real, no malware, y el aviso de Cline lo dice explícitamente: es un proyecto legítimo, pero su instalación no fue autorizada ni prevista. Endor Labs, que analizó el tarball, evaluó el impacto general como bajo sobre la base de que la instalación no inició el daemon Gateway de OpenClaw. El informe de StepSecurity mide el otro lado: una instalación global deja el framework en disco con cualesquiera credenciales y acceso a archivos que tenga el usuario que instala, y el diseño de OpenClaw, un gateway local persistente con una API de operador, hace que sea algo de alto valor encontrarlo allí. Las dos evaluaciones no son contradictorias. Una describe lo que se ejecutó durante la ventana; la otra describe lo que quedó atrás después.

El volumen es el único número que debe manejarse con cuidado. StepSecurity informó de que la versión comprometida se descargó aproximadamente 4.000 veces antes de quedar obsoleta, y The Register repitió esa cifra. Endor Labs situó el recuento mensual de descargas de cline del 19 de enero al 17 de febrero en 418.545, lo que describe el tráfico normal del paquete y no la compilación maliciosa. Ninguna de las cifras cuenta máquinas: un recuento de descargas no es un recuento de desarrolladores afectados, y ninguna de las partes ha publicado una cifra de base instalada para 2.3.0. El equipo de Threat Intelligence de Microsoft dijo en X que observó un "pequeño pero notable aumento" en las instalaciones de OpenClaw el 17 de febrero derivado del script de instalación de Cline, según informó The Hacker News.

El registro de avisos de GitHub para GHSA-9ppg-jx86-fqw7 no incluye ningún CVE ni ningún CWE, y su gravedad es Baja. Esa calificación se refiere a la carga útil benigna, no al robo de credenciales, y resulta extraña junto a la calificación crítica del archivo para el incidente en sí. El aviso registra la 2.3.0 como versión afectada y la 2.4.0 como la corrección.

La divulgación a la que Cline no respondió

La cronología previa a la publicación de Khan es la parte del registro que menos tiene que ver con el modelo y más con el proceso. Envió un GHSA mediante la notificación privada de vulnerabilidades de GitHub el 1 de enero de 2026 y ese mismo día escribió por correo electrónico al contacto de seguridad indicado en la página de confianza de Cline. El 8 de enero envió un seguimiento a un desarrollador de Cline. El 18 de enero intentó enviar un mensaje directo al CEO de Cline en X. Volvió a escribir el 7 de febrero y no recibió más que un número de ticket automatizado. Publicó el 9 de febrero.

Cline fusionó la corrección, la pull request 9211, aproximadamente entre treinta minutos y una hora después. La PR elimina tres archivos de flujo de trabajo, claude-issue-triage.yml, claude-pr-review.yml y cline-pr-review.yml, y quita el almacenamiento en caché de publish.yml, publish-nightly.yml, npm-nightly.yaml y npm-main.yaml, siete archivos en total, y hace que los pasos de instalación sean incondicionales ahora que no hay ningún acierto de caché del que depender.

La respuesta pública de Cline el 10 de febrero, citada en la publicación de Khan, aceptó el hallazgo y enumeró mitigaciones inmediatas: la eliminación de los flujos de trabajo de revisión del bot de issues y PR, la eliminación de actions/cache de los flujos de trabajo de publicación que manejan credenciales de lanzamiento, y la rotación de las credenciales relevantes, incluidas las de bot, proveedor y publicación. También reconoció el manejo: "reconocemos que nuestro tiempo de respuesta a tu informe inicial fue inaceptable. Un informe presentado el 1 de enero no debería haber requerido una divulgación pública el 9 de febrero para que se atendiera".

El 11 de febrero, Cline dijo que había completado una rotación completa de VSCE_PAT, OVSX_PAT y NPM_RELEASE_TOKEN, y que una auditoría de cada versión publicada en los tres canales de distribución entre el 21 de diciembre de 2025 y el 9 de febrero de 2026 había determinado que cada versión de Marketplace y OpenVSX correspondía a una versión etiquetada de GitHub y que las 41 versiones de npm eran coherentes con el código fuente. Concluyó que no se había publicado ninguna versión no autorizada «durante la ventana de exposición alegada». Seis días después corrigió la información, en el mensaje citado más arriba: el token de npm no se había revocado y con él se había publicado la 2.3.0.

Establecido, atribuido, no resuelto

Confirmado. La configuración del flujo de trabajo es pública y se publicó antes de la corrección. Khan reprodujo la inyección de prompt en un espejo del repositorio. Cline fusionó la remediación y emitió un aviso que confirma la publicación de 2.3.0, la línea postinstall añadida, el binario CLI sin cambios, la ventana de ocho horas y el fallo del token. Las marcas de tiempo del registro npm para 2.3.0 y 2.4.0 coinciden con las horas del aviso. El archivo califica el registro como crítico, con confianza A, con daño real registrado y sin marca de disputa.

Atribuido, no establecido. Quién publicó 2.3.0 sigue siendo una atribución abierta. El informe forense publicado por Michael Bargury y una herramienta de investigación automatizada llamada Raptor el 19 de febrero nombra una cuenta de GitHub, glthub-actions, e informa con alta confianza que esta cuenta bifurcó cline/cline, abrió el issue 8904 el 28 de enero de 2026 a las 03:51 UTC con el título inyectado y usó un commit de la bifurcación para ejecutar una carga útil desde un gist. Khan confirmó que las cuentas gcbrun y Dev11940518 son suyas y que glthub-actions no. La cuenta ya había sido eliminada o suspendida cuando se publicó el informe, y Cline no ha nombrado a nadie. Trata la identidad como un hallazgo de terceros.

• Se discute su carácter, no los hechos. Bargury evalúa el episodio como coherente con una demostración de investigación de seguridad más que con una campaña maliciosa, y cita la carga útil benigna y el historial del actor respecto de un repositorio de automatización de New Relic. Cline lo califica como una publicación no autorizada, y Khan escribe que el actor que publicó 2.3.0 es "presuntamente" el mismo que envenenó las cachés. Nadie ha demostrado una intención de causar daño, y nadie ha demostrado que no la hubiera.

• Sin resolver. La propia nota de Khan previa a la publicación es cuidadosa respecto de un punto que la cobertura posterior a veces simplifica: entre el 31 de enero y el 3 de febrero de 2026, varias ejecuciones nocturnas fallaron con un paso Post Checkout que no produjo ninguna salida, que es el indicador de compromiso de Cacheract, y el flujo de trabajo de triaje es la ruta más obvia, pero no está probado que haya sido el punto de entrada de esa actividad. Tampoco ninguna de las partes ha publicado pruebas de que se hayan utilizado los tokens de Marketplace o de OpenVSX; el único artefacto que alguien ha producido es la compilación de npm.

¿Qué cambió después?

La remediación se aplicó en varias capas a la vez, y vale la pena nombrar cada una porque responden a partes distintas del fallo. El flujo de trabajo al que podía llegar un externo se eliminó en lugar de restringirse. La caché se retiró de los cuatro flujos de trabajo de publicación que contienen secretos de publicación, en lugar de retirarla del repositorio en su conjunto, que es el cambio que rompe el pivote. Se rotaron las credenciales y, tras la corrección del 17 de febrero, se revocó el token de npm correcto. El aviso de Cline indica que la publicación en npm ahora usa procedencia OIDC mediante GitHub Actions, y el análisis de metadatos de StepSecurity muestra por qué eso importaba: las versiones legítimas ya llevaban atestaciones de procedencia, y la 2.3.0 era la excepción publicada por una cuenta humana. La brecha era que la ruta del token de larga duración seguía abierta junto con la publicación de confianza, que es justo lo que Endor Labs sostiene que los mantenedores deberían cerrar. Cline publicó GHSA-9ppg-jx86-fqw7, marcó como obsoleta la 2.3.0 con el mensaje de que no debería instalarse y remitió a los usuarios a la 2.4.0 o posterior.

Las recomendaciones estructurales de Khan van más allá de lo que se implementó, y merecen registrarse como suyas, no como de Cline: eliminar Bash, Write y Edit de cualquier flujo de trabajo de triaje y dejarle únicamente lecturas de archivos y las llamadas específicas a GitHub CLI que necesite; no restaurar nunca una caché en un trabajo que contiene secretos de publicación de producción; y dar a las versiones nocturnas su propio espacio de nombres de registro y una identidad de publicación dedicada y no de producción, de modo que un token nocturno robado no pueda publicar en absoluto una versión estable.

El intervalo de ocho días entre la corrección y la publicación maliciosa es el detalle que hace que este registro merezca conservarse. Cada paso de la cadena era una técnica conocida; Khan había publicado la herramienta de envenenamiento de caché, y la investigación PromptPwnd de Aikido Security de diciembre de 2025 documentó el mismo patrón de mala configuración en el triaje. Lo que los convirtió en un incidente de cadena de suministro fue un flujo de trabajo que permitía que el texto de un desconocido llegara a una shell, una caché compartida con trabajos que tenían claves de publicación y una rotación de tokens que pasó por alto una credencial. Cada una de las tres correcciones habría roto la cadena por sí sola; la tercera llegó ocho días tarde.