CrowdSec perdió 170 repositorios privados en nueve minutos debido a una falla en el proceso de offboarding

El 22 de mayo de 2026, entre las 05:52:29 y las 06:01:33 UTC, alguien que trabajaba desde una dirección IP en Toronto, Canadá, utilizó la cuenta de GitHub de un desarrollador que acababa de dejar CrowdSec para copiar aproximadamente 170 de los repositorios privados de la empresa de seguridad francesa. CrowdSec publicó esa cronología en su propio informe de incidente el 18 de septiembre de 2026 —la fecha que el archivo de incidentes de IA asigna a este registro— después de que un archivo de su código fuente apareciera en el mercado de ciberdelincuencia pwnforum el 16 de septiembre. La cuenta seguía funcionando porque la empresa había dejado deliberadamente abierto el acceso de GitHub del desarrollador para que pudiera terminar algo de trabajo. El portátil que había detrás había sido infectado once días antes por el gusano ladrón de credenciales Mini Shai-Hulud que TeamPCP distribuyó a través de los paquetes npm de TanStack. Este relato se basa en el registro presentado el 18 de septiembre de 2026, y el conjunto completo de incidentes documentados —cada entrada con su propia gravedad, grado de confianza, indicador de disputa y fuentes— se encuentra en el Orca AI Incident Archive, donde este puede leerse junto a los demás casos de cadena de suministro del mismo año.

El robo no se limitó al código. El informe de CrowdSec también reveló las direcciones de correo electrónico de 83 usuarios, extraídas de una lista interna de monitoreo de ciencia de datos y en su mayoría cuentas de Gmail, además de los nombres y apellidos, las direcciones de correo electrónico y el contexto de inversión de 51 posibles inversores de 2020. Frente a aproximadamente 150.000 usuarios, 83 direcciones son una pequeña fracción; no es cero. El director ejecutivo Philippe Humeau reservó su disculpa personal para los inversores: «La filtración de sus nombres y direcciones de correo electrónico es un asunto que trataremos directamente con ustedes y con las autoridades competentes, y por ello les pido disculpas personalmente».

Lo que nueve minutos realmente conllevaron

Los registros de Git que GitHub devolvió a CrowdSec comienzan a las 05:52:32.138 UTC con una operación de fetch contra uno de los repositorios de la empresa, y la actividad se detiene a las 06:01:33. La cifra del archivo de aproximadamente 170 repositorios privados proviene de esos datos de Git. En su informe, Humeau describe la exposición como "limitada al código fuente de CrowdSecurity, incluidos más de 130 repositorios públicos y muchos privados". DevOps.com, que informó del incidente el 24 de septiembre, situó el recuento combinado de repositorios públicos y privados en aproximadamente 300 repositorios —una cifra mayor que la de repositorios privados de CrowdSec, y que el informe de la empresa no menciona.

El contenido era el mobiliario habitual de una empresa SaaS de rápido movimiento: el código fuente de la consola web, los scripts de despliegue y automatización, y los scripts y modelos de ciencia de datos que respaldaban su analítica. El elemento más sensible que CrowdSec menciona es el «algoritmo de consenso» que decide qué direcciones IP llegan a sus listas de bloqueo. La arquitectura del algoritmo ya era pública, pero sus umbrales de diversidad y detección no lo eran, y ahora se conocen. Humeau sostiene que los umbrales son un objetivo móvil y que dirigir el consenso seguiría requiriendo una flota grande y costosa de servidores; la empresa afirma que puede ajustarlos y está vigilando en busca de discrepancias.

Las credenciales fueron la parte que podría haber salido mucho peor. «Estuvimos muy cerca de quedar limpios», escribió Humeau. El único secreto utilizable en el volcado era un token de AWS Simple Notification Service, con alcance para publicar en un solo tema. Alguien lo probó el 17 de agosto de 2026 desde la IP 23.234.84.102, llamando a GetCallerIdentity y ListTopics contra los temas de dev y env, y no llegó más lejos. La mayoría de los demás tokens y secretos del código habían sido revocados o rotados antes de la filtración. CrowdSec afirma que no se accedió a su infraestructura ni a sus bases de datos y que no se alteró ningún código en el proyecto de código abierto, su código fuente privado ni sus canalizaciones de compilación.

Por qué la cuenta seguía funcionando

