OpenAI Codex: 29.000 descargas robando tokens de devs

¿Qué pasó con el paquete codexui-android?

29.000 descargas semanales y un mes robando credenciales sin que nadie lo notara. El paquete npm codexui-android, que se presentaba como una interfaz legítima para OpenAI Codex, estuvo exfiltrando tokens de autenticación de desarrolladores desde la versión 0.1.82 en adelante.

El ataque no fue detectado hasta que investigadores de seguridad identificaron tráfico sospechoso hacia sentry.anyclaw[.]store, un dominio registrado apenas dos días después del primer upload del paquete. Para founders que dependen de herramientas de IA en su stack tecnológico, esto representa una vulnerabilidad crítica en la cadena de suministro de software.

¿Cómo funcionaba el ataque de supply chain?

La sofisticación del ataque radicaba en su invisibilidad. El paquete mantenía un repositorio activo en GitHub con historial de desarrollo estable, generando confianza en la comunidad. Sin embargo, el código publicado en npm difería del código fuente visible: incluía lógica maliciosa que se ejecutaba antes del código funcional visible.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

El flujo del ataque seguía estos pasos:

Localización del archivo ~/.codex/auth.json en el sistema del desarrollador
Extracción silenciosa de access_token, refresh_token, id_token y account ID
Cifrado y codificación en base64 para evadir detección
Envío al servidor atacante disfrazado como telemetría de Sentry

El endpoint de exfiltración se camuflaba como monitorización legítima, incluso con referencias tipo Sentry y ofuscación para evadir análisis automatizados de paquetes npm.

¿Qué tokens fueron comprometidos y por qué es grave?

El paquete robaba cuatro tipos de credenciales críticas:

Access token: permite acceso inmediato a la API de Codex
Refresh token: el más peligroso, no expira y permite suplantación indefinida
ID token: identifica la cuenta del desarrollador
Account ID: identificador único de la cuenta OpenAI

La gravedad del refresh_token no puede subestimarse: a diferencia de las contraseñas tradicionales, este token permite mantener acceso persistente sin necesidad de reautenticación. Un atacante con este token puede operar como el desarrollador legítimo durante meses, accediendo a repositorios privados, consumiendo cuota de API o incluso inyectando código malicioso en proyectos.

El autor identificado como "friuns" (Igor Levochkin) cambió su versión del paquete al ser confrontado, pero el daño ya estaba hecho. Las apps Android de BrutalStrike en Google Play, con más de 60.000 descargas combinadas, también distribuían este paquete npm en un sandbox PRoot sin version pinning, recibiendo el código malicioso automáticamente.

Antecedentes: la campaña Mini Shai-Hulud y TanStack

Este ataque no ocurre en el vacío. En mayo de 2026, OpenAI confirmó que la campaña Mini Shai-Hulud comprometió dos dispositivos internos de empleados a través de paquetes npm de TanStack. Aunque no hubo acceso a datos de usuarios, la empresa tuvo que rotar certificados y actualizar obligatoriamente clientes macOS.

La campaña Mini Shai-Hulud afectó más de 170 paquetes entre npm y PyPI, con más de 518 millones de descargas acumuladas. Esto ilustra la magnitud del riesgo de supply chain para herramientas usadas por desarrolladores, incluidas las de IA.

La diferencia clave con codexui-android es el objetivo: mientras TanStack buscaba compromiso general del ecosistema npm, este ataque se enfocó específicamente en tokens de desarrolladores de Codex y acceso persistente a cuentas OpenAI. Ambos casos comparten el mismo patrón: código malicioso distribuido como herramienta legítima, explotando la confianza en extensiones y paquetes del ecosistema developer.

¿Qué significa esto para tu startup?

Si tu startup usa herramientas de IA para desarrollo (Codex, GitHub Copilot, Cursor, etc.), este incidente debe activar alertas inmediatas. Los tokens de AI coding tools se han vuelto infraestructura crítica y deben tratarse con el mismo nivel de seguridad que las contraseñas de producción o las claves de deployment.

El riesgo para startups es triple:

Exposición de código propietario: un refresh_token robado puede dar acceso a repositorios privados donde se desarrolla tu core technology
Gasto no autorizado de API: atacantes pueden consumir tu quota de OpenAI, generando costos inesperados
Compromiso de la cadena de build: si el atacante accede a tu CI/CD, puede inyectar vulnerabilidades en tus releases

En startups con pipelines rápidos y poca segmentación de entornos, un paquete malicioso puede propagarse desde una estación de trabajo a múltiples repositorios si los tokens robados tienen permisos amplios. El coste operativo incluye rotación de secretos, revisión de dependencias, pausas de despliegue y potenciales interrupciones por actualización obligatoria.

Acciones concretas que debes implementar hoy

No esperes a que te afecte. Estas son las acciones que todo founder técnico debe implementar esta semana:

1. Auditoría inmediata de dependencias: Revisa tu package.json y lockfile buscando codexui-android o paquetes similares. Usa npm audit y herramientas como npm ls para identificar dependencias transitivas.
2. Version pinning obligatorio: Fija versiones exactas en tu package.json (ej. "package": "1.2.3" en lugar de "^1.2.3"). Evita dependencias flotantes para herramientas de build y de IA.
3. Rotación preventiva de tokens: Si usaste OpenAI Codex en los últimos 30 días, revoca y rota todos los tokens inmediatamente desde el dashboard de OpenAI. No asumas que no fuiste afectado.
4. Segmentación de credenciales: Separa tokens de desarrollo, staging y producción. Nunca reutilices secretos de producción en flujos de CI/CD o pruebas locales.
5. Monitorización de tráfico saliente: Implementa reglas en tu firewall o usa herramientas como Little Snitch para detectar conexiones a dominios no autorizados. El ataque usó sentry.anyclaw[.]store como endpoint.
6. Revisión de workflows de GitHub Actions: Verifica permisos de tokens, uso de cachés compartidas entre pull requests y releases. La campaña TanStack explotó estos vectores.

Mejores prácticas de seguridad para el ecosistema AI developer tools

La lección de codexui-android es clara: la conveniencia no puede superar a la seguridad. Las siguientes prácticas deben convertirse en estándar para cualquier startup que use herramientas de IA en su desarrollo:

Verificación de artefactos: Cuando sea posible, compara el paquete publicado en npm con el código fuente visible en GitHub. El ataque a Codex explotó precisamente la discrepancia entre el repo visible y lo publicado.

Supervisión continua: Suscríbete a alertas de seguridad de npm, GitHub Security Advisories y feeds especializados como AI Weekly. Los ataques de supply chain se detectan cada vez más rápido, pero solo si estás monitoreando.

Política de actualización: Establece un proceso formal para actualizar dependencias. No actualices automáticamente en producción. Prueba en staging, revisa changelogs y verifica que no haya cambios sospechosos en el código.

Segmentación de acceso: Limita los permisos de los tokens de IA al mínimo necesario. Un token de desarrollo no debería tener acceso a repositorios de producción ni a billing.

Cultura de seguridad: Educa a tu equipo sobre los riesgos de supply chain. Un desarrollador que instala paquetes sin verificar es el eslabón más débil. Haz de la verificación de dependencias parte de tu code review process.

El ecosistema hispanohablante no es inmune

Startups en España y LATAM usan las mismas herramientas que Silicon Valley. De hecho, la presión por mover rápido con equipos pequeños puede aumentar la tentación de instalar paquetes sin auditoría profunda. El ataque a codexui-android afectó usuarios globalmente, sin distinción geográfica.

En mercados emergentes donde el capital es más escaso y los equipos más pequeños, la automatización con IA es aún más crítica. Esto hace que la seguridad de estas herramientas sea prioritaria: un compromiso puede significar la pérdida de meses de desarrollo o la exposición de IP crítica a competidores.

La buena noticia: las mismas prácticas que protegen contra supply chain attacks también mejoran tu postura general de seguridad. Version pinning, auditorías de dependencias y segmentación de credenciales son inversiones que pagan dividendos más allá de este incidente específico.