OpenAI confirmó este jueves que dos dispositivos de empleados de la compañía se vieron comprometidos por el ataque a la cadena de suministro del ecosistema TanStack impulsado por el grupo TeamPCP. La intrusión, detectada durante la madrugada del miércoles en los sistemas internos de la compañía, permitió el robo de credenciales y material sensible alojado en repositorios internos de código fuente, aunque la compañía sostiene que el impacto ha sido limitado y no ha afectado a datos de clientes ni a los modelos de inteligencia artificial que sustentan ChatGPT.
El incidente comenzó después de que los atacantes de TeamPCP —conocidos por campañas anteriores contra entornos de desarrollo— explotaran vulnerabilidades en el proceso de publicación de paquetes npm. Distribuyeron un total de ochenta y cuatro paquetes maliciosos vinculados al ecosistema de desarrollo open source TanStack, utilizado por desarrolladores de todo el mundo. Según los investigadores que siguen la campaña, el grupo desplegó una nueva variante del gusano Mini Shai-Hulud, capaz de robar secretos de entornos CI/CD y de propagarse automáticamente a otros repositorios controlados por los mismos mantenedores.
El modus operandi fue quirúrgico. Los atacantes lograron secuestrar tokens OIDC de GitHub Actions, lo que les permitió comprometer la cadena de publicación de paquetes legítimos. El malware generó atestaciones SLSA de nivel 3, una garantía de integridad que hizo que los paquetes maliciosos parecieran completamente confiables. De hecho, los dos empleados de OpenAI que descargaron esos paquetes lo hicieron desde repositorios que cualquier desarrollador habría considerado seguros. Ninguna alarma saltó en el proceso de verificación de firmas. Esa fue la clave del éxito de TeamPCP: infiltrarse en las tuberías de confianza de los desarrolladores.
Una vez dentro del entorno de desarrollo de OpenAI, el malware se centró en la exfiltración de credenciales. Buscó en más de cien ubicaciones posibles, incluyendo herramientas de desarrollador como VS Code y Claude Code, e instaló mecanismos de persistencia para mantener el acceso. Lo que encontró no fue el núcleo de la inteligencia artificial, sino algo igualmente valioso: los certificados de firma de código de las aplicaciones de OpenAI para iOS, macOS, Windows y Android. Con esos certificados en manos ajenas, un atacante podría distribuir versiones falsas del software de la compañía haciéndolas pasar por oficiales.
La respuesta de OpenAI fue inmediata. Revocó los certificados comprometidos, rotó las credenciales filtradas y comenzó a firmar de nuevo todo el software afectado. La empresa advirtió en un comunicado que los usuarios de macOS deben actualizar sus aplicaciones antes del 12 de junio de 2026; de lo contrario, el software podría dejar de recibir actualizaciones e incluso fallar. También coordinó con las plataformas de distribución —Apple, Microsoft y Google— para bloquear cualquier intento de reutilizar los certificados robados en actividades de notarización maliciosa. “Hemos revisado todo el software firmado anteriormente y no encontramos indicios de manipulación no autorizada”, señaló la compañía. “Creemos que el riesgo de que alguien intente distribuir una aplicación falsa que aparente ser de OpenAI es bajo, pero hemos tomado todas las precauciones”.
El ataque a OpenAI demuestra que las cadenas de suministro se han convertido en el vector preferido por los adversarios para saltarse cualquier perímetro de seguridad.
La intrusión se produjo, además, en un momento crítico para la seguridad de la compañía. Según reveló OpenAI, el incidente ocurrió durante una migración en curso hacia configuraciones reforzadas que se habían introducido tras un ataque anterior a la cadena de suministro de Axios. Los dos dispositivos infectados aún no habían recibido esas protecciones adicionales, lo que probablemente permitió que los paquetes maliciosos se descargaran sin bloqueo. “Este incidente refleja un cambio más amplio en el panorama de amenazas: los atacantes cada vez apuntan más a las dependencias compartidas de software y a las herramientas de desarrollo que a una empresa en concreto”, concluyó OpenAI en su nota.
Anatomía de una intrusión que aprovecha la confianza en el código abierto
El gusano Mini Shai-Hulud, utilizado por TeamPCP, es un ejemplo avanzado de amenaza persistente dirigida a entornos de desarrollo. No busca explotar una vulnerabilidad de día cero en un servidor en producción, sino envenenar el pozo del software desde su origen para propagarse mediante la confianza inherente a las cadenas de publicación automatizadas. Al secuestrar tokens OIDC de GitHub Actions, el grupo obtuvo la capacidad de firmar paquetes como si fueran los propios mantenedores, lo que les permitió colarse en el flujo de trabajo de miles de desarrolladores.
Según los investigadores que destaparon la campaña, el malware no solo robaba secretos de CI/CD, sino que también se propagaba lateralmente hacia otros repositorios vinculados a las mismas identidades comprometidas. Esto afectó a paquetes relacionados con TanStack, UiPath, DraftLab y otras organizaciones, lo que sugiere que el grupo tiene un interés general en el ecosistema open source más que en un desarrollador concreto. El hecho de que los atacantes lograsen generar atestaciones SLSA de nivel 3 —el más alto en la cadena de suministro de software— indica un conocimiento profundo de los mecanismos de seguridad que se suponía debían proteger precisamente contra este tipo de ataques.
En el caso de OpenAI, la carga útil logró un doble objetivo: obtener credenciales de acceso a repositorios internos y, sobre todo, hacerse con los certificados de firma de código, que son la llave maestra para distribuir software en los principales sistemas operativos. La compañía ha señalado que no ha encontrado evidencias de que se hayan producido intentos de suplantación con esos certificados, pero la revocación preventiva y la actualización obligatoria para los usuarios de macOS indican que la cautela es máxima.
Los equipos de seguridad de OpenAI también revisaron las notarizaciones de todo el software firmado con los certificados anteriores y confirmaron que no se había producido ninguna firma inesperada. Esa validación cruzada, junto con el bloqueo coordinado con las plataformas, reduce la exposición, aunque el daño reputacional para el ecosistema de desarrollo —y para la confianza en las cadenas de suministro automatizadas— ya está hecho.
Dossier Moncloa: Ojos en la Sombra
El ataque a OpenAI mediante paquetes npm maliciosos es, a primera vista, un incidente corporativo que afecta a dos empleados y a unos certificados de firma. Pero en el análisis confidencial de esta redacción, el episodio tiene implicaciones mucho más profundas para la seguridad de las cadenas de suministro digitales que nutren a empresas, administraciones y organismos de inteligencia en todo el mundo.
El vector de amenaza —ciberataque a la cadena de suministro de software— se ha consolidado como una de las técnicas más eficaces para burlar los perímetros de seguridad más avanzados. El tradecraft empleado por TeamPCP, con el secuestro de tokens OIDC y la generación de atestaciones SLSA de nivel 3, revela un nivel de sofisticación comparable al de los grupos APT patrocinados por Estados. Aunque por ahora no se ha atribuido públicamente la autoría de TeamPCP a ningún servicio de inteligencia, la naturaleza y el alcance de la operación recuerdan a campañas previas del GRU ruso (APT28) o del MSS chino (APT31) contra infraestructuras de desarrollo. Estos grupos han demostrado un interés sostenido en comprometer repositorios de código abierto para infiltrarse en objetivos de alto valor. La diferencia aquí es que la víctima no es un gobierno, sino la compañía que probablemente ostenta la mayor concentración de talento en inteligencia artificial del planeta.
¿Quién ataca? TeamPCP, un grupo cuyas campañas anteriores apuntaban a entornos CI/CD y pipelines de publicación, pero sobre el que no hay atribución formal pública. ¿Quién defiende? OpenAI, con su propio equipo de seguridad interna y el apoyo de las plataformas afectadas. Y ¿quién mira? En este tablero, el CNI español, a través del CCN-CERT, monitoriza de cerca cualquier incidente que pueda afectar a las cadenas de suministro de las empresas y administraciones españolas. Aunque el ataque se ha limitado a dos empleados de la compañía californiana, el hecho de que los certificados comprometidos afecten a aplicaciones de escritorio y móviles de uso masivo eleva el riesgo de que un actor malicioso pudiera haber intentado distribuir malware bajo la apariencia del software legítimo de ChatGPT, si no se hubiera contenido a tiempo.
Clasifico el nivel de material comprometido como Confidencial, según los estándares habituales de las agencias de inteligencia. Los certificados de firma de código robados no solo permiten distribuir software, sino que podrían haber servido para firmar herramientas de spraying de credenciales o blobs maliciosos en redes corporativas. La respuesta de OpenAI, aunque rápida, deja una lección incómoda: la migración a configuraciones reforzadas tras el ataque de Axios aún no había llegado a todos los dispositivos, y fue precisamente esa brecha la que explotó TeamPCP. Es un recordatorio de que las actualizaciones de seguridad no protegen si no se despliegan a tiempo en todos los eslabones de la cadena.
Ya advertí en El quinto elemento que “el próximo 11S empezará con un clic”. Este tipo de incidentes, que explotan la confianza en las herramientas que los desarrolladores usan a diario, demuestran que la línea entre el sabotaje industrial y el ciberataque dirigido se difumina cada vez más. Para el CNI y el CCN-CERT, el caso OpenAI es un aviso a navegantes: si una empresa con los recursos y el talento de OpenAI puede verse comprometida por una cadena de suministro automatizada, cualquier organismo público con menos recursos está igualmente expuesto. La próxima campaña de TeamPCP —o de cualquier otro grupo que copie su tradecraft— podría perfectamente apuntar a dependencias usadas por el sector energético o de telecomunicaciones español.
El cierre del incidente, con la obligación de actualizar las aplicaciones de macOS antes del 12 de junio, marca un hito temporal que nos obliga a seguir de cerca si aparecen signos de abuso de los certificados robados en las próximas semanas. Mientras tanto, el ecosistema de desarrollo open source deberá replantearse si las atestaciones SLSA, tal y como se implementan hoy, ofrecen una garantía suficiente. La confianza ciega en los pipelines automatizados puede ser, como ha demostrado TeamPCP, la puerta de atrás más dulce para un adversario persistente.
