Tokens de autenticación de OpenAI Codex robados en ataque a la cadena de suministro de npm
El riesgo en la cadena de suministro tradicionalmente se ha centrado en las dependencias de software que introducen vulnerabilidades en productos compilados, como ocurrió en los casos de SolarWinds y XZ Utils. El robo de tokens de Codex representa un modelo diferente. El paquete comprometido no introduce una vulnerabilidad en el código del desarrollador; extrae credenciales del entorno del desarrollador mientras trabaja.
El ciclo de vida del ataque sigue un patrón predecible: se publica un paquete funcional que obtiene descargas a través de canales habituales; el paquete se mantiene y actualiza, generando un historial de commits que transmite legitimidad; en algún momento se añade código para recolectar credenciales; y como el paquete funciona correctamente, los desarrolladores no lo examinan a fondo. La exfiltración opera silenciosamente durante semanas o meses antes de ser detectada.
La calidad del disfraz en el caso de Codex es reveladora. Las credenciales robadas se enviaron a un endpoint de servidor que imitaba una integración de reporte de errores de Sentry, un servicio que recibe telemetría de herramientas de desarrollo de manera rutinaria. La monitorización de red que alerta sobre conexiones salientes a dominios desconocidos no marcaría una conexión que parece ser de Sentry. El atacante anticipó y superó el mecanismo de detección más común para la exfiltración de datos salientes.
Los programas de administración de riesgos de proveedores que evalúan la postura de seguridad de los proveedores de software deben ampliar su alcance para incluir los ecosistemas de paquetes en los que operan esos proveedores. Un paquete npm es una relación con un proveedor sin proceso de adquisición asociado.
5 conclusiones clave
1. Un paquete npm funcional robó silenciosamente tokens OAuth de Codex durante un mes.
«codexui-android», con aproximadamente 29,000 descargas semanales, recolectó tokens de autenticación de OpenAI Codex desde el almacenamiento local y envió paquetes completos de credenciales OAuth a un servidor controlado por el atacante disfrazado como endpoint de Sentry. La misma lógica de exfiltración apareció en dos aplicaciones Android con más de 60,000 descargas en total. El paquete cumplía su función anunciada mientras la recolección de credenciales operaba en segundo plano, sin dar ninguna señal de comportamiento anómalo a los desarrolladores. Los escaneos previos a la publicación en la cadena de suministro no detectan este patrón.
2. Los tokens de actualización no expiran, lo que hace que este robo sea especialmente persistente.
El archivo ~/.codex/auth.json robado contenía tokens de actualización, no solo tokens de acceso. Un atacante que posee un token de actualización puede suplantar silenciosamente a la víctima de manera indefinida, generando nuevos tokens de acceso según sea necesario sin activar ningún desafío de reautenticación. La mayoría de las víctimas de robo de credenciales no saben que han sido afectadas y, por lo tanto, no revocan nada, lo que hace que la verificación contextual continua sea un control más duradero que la expiración de tokens.
3. El almacenamiento de credenciales en texto plano es un riesgo sistémico en las cadenas de herramientas de desarrollo.
Cualquier paquete que instale un desarrollador puede tener acceso a todas las credenciales almacenadas en el directorio personal. Este mismo patrón se observa en las interfaces de línea de comandos de proveedores de nube, sistemas de control de versiones, registros de contenedores y proveedores de servicios de IA, que suelen almacenar credenciales en archivos locales en texto plano. Los marcos de administración de riesgos de proveedores diseñados para proveedores SaaS necesitan un marco equivalente para dependencias de paquetes de código abierto.
4. Las credenciales de desarrollador de IA robadas pueden llegar a sistemas de datos empresariales mucho más allá de la estación de trabajo.
Los tokens de Codex otorgan acceso a cualquier sistema empresarial al que el desarrollador tenga conexión: entornos de uso compartido de archivos, flujos de MFT, repositorios de contenido y APIs internas. Un atacante que opere con credenciales válidas de desarrollador puede interactuar con estos sistemas a través de flujos de trabajo mediados por IA que parecen completamente normales para los sistemas de registro de auditoría que buscan comportamientos humanos anómalos.
5. La aplicación de acceso de confianza cero limita las consecuencias incluso cuando se roban credenciales.
Las condiciones de política asociadas a los datos sensibles, no solo la identidad de la credencial, determinan si se concede el acceso. La protección de datos de confianza cero significa que un token robado presentado desde una ubicación inesperada, en un horario inusual o solicitando datos fuera del alcance habitual, puede fallar la evaluación de políticas aunque el token sea técnicamente válido. El Secure MCP Server de Kiteworks crea el punto de control que los tokens controlados por atacantes no pueden eludir.
Confías en que tu organización es segura. Pero ¿puedes comprobarlo?
Léelo ahora
Por qué el almacenamiento de credenciales en texto plano es un riesgo sistémico
El archivo ~/.codex/auth.json almacena credenciales OAuth en texto plano porque es la vía de menor resistencia para las herramientas de desarrollo. Los desarrolladores necesitan que sus herramientas se autentiquen sin fricción. Los archivos de credenciales en el sistema de archivos local, legibles por cualquier proceso que ejecute el desarrollador, resuelven ese problema de manera eficiente, pero también crean un único punto de fallo: cualquier proceso con acceso de lectura al sistema de archivos puede recolectar todo lo necesario para suplantar la cuenta.
Esto no es un problema exclusivo de Codex. El mismo patrón se repite en las cadenas de herramientas de desarrollo: las interfaces de línea de comandos de proveedores de nube, sistemas de control de versiones, registros de contenedores y proveedores de servicios de IA suelen almacenar credenciales en archivos locales en texto plano. Los equipos de seguridad enfocados en controles de acceso a nivel de red y defensas perimetrales a menudo pasan por alto por completo esta superficie local de credenciales.
Cualquier paquete que instale un desarrollador puede tener acceso a todas las credenciales almacenadas en el directorio personal. Los marcos de administración de riesgos de terceros diseñados para proveedores SaaS y de nube necesitan un marco equivalente para dependencias de paquetes de código abierto. Las credenciales en reposo deben recibir el mismo tratamiento que los datos sensibles en reposo: cifrado con claves almacenadas por separado del material cifrado.
Cómo las credenciales de IA robadas se convierten en brechas de datos empresariales
El robo de tokens de Codex no es solo un compromiso de cuenta; es el primer paso en una cadena que puede terminar en la exfiltración de datos empresariales. Un desarrollador instala un paquete malicioso; el paquete recolecta credenciales de Codex; el atacante usa esas credenciales para acceder a los sistemas empresariales a los que puede llegar la cuenta del desarrollador; luego el atacante extrae contenido confidencial a través de canales que son indistinguibles de la actividad legítima del desarrollador.
Los sistemas de datos empresariales más expuestos son aquellos a los que las herramientas de IA se conectan cada vez más: repositorios de documentos, plataformas de uso compartido seguro de archivos, salas de datos virtuales y flujos de transferencia de archivos gestionados. Estos sistemas contienen contratos, datos financieros, propiedad intelectual e información personal regulada. Un atacante que opere con credenciales de Codex de un desarrollador puede interactuar con estos sistemas mediante flujos de trabajo mediados por IA que parecen completamente normales para los sistemas de registro de auditoría que buscan comportamientos humanos anómalos.
Kiteworks interrumpe esta cadena en la capa de acceso a los datos. El Secure MCP Server controla qué herramientas de IA pueden interactuar con los datos empresariales; si la identidad de una herramienta o el contexto de la política no coincide con el conjunto permitido, no puede acceder a los datos sin importar las credenciales que presente. La aplicación de ABAC va más allá: evalúa no solo quién solicita, sino qué atributos describen la solicitud, los datos y el contexto operativo. Un token robado presentado desde una ubicación geográfica inesperada, en un horario inusual o solicitando datos fuera del alcance habitual del desarrollador, puede fallar la evaluación de políticas aunque el token sea válido.
Cómo responder ante compromisos en la cadena de suministro de herramientas de IA
Cuando ocurre un robo de credenciales de este tipo, la respuesta debe abordar dos frentes en paralelo: contener la exposición inmediata y establecer controles que eviten recurrencias. La contención inmediata requiere revocar todos los tokens potencialmente comprometidos; cualquier desarrollador que haya instalado el paquete afectado durante el periodo de exposición debe considerar sus credenciales auth.json como comprometidas. La revocación de tokens es una acción manual en la mayoría de las implementaciones OAuth, y las organizaciones que no tienen un inventario de qué desarrolladores poseen credenciales de qué servicios tendrán dificultades para ejecutarla de manera integral.
Un plan de respuesta a incidentes que contemple compromisos en cadenas de herramientas de IA debe incluir la detección automatizada de accesos a archivos de credenciales por procesos no autorizados, procedimientos de revocación de tokens con alcance empresarial y una revisión de a qué sistemas empresariales pueden acceder las credenciales de herramientas de IA de los desarrolladores. Los registros de auditoría que capturen accesos a datos mediados por IA son esenciales para determinar a qué tuvo acceso realmente un atacante durante el periodo de exposición, la base de evidencia que determina si se vieron involucrados datos regulados.
Para saber más sobre cómo proteger tus datos sensibles frente a ataques en la cadena de suministro de IA, solicita una demo personalizada hoy mismo.
Preguntas frecuentes
El atacante redirigió las credenciales robadas a un endpoint que imitaba una integración de reporte de errores de Sentry, un tráfico que la mayoría de las monitorizaciones de red no marcarían. Además, el paquete funcionaba correctamente, sin dar señales de comportamiento anómalo a los desarrolladores. Los escaneos de registros previos a la publicación buscan firmas maliciosas conocidas, pero no realizan simulaciones de comportamiento que revelarían el acceso a credenciales en tiempo de ejecución. Los controles de administración de riesgos en la cadena de suministro deben incluir análisis de comportamiento en tiempo real de los paquetes instalados, no solo verificaciones de firmas al instalar.
Los tokens de acceso expiran tras minutos u horas. Los tokens de actualización generan nuevos tokens de acceso indefinidamente hasta que se revocan explícitamente, y la mayoría de las víctimas no saben que han sido robadas, por lo que nunca los revocan. Los principios de confianza cero abordan esto mediante una verificación contextual continua: marcando tokens usados en contextos anómalos aunque sean técnicamente válidos. La aplicación de ABAC de Kiteworks aplica esta evaluación contextual a cada solicitud de acceso a datos, independientemente de la validez del token.
Sí. Las credenciales OAuth deberían guardarse en almacenes de claves gestionados por la plataforma, como el llavero de macOS, el Administrador de Credenciales de Windows o un módulo de seguridad de hardware para implementaciones empresariales, y no en archivos JSON en texto plano en el directorio personal. Los almacenes de claves de la plataforma requieren autenticación explícita del usuario antes de liberar las credenciales, lo que dificulta considerablemente el acceso silencioso en segundo plano por parte de un paquete malicioso. Las organizaciones también deberían auditar periódicamente qué herramientas de desarrollo pueden acceder a credenciales de sistemas empresariales como parte de su programa de administración de riesgos de proveedores.
Depende de a qué sistemas empresariales puedan acceder esas credenciales. Si autorizan el acceso a repositorios de documentos, plataformas de uso compartido seguro de archivos o flujos de MFT, un atacante puede interactuar con esos sistemas mediante flujos de trabajo mediados por IA. Los datos regulados — PHI protegida por HIPAA, datos personales cubiertos por GDPR, CUI bajo CMMC — quedan expuestos directamente. Trata las credenciales de herramientas de IA comprometidas con la misma urgencia que las credenciales privilegiadas comprometidas.
Kiteworks aplica la política de acceso en la capa de datos, no solo en la autenticación. El Secure MCP Server controla qué herramientas de IA están autorizadas a interactuar con los datos empresariales; una identidad de herramienta no reconocida no puede acceder a contenido protegido sin importar las credenciales presentadas. La puerta de enlace de datos IA y la aplicación de ABAC evalúan todo el contexto de la solicitud — identidad, herramienta, clasificación de datos, entorno y patrones de comportamiento — por lo que un token robado usado en un contexto anómalo falla la evaluación de políticas aunque aún no haya sido revocado. Cada interacción genera una pista de auditoría a prueba de manipulaciones.
Recursos adicionales
- Artículo del Blog
Estrategias de confianza cero para una protección de privacidad de IA asequible - Artículo del Blog
Cómo el 77% de las organizaciones falla en la seguridad de datos de IA - eBook
Brecha de gobernanza de IA: por qué el 91% de las pequeñas empresas juega a la ruleta rusa con la seguridad de datos en 2025 - Artículo del Blog
No existe un «–dangerously-skip-permissions» para tus datos - Artículo del Blog
Los reguladores ya no preguntan si tienes una política de IA. Quieren pruebas de que funciona.