OpenAI, Axios y Trivy: qué revela la nueva ola de ataques a la cadena de suministro de software

CyberSecureFox

OpenAI ha revelado nuevos detalles sobre un incidente de ataque a la cadena de suministro de software en el que un paquete npm comprometido, Axios, fue ejecutado dentro de sus workflows de GitHub Actions para la firma de aplicaciones macOS. Según la compañía, no se han visto afectados datos de clientes ni sistemas internos, pero el certificado de firma de código utilizado para sus aplicaciones de escritorio se considera potencialmente comprometido y está siendo revocado.

Cómo Axios comprometido entró en la cadena de suministro de OpenAI

Compromiso del paquete Axios y backdoor WAVESHAPER.V2

A finales de marzo, Google Threat Intelligence Group vinculó la compromisión del popular cliente HTTP Axios con la operación norcoreana UNC1069. Los atacantes lograron acceso a la cuenta de mantenimiento en npm y publicaron dos versiones maliciosas: 1.14.1 y 0.30.4.

Estas versiones introducían una dependencia falsa llamada plain-crypto-js, que desplegaba un backdoor multiplataforma identificado como WAVESHAPER.V2. La carga maliciosa estaba diseñada para ejecutarse en Windows, macOS y Linux, encajando plenamente en el patrón de una supply chain attack: en lugar de comprometer directamente el software final, se atacan componentes de confianza dentro del ecosistema open source.

Impacto en el proceso de firma de aplicaciones macOS de OpenAI

OpenAI confirmó que uno de sus workflows de GitHub Actions, utilizado en el proceso de firma de aplicaciones para macOS, descargó y ejecutó Axios 1.14.1 el 31 de marzo. Ese pipeline tenía acceso al certificado de firma y al material de notarización empleados para firmar productos como ChatGPT Desktop, Codex, Codex CLI y Atlas.

Tras un análisis forense interno, OpenAI considera que la exfiltración de la clave privada es poco probable, debido a la secuencia concreta de pasos del job, al momento en que se inyecta el certificado y a otros controles técnicos. Sin embargo, siguiendo el principio de precaución, la organización trata el certificado como si estuviese comprometido y procederá a su revocación y rotación.

Revocación del certificado macOS de OpenAI y consecuencias para los usuarios

Como medida de contención, OpenAI está llevando a cabo la revocación y sustitución del certificado de firma de código para macOS. Esto implica que las versiones antiguas de los clientes de escritorio dejarán de recibir soporte y actualizaciones, y a partir del 8 de mayo de 2026 serán bloqueadas por los mecanismos de seguridad de macOS al intentar descargarlas o ejecutarlas.

En coordinación con Apple, se está impidiendo que el software firmado con el certificado antiguo pueda conseguir nuevas notarizaciones. Durante un periodo transitorio de 30 días, se recomienda a los usuarios actualizar a versiones firmadas con el nuevo certificado para evitar interrupciones de servicio.

El riesgo en caso de compromiso real del certificado es crítico: terceros podrían firmar malware haciéndolo pasar por software legítimo de OpenAI. Aunque la emisión de nuevas notarizaciones con el certificado antiguo se ha bloqueado, persiste el factor humano: un usuario puede ignorar manualmente las advertencias de macOS y ejecutar binarios potencialmente maliciosos.

Una campaña más amplia: Trivy, TeamPCP y la vulnerabilidad CVE‑2026‑33634

El incidente con Axios es solo una pieza de una campaña más extensa contra el ecosistema open source. En paralelo, otra operación tuvo como objetivo el escáner de vulnerabilidades Trivy, muy utilizado en entornos cloud y contenedores, y mantenido por Aqua Security. Esta rama se atribuye al grupo criminal TeamPCP (UNC6780).

Al inyectar código malicioso en la cadena de suministro de Trivy, los atacantes desplegaron una funcionalidad de robo de credenciales SANDCLOCK. Con los secretos sustraídos, comprometieron múltiples paquetes npm y propagaron el gusano autorreplicable CanisterWorm. Esos mismos secretos se emplearon para manipular workflows de GitHub Actions de compañías como Checkmarx y para publicar versiones maliciosas de LiteLLM y Telnyx en PyPI.

Investigaciones de Trend Micro muestran una rápida evolución de las tácticas: desde simples cadenas Base64 en pipelines hasta el uso de esteganografía en archivos WAV y la infección simultánea de Linux y Windows, con especial persistencia en este último. En Windows, una versión maliciosa del SDK de Telnyx lanzaba msbuild.exe, que extraía desde una imagen PNG el cargador DonutLoader y, posteriormente, un troyano con un beacon asociado al framework de mando y control AdaptixC2.

Esta campaña ha sido catalogada como CVE‑2026‑33634 y añadida al listado Known Exploited Vulnerabilities de CISA, obligando a las agencias federales estadounidenses a implementar mitigaciones antes del 9 de abril de 2026. Según GitGuardian, el workflow malicioso trivy-action se ejecutó al menos en 474 repositorios públicos, y cerca de 1750 paquetes de Python heredaron versiones infectadas de dependencias. Google estima que estas operaciones han expuesto cientos de miles de secretos robados, con potencial para nuevas supply chain attacks, ataques a SaaS, extorsión y robo de criptoactivos.

Por qué se atacan herramientas de seguridad y cómo reforzar la cadena de suministro

Un aspecto especialmente preocupante es la focalización en herramientas con altos privilegios: escáneres de vulnerabilidades, pipelines CI/CD, infraestructura de IA y sistemas de automatización. Tal y como subraya el cibercomando del FBI, la compromisión de las propias herramientas de seguridad abre la puerta a los entornos más sensibles, ya que por diseño se les otorga confianza y acceso ampliado.

La experiencia reciente confirma el principio formulado por responsables de seguridad de la industria: en entornos DevOps modernos, la confianza debe ser verificable y no asumida. En la práctica, esto implica apostar por imágenes base verificadas en lugar de builds comunitarias aleatorias, usar versiones fijadas (pinned versions) en vez de etiquetas flotantes como latest, gestionar secretos mínimos y de vida corta en lugar de tokens permanentes, y desplegar runners de CI aislados en vez de entornos compartidos y poco segmentados.

Los ataques contra Axios, Trivy y las bibliotecas derivadas demuestran que la principal superficie de riesgo hoy es la automatización: GitHub Actions, pipelines CI/CD, gestores de dependencias y escáneres de código. Las organizaciones deberían priorizar un inventario exhaustivo de su cadena de suministro de software, habilitar escaneo continuo de secretos, controlar el uso de dependencias open source, monitorizar anomalías en pipelines y revisar de forma periódica el posible impacto de campañas conocidas como CVE‑2026‑33634. Cuanto antes se construya un circuito transparente y controlado desde el código fuente hasta producción, menor será la probabilidad de que la próxima ola de ataques a la cadena de suministro las tome por sorpresa.

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.