Una mala configuración crítica en CodeBuild de Amazon Web Services (AWS) podría haber permitido la adquisición completa de los propios repositorios GitHub del proveedor de servicios en la nube, incluido su SDK de JavaScript de AWS, poniendo en riesgo todos los entornos de AWS.
La vulnerabilidad ha sido nombrada en código. Violación de código por la empresa de seguridad en la nube Wiz. AWS solucionó el problema en septiembre de 2025 tras la divulgación responsable el 25 de agosto de 2025.
«Al explotar CodeBreach, los atacantes podrían haber inyectado código malicioso para lanzar un compromiso en toda la plataforma, afectando potencialmente no sólo a las innumerables aplicaciones que dependen del SDK, sino a la consola misma, amenazando cada cuenta de AWS», dijeron los investigadores Yuval Avrahami y Nir Ohfeld en un informe compartido con The Hacker News.
La falla, señaló Wiz, es el resultado de una debilidad en los canales de integración continua (CI) que podría haber permitido a atacantes no autenticados violar el entorno de construcción, filtrar credenciales privilegiadas como tokens de administrador de GitHub y luego usarlas para impulsar cambios maliciosos en el repositorio comprometido, creando una vía para ataques a la cadena de suministro.
Dicho de otra manera, el problema socava los filtros de webhook introducidos por AWS para garantizar que solo ciertos eventos desencadenen una compilación de CI. Por ejemplo, AWS CodeBuild se puede configurar de manera que se active una compilación solo cuando los cambios de código se confirman en una rama específica o cuando un ID de cuenta de GitHub o GitHub Enterprise Server (también conocido como ACTOR_ID o ID de actor) coincide con el patrón de expresión regular. Estos filtros sirven para proteger contra solicitudes de extracción que no son de confianza.
La configuración incorrecta afectó a los siguientes repositorios de GitHub de código abierto administrados por AWS, que están configurados para ejecutar compilaciones en solicitudes de extracción:
- aws-sdk-js-v3
- aws-lc
- amazon-corretto-proveedor-de-criptos
- awslabs/registro-de-datos-abiertos
Los cuatro proyectos, que implementaron un filtro ACTOR_ID, sufrieron un «defecto fatal» al no incluir dos caracteres para garantizar (es decir, los anclajes inicial ^ y final $) necesarios para producir una coincidencia exacta de expresión regular (regex). En cambio, el patrón de expresiones regulares permitía que cualquier ID de usuario de GitHub que fuera una supercadena de un ID aprobado (por ejemplo, 755743) omitiera el filtro y activara la compilación.
Debido a que GitHub asigna ID de usuario numéricos de forma secuencial, Wiz dijo que podía predecir que los nuevos ID de usuario (actualmente de 9 dígitos) «eclipsarían» el ID de seis dígitos de un mantenedor confiable aproximadamente cada cinco días. Esta información, junto con el uso de GitHub Apps para automatizar la creación de aplicaciones (que, a su vez, crea un usuario de bot correspondiente), hizo posible generar una identificación de destino (por ejemplo, 226755743) al activar cientos de nuevos registros de usuarios de bot.
Armado con el ID del actor, un atacante ahora puede desencadenar una compilación y obtener las credenciales de GitHub del proyecto CodeBuild aws-sdk-js-v3, un token de acceso personal (PAT) que pertenece al usuario de aws-sdk-js-automation, que tiene privilegios de administrador completos sobre el repositorio.
El atacante puede utilizar este acceso elevado como arma para enviar código directamente a la sucursal principal, aprobar solicitudes de extracción y filtrar secretos del repositorio, lo que eventualmente preparará el escenario para ataques a la cadena de suministro.
«Las expresiones regulares configuradas de los repositorios anteriores para los filtros de webhook de AWS CodeBuild destinados a limitar las ID de actores confiables fueron insuficientes, lo que permitió que una ID de actor adquirida de manera predecible obtuviera permisos administrativos para los repositorios afectados», dijo AWS en un aviso publicado hoy.
«Podemos confirmar que se trataba de configuraciones erróneas específicas del proyecto en los filtros de ID de actor de webhook para estos repositorios y no un problema en el servicio CodeBuild en sí».
Amazon también dijo que solucionó los problemas identificados, además de implementar mitigaciones adicionales, como rotaciones de credenciales y pasos para proteger los procesos de compilación que contienen tokens de GitHub o cualquier otra credencial en la memoria. Además, enfatizó que no encontró evidencia de que CodeBreach haya sido explotado en la naturaleza.
Para mitigar tales riesgos, es esencial que las contribuciones que no son de confianza no activen canales de CI/CD privilegiados al habilitar la nueva puerta de compilación Pull Request Comment Approval, usar ejecutores alojados en CodeBuild para administrar los activadores de compilación a través de flujos de trabajo de GitHub, garantizar que los patrones de expresiones regulares en los filtros de webhook estén anclados, generar una PAT única para cada proyecto de CodeBuild, limitar los permisos de PAT al mínimo requerido y considerar el uso de una cuenta de GitHub dedicada sin privilegios para Integración con CodeBuild.
«Esta vulnerabilidad es un ejemplo de libro de texto de por qué los adversarios apuntan a entornos CI/CD: una falla sutil, que fácilmente se pasa por alto y que puede explotarse para lograr un impacto masivo», señalaron los investigadores de Wiz. «Esta combinación de complejidad, datos no confiables y credenciales privilegiadas crea una tormenta perfecta para violaciones de alto impacto que no requieren acceso previo».
Esta no es la primera vez que la seguridad del oleoducto CI/CD ha sido objeto de escrutinio. El año pasado, una investigación de Sysdig detalló cómo los flujos de trabajo inseguros de GitHub Actions asociados con el disparador pull_request_target podrían explotarse para filtrar el GITHUB_TOKEN privilegiado y obtener acceso no autorizado a docenas de proyectos de código abierto mediante el uso de una única solicitud de extracción desde una bifurcación.
Un análisis similar de dos partes de Orca Security encontró pull_request_target inseguro en proyectos de Google, Microsoft, NVIDIA y otras compañías Fortune 500 que podrían haber permitido a los atacantes ejecutar código arbitrario, filtrar secretos confidenciales y enviar código malicioso o dependencias a sucursales confiables. El fenómeno ha sido denominado pull_request_nightmare.
«Al abusar de flujos de trabajo mal configurados activados a través de pull_request_target, los adversarios podrían pasar de una solicitud de extracción bifurcada que no es de confianza a una ejecución remota de código (RCE) en corredores alojados en GitHub o incluso autohospedados», señaló el investigador de seguridad Roi Nisimi.
«Los flujos de trabajo de GitHub Actions que utilizan pull_request_target nunca deben verificar código que no sea de confianza sin una validación adecuada. Una vez que lo hacen, corren el riesgo de verse comprometidos por completo».