El fallo de offboarding es pequeño y concreto. Para cuando el desarrollador se marchó, CrowdSec ya había eliminado su otro acceso; la cuenta de GitHub se mantuvo activa, escribió Humeau, porque «nos separamos en buenos términos con nuestro desarrollador, y él quería finalizar algo de trabajo». La cuenta se eliminó de la organización de GitHub el 25 de mayo, tres días después de que los repositorios ya se hubieran copiado.

CrowdSec no pudo ver el robo en ese momento, y la razón merece exponerse con precisión. El token OAuth no estaba presente en el registro de auditoría de la organización ni en el de ningún miembro actual, y para cuando alguien fue a buscarlo ya no existía: se había creado, usado y caducado sin dejar ningún rastro que la empresa pudiera leer. GitHub solo conserva la actividad de Git en una ventana móvil de siete días para las organizaciones que no tienen un plan Enterprise, como señala la propia CrowdSec. El avance llegó del equipo de soporte de GitHub, que rastreó todo el ciclo de vida del token y proporcionó la actividad de Git de la ventana de dos horas en torno a la copia. Así fue como la empresa llegó a la cuenta de un empleado que ya no trabajaba allí. El vínculo con TanStack provino del mismo ejercicio.

El archivo filtrado llevaba consigo su propia evidencia. El .github/.git/config que contenía registraba una URL de origen con el formato oauth2:gho_xxxxxxxxx@github.com, lo que identificaba la credencial como un token OAuth de GitHub y coincidía con la metodología documentada de TeamPCP. CrowdSec afirma que revisó las máquinas de los desarrolladores en busca de paquetes maliciosos y no encontró ninguna de las versiones de TanStack con puerta trasera en sus propios repositorios — un resultado que describe como no concluyente en lugar de exculpatorio.

¿Quién lo hizo y qué tan firme es la atribución?

CrowdSec atribuye la descarga a «uno de los fundadores de BreachForum y un miembro, diencracked», con la dirección del miembro indicada como diencracked@cock.li, operando desde una IP de Toronto con la zona horaria de la máquina configurada en UTC-4. La empresa añade su propia cautela en la misma frase: «Al menos eso es lo que muestran los datos de Git». El informe de Dark Reading del 22 de septiembre lleva la misma atribución al fundador de BreachForum y al alias diencracked.

La campaña upstream está mejor documentada que las identidades que hay detrás. Los paquetes de TanStack fueron comprometidos mediante puerta trasera el 11 de mayo de 2026, cuando se publicaron 84 versiones maliciosas en 42 paquetes; The Hacker News registra el compromiso como CVE-2026-45321 y cita el propio aviso de TanStack para la carga útil de robo de credenciales. La cronología de CrowdSec señala que el 22 de mayo, el mismo día que la copia del repositorio, TeamPCP —rastreado por CrowdSec como UNC6780— se atribuyó la responsabilidad de comprometer repositorios pertenecientes a Mistral AI.

Qué está establecido y qué no

Establecido: una copia de aproximadamente 170 repositorios privados se realizó el 22 de mayo de 2026, en una ventana de nueve minutos, utilizando la cuenta de GitHub aún válida de un desarrollador que ya no forma parte de la empresa —una secuencia reconstruida a partir de los propios registros de actividad de Git de GitHub, no inferida. También se estableció, según la propia versión de la empresa, lo siguiente: la exposición de 83 direcciones de correo electrónico de usuarios y los datos de 51 posibles inversores, la revocación del 25 de mayo, el token de SNS sondeado y la conclusión de que no se alteró ningún código y no se accedió a ninguna infraestructura ni base de datos.

No determinado: qué paquete envenenado llegó al portátil y cuándo. CrowdSec afirma claramente que no identificó ninguno de los dos. El escaneo del repositorio de la empresa no fue concluyente, y sus máquinas de desarrollo dieron resultados limpios, lo que resulta difícil de conciliar con un portátil que, según el propio relato de la empresa, fue comprometido. La laguna se reconoce en lugar de cerrarse.

No publicado: la versión de GitHub sobre la investigación. CrowdSec afirma que el equipo de soporte de GitHub corroboró el origen de TanStack, pero The Hacker News señala que el informe de la empresa no contiene hallazgos del propio GitHub, y GitHub no ha publicado su propio relato del ciclo de vida del token.

