La cadena de compromiso de TanStack, Nx Console y GitHub (mayo de 2026): qué deben revisar los desarrolladores

Los paquetes afectados son 42 paquetes Router/Start, 84 versiones, entre ellos @tanstack/react-router, @tanstack/react-start, @tanstack/router-core y @tanstack/history (lista completa en el aviso de GitHub GHSA-g7cv-rxg3-hmpx). TanStack afirma que Query, Table, Form, Virtual y sus demás paquetes no se vieron afectados. Revise no solo el contenido actual de su lockfile, sino también su historial de cambios alrededor del 11 de mayo de 2026. Las versiones maliciosas se eliminaron de npm en cuestión de horas, por lo que una instalación durante ese periodo podría no aparecer en el lockfile actual. En CI, busque trabajos que hayan ejecutado una instalación después de las 19:20 UTC del 11 de mayo.

La autopsia de Nx muestra cómo verificar la versión instalada con code --list-extensions --show-versions (el ID de la extensión contiene angular-console). Solo se vio afectada la v18.95.0, que estuvo disponible el 18 de mayo entre las 12:30 y las 13:09 UTC. Nx pide que quien tuviera Nx Console con actualización automática activada durante ese periodo considere la máquina como comprometida, sea cual sea la cifra de instalaciones que resulte correcta. La autopsia también enumera archivos y procesos que buscar (indicadores de compromiso); si está afectado, siga esa lista.

TanStack y Nx indican los mismos objetivos: tokens de GitHub, tokens de npm, claves SSH, credenciales de nube (AWS, GCP, Azure), Kubernetes, tokens de Vault y el contenido de cualquier archivo .env. Nx añade las credenciales que las herramientas de la máquina pudieron haber generado durante el periodo (credenciales temporales de nube, tokens de la CLI de GitHub, etc.), y recomienda considerar una reconstrucción completa de la máquina después de la rotación. Para el orden de revocación y cómo tratar un malware residente, consulte la sección "si sospecha de infección" de Cómo defenderse de gusanos de cadena de suministro en npm.

Según TanStack, el código buscaba otros paquetes que mantiene la víctima e intentaba republicarlos con la misma inyección. Si publica en npm, revise el historial de versiones de sus paquetes en busca de versiones que usted no publicó desde el 11 de mayo.

Según Nx, la credencial robada era un token de la CLI de GitHub. En ese entorno estaba guardada en un archivo en disco y era legible por cualquier proceso que se ejecutara como el usuario, y se usó contra la API de GitHub en 74 segundos. Ejecute gh auth status para ver dónde está el suyo; si está en un archivo de texto plano, considere moverlo al llavero del sistema operativo o a una integración con un gestor de contraseñas que inyecte la credencial solo en tiempo de ejecución. Tras el incidente, la política de Nx ya no permite el uso directo de la CLI de GitHub en equipos de desarrollo. Para reducir la vigencia y el alcance del token, consulte Cómo defenderse de gusanos de cadena de suministro en npm.

Según Nx, el proyecto del colaborador comprometido tenía minimum-release-age=10080 (7 días) en su .npmrc, pero el proyecto fijaba pnpm 10.14, que no admite ese ajuste y lo ignoró silenciosamente. El soporte empieza con pnpm 10.16. La versión maliciosa tenía solo 77 minutos de antigüedad en el momento de la instalación, así que un ajuste funcionando la habría bloqueado. Revise la versión fijada en el campo packageManager de package.json y haga que CI verifique que sea lo bastante reciente. El ajuste equivalente para npm se explica en Cómo defenderse de gusanos de cadena de suministro en npm.

El 26 de mayo, GitHub anunció que está rotando claves, incluida la que firma los paquetes de actualización de GitHub Enterprise Server. Los administradores deben rotar las claves públicas GPG de su instancia; de lo contrario, las futuras actualizaciones fallarán con un error que indica que el archivo no es un paquete GHES válido. Las instrucciones y el digest SHA256 del script auxiliar están en la publicación de GitHub. GitHub también pide a los clientes que descarguen las actualizaciones de GHES solo desde la fuente oficial y que se preparen para recibir actualizaciones de seguridad con mayor frecuencia en los próximos meses. Los clientes de GitHub Enterprise Cloud no necesitan hacer nada.

Según TanStack, un flujo de control de tamaño de bundle se ejecutaba con pull_request_target y, dentro de él, descargaba y construía código de un pull request desde un fork. pull_request_target se ejecuta con los privilegios del repositorio base, y TanStack señala que la puerta de aprobación para colaboradores nuevos no se aplica a este disparador. Limítelo a tareas que nunca ejecuten código externo, como etiquetar y comentar. Tras el incidente, TanStack eliminó todo uso de pull_request_target de su CI.

Según TanStack, la caché de GitHub Actions se comparte por repositorio: las ejecuciones de pull_request_target y los envíos a main usan el mismo ámbito. Además, guardar en caché no se bloquea configurando permissions: del flujo como solo lectura. Como resultado, el flujo de publicación restauró una caché escrita por un trabajo que había ejecutado código externo. Tras el incidente, TanStack desactivó la caché de paquetes en su pipeline de publicación y purgó todas las cachés. No restaurar cachés en los flujos que publican es la línea más sencilla de trazar.

El flujo de publicación de TanStack tenía id-token: write para la publicación confiable de npm (OIDC). Según la autopsia, la publicación maliciosa no provino del paso de publicación definido en el flujo; código que se ejecutaba en otra etapa de la misma ejecución extrajo un token y publicó directamente. La lección que TanStack extrae es que un vínculo de editor confiable no tiene revisión por cada publicación. Separe la publicación en su propio trabajo, aparte de la compilación y las pruebas, dé el permiso solo a ese trabajo y colóquelo detrás de un entorno de GitHub con revisores obligatorios. Tras el incidente, Nx hizo obligatoria la aprobación para publicar por alguien distinto de quien activó la ejecución.

Tras el incidente, tanto TanStack como Nx fijaron cada referencia de acción a un SHA de commit en lugar de a una etiqueta o rama. TanStack describe las referencias flotantes como un "riesgo permanente para la cadena de suministro, independiente de este incidente".

Nx detectó la publicación manipulada gracias al correo de notificación rutinario que el marketplace de extensiones envía con cada subida. Un mantenedor que no esperaba una publicación la reconoció como anómala y la retiró en unos 11 minutos. El segundo canal de distribución no tenía esa notificación, y la retirada allí tardó unos 36 minutos. Mientras tanto, la actividad con el token robado, como la eliminación de ejecuciones de flujos de trabajo, permaneció una semana en el registro de auditoría sin que nadie la notara. Compruebe que las notificaciones de publicación lleguen a alguien del equipo y que alguien vigile el registro de auditoría en busca de ejecuciones de flujos eliminadas.