Corroboración:Dark Reading, The Hacker News y DevOps.com cubrieron el incidente cada uno en el plazo de una semana, y los tres se basan en el informe de CrowdSec y el aviso de TanStack, no en un examen forense independiente de los sistemas de CrowdSec. Dark Reading añade comentarios de profesionales externos, entre ellos Denis Calderone, de Suzu Labs, quien calificó el fallo de revocación como «cosas del primer día». Una nota de investigación de Cloud Security Alliance fechada el 20 de septiembre repite la secuencia, pero el documento incluye su propia advertencia de que fue generado con asistencia de IA y no ha sido sometido a la revisión oficial de la CSA — algo que conviene saber antes de tomarlo como un segundo hallazgo independiente. El archivo califica la confianza del registro como A, disputado falso, daño real verdadero.

La primera afirmación y la corrección.

La primera declaración pública de CrowdSec, el 17 de septiembre, afirmó que «no se filtraron datos de clientes, inicio de sesión/contraseña, nombre, organización ni ninguna otra cosa, y CrowdSec no almacena información personal identificable (PII) ni registros de clientes; el impacto se limita a CrowdSec». También planteó una hipótesis técnica: que se había introducido una puerta trasera en un componente interno para robar una clave de API capaz de leer código privado.

El informe más completo, un día después, sustituyó esa hipótesis por la versión del empleado que se marchó y reveló las 83 direcciones y los 51 inversores. Hacker News describe esto como una corrección de la afirmación anterior. El planteamiento del propio CrowdSec es más limitado: las 83 direcciones procedían de una lista de monitoreo de ciencia de datos, no de registros de clientes, y los datos de los inversores databan de 2020. Ambas descripciones pueden ser ciertas a la vez: las direcciones no eran cuentas de clientes y, aun así, seguían siendo datos personales en un volcado publicado en un foro criminal. La empresa afirma que notificará a los usuarios e inversores afectados y denunciará la filtración ante las autoridades.

¿Qué cambió después?

• Las credenciales y los tokens encontrados en el archivo se rotaron la noche del 16 de septiembre y a lo largo del 17 de septiembre, y la rotación restante se completó a la mañana siguiente.

• La detección y respuesta en puntos finales ya está implementada en las estaciones de trabajo y los portátiles de las personas que trabajan con el código base o la infraestructura de CrowdSec; la empresa señala Aikido Security como el producto. Humeau admite que debería haber estado implementado antes, y también admite que era poco probable que la máquina de un exempleado lo estuviera ejecutando.

• Los umbrales del algoritmo de consenso expuestos en la filtración se están ajustando, con una monitorización más estricta de las desviaciones estadísticas en toda la red de blocklist.

• La empresa se ha fijado el objetivo de comprimir esa misma respuesta —inventario, rotación, análisis forense y divulgación— de 48 horas a menos de 24.

• Los usuarios e inversores afectados están siendo contactados directamente, y la filtración se está denunciando a las autoridades, según la formulación de la empresa.

Por qué esto figura en un archivo de incidentes de IA

La participación de la IA aquí es de carácter infraestructural, y vale la pena ser precisos sobre lo que eso significa. Nada en el relato de CrowdSec describe a un sistema de IA tomando una decisión durante la intrusión; el actor fue una persona o varias personas usando un token robado. Lo que convierte el caso en un incidente de la industria de la IA es el radio de impacto. Las bibliotecas de TanStack construyen las interfaces de una gran parte del software moderno, el gusano que recolectó el token está diseñado para tomar credenciales de nube, SSH y de proveedores de modelos en una sola pasada, y el material copiado de CrowdSec incluía scripts y modelos de ciencia de datos, no solo código de aplicación.

La misma campaña llegó directamente a empresas de IA. La cronología de CrowdSec registra que TeamPCP reclamó repositorios de Mistral AI el 22 de mayo, y The Hacker News informa de que dos dispositivos de empleados de OpenAI se vieron afectados, con acceso no autorizado a un conjunto limitado de repositorios de código internos. El archivo registra el caso de CrowdSec como la segunda víctima aguas abajo del compromiso de TanStack de mayo, después de esos dispositivos del personal de OpenAI.

La distancia entre la copia y su descubrimiento es la parte que debería recorrer. Los repositorios se tomaron el 22 de mayo; CrowdSec se enteró de la filtración el 16 de septiembre, cuando el equipo de Fuites Info contactó con la empresa acerca de la publicación en pwnforum —117 días después, y no gracias a su propia monitorización. El mecanismo que hizo posible el retraso no era exótico: una cuenta que siguió activa tres días después de haber cumplido su propósito, un token que no dejó rastro en los registros que la empresa podía leer y portátiles de desarrolladores sin detección de endpoints. CrowdSec, una empresa que vende detección de amenazas, contaba con las tres cosas.