- Una configuración defectuosa en AWS CodeBuild permitió eludir los filtros de seguridad y lanzar compilaciones privilegiadas desde GitHub.
- El fallo, bautizado como CodeBreach por Wiz, pudo exponer repositorios clave como el SDK de JavaScript de AWS y credenciales de alto privilegio.
- AWS corrigió la vulnerabilidad en cuestión de horas, rotó credenciales, revisó todos sus proyectos públicos y asegura no haber detectado explotación maliciosa.
- El incidente subraya la fragilidad de los entornos CI/CD y obliga a reforzar buenas prácticas en Europa y a nivel global: regex anclados, tokens mínimos y bloqueo de PRs no confiables.
Una desconfiguración crítica en AWS CodeBuild ha encendido todas las alarmas en el ecosistema de desarrollo en la nube al evidenciar lo fácil que puede ser comprometer la cadena de suministro de software a través de los sistemas de integración continua. La investigación, liderada por la firma de seguridad en la nube Wiz, demuestra que un error aparentemente menor en los filtros de seguridad de CodeBuild podía abrir la puerta a un control casi total de repositorios clave de GitHub gestionados por Amazon Web Services.
El fallo, bautizado como CodeBreach, afectaba a varios proyectos abiertos de AWS ampliamente utilizados a escala global, entre ellos el SDK de JavaScript que utilizan tanto aplicaciones de clientes como la propia Consola de AWS. Aunque AWS asegura que no hay indicios de explotación real, el incidente muestra hasta qué punto un detalle técnico como dos caracteres ausentes en una expresión regular puede convertirse en un riesgo de gran alcance para empresas europeas y españolas que basan su operativa en servicios en la nube.
Qué es CodeBreach y por qué es tan delicado
Según ha explicado Wiz, la vulnerabilidad se originaba en la forma en que AWS CodeBuild gestionaba los disparadores de compilación vinculados a GitHub. CodeBuild es el servicio de integración continua de AWS que compila, testa y empaqueta código de manera automatizada dentro de las canalizaciones CI/CD, un pilar fundamental para organizaciones que despliegan software con alta frecuencia, incluidas muchas compañías europeas de banca, ecommerce y sector público.
Para proteger estos procesos, AWS permite configurar filtros de webhook basados en ACTOR_ID, es decir, listas de IDs de usuario de GitHub autorizados a lanzar compilaciones privilegiadas. La idea es que solo mantenedores de confianza puedan activar builds que tengan acceso a credenciales sensibles o que puedan publicar nuevas versiones de librerías críticas.
El problema llegó cuando varios repositorios gestionados por AWS —incluidos aws-sdk-js-v3, aws-lc, amazon-corretto-crypto-provider y awslabs/open-data-registry— implementaron esos filtros con expresiones regulares que no estaban correctamente “ancladas”. Les faltaban los símbolos ^ y $, que obligan a que el patrón coincida exactamente con el ID permitido.
Al no estar anclada, la expresión aceptaba cualquier ID de GitHub que contuviera como subcadena un ID autorizado. En la práctica, eso significaba que un atacante podía registrar un nuevo usuario cuyo identificador numérico incluyera el de un mantenedor aprobado y, con ello, saltarse por completo el filtro de seguridad sin necesidad de autenticación previa.
Este matiz técnico, aparentemente menor, se convertía así en un vector de ataque de cadena de suministro con impacto potencial sobre miles de empresas y administraciones que dependen de software y SDKs oficiales de AWS, también dentro de la Unión Europea.
Cómo se explotaba el fallo: de un ID de GitHub a controlar un repositorio
La investigación de Wiz detalla paso a paso cómo un atacante podía pasar de un repositorio público a hacerse con credenciales de administrador en cuestión de minutos. El punto de partida está en que GitHub asigna los IDs de usuario de manera secuencial y actualmente son numéricos de nueve dígitos. Si un mantenedor legítimo tiene un ID de seis dígitos, basta con generar nuevas cuentas hasta que se cree un ID que lo contenga como subcadena.
Para acelerar este proceso, el equipo de Wiz recurrió a GitHub Apps: cada nueva app genera un bot asociado con su propio ID. Automatizando cientos de peticiones de creación de apps, fueron capaces de “cazar” un identificador que incluía el ID de un mantenedor aprobado. De este modo, su bot aparecía a ojos de CodeBuild como un actor de confianza, pese a no estar autorizado en realidad.
Con ese ID predictivo en la mano, el atacante puede enviar un pull request aparentemente legítimo a uno de los repositorios afectados —por ejemplo, el SDK de JavaScript de AWS—. El filtro mal configurado acepta el PR como si viniera de un mantenedor y desencadena una compilación privilegiada en CodeBuild.
Durante esa compilación, el código malicioso incluido en la contribución se ejecuta en el entorno de build y extrae los tokens de GitHub o PAT (Personal Access Tokens) utilizados por el proyecto, que normalmente tienen permisos administrativos sobre el repositorio. En las pruebas de Wiz, lograron obtener el token del usuario automatizado aws-sdk-js-automation, con capacidad para empujar cambios directamente a la rama principal, aprobar PRs y acceder a secretos del repositorio.
A partir de ahí, el escenario es preocupante: un actor malicioso podría inyectar código malicioso en el SDK justo antes de su publicación, robar secretos de producción, alterar dependencias o introducir puertas traseras difíciles de detectar. Para organizaciones europeas que confían en estos SDKs para conectar con la infraestructura de AWS, el impacto habría sido similar al de otros grandes incidentes de cadena de suministro, pero centrado en el “cerebro” que gestiona sus recursos en la nube.
Repositorios afectados y posible alcance en empresas europeas
Los repositorios afectados por esta mala configuración eran proyectos estratégicos del ecosistema AWS, entre ellos:
- aws-sdk-js-v3, el SDK de JavaScript de AWS, utilizado tanto por desarrolladores externos como por la propia Consola de AWS.
- aws-lc, la librería criptográfica de AWS, clave para operaciones seguras.
- amazon-corretto-crypto-provider, componente criptográfico ligado a Amazon Corretto.
- awslabs/open-data-registry, el registro de datos abiertos en AWS.
En todos los casos, la misma debilidad en el filtro ACTOR_ID permitía que un ID numerado como supercadena de uno aprobado desencadenara compilaciones privilegiadas. En uno de los casos, la integración parecía estar vinculada incluso a una cuenta personal de un empleado de AWS, lo que añadía otro ángulo de riesgo.
Wiz subraya que el objetivo más sensible era el SDK de JavaScript de AWS, ya que es una pieza omnipresente: según sus estimaciones, alrededor del 66 % de los entornos en la nube lo utilizan de alguna forma, y uno de esos consumidores es la propia consola web de AWS que administradores de todo el mundo —incluidos los de empresas españolas— usan a diario.
La posibilidad teórica era que una actualización semanal del SDK incluyera un backdoor distribuido de manera masiva, afectando a aplicaciones, servicios internos y herramientas de administración. Debido a la confianza que muchas entidades europeas depositan en los paquetes oficiales de grandes proveedores cloud, un incidente de este tipo tendría un impacto transversal: desde fintechs en Madrid o Berlín hasta administraciones que explotan datos en plataformas abiertas.
Aunque este caso concreto se ha quedado, afortunadamente, en un hallazgo de laboratorio, el vector de ataque no es cualquier proveedor con repositorios abiertos exclusivo de AWS: cualquier proveedor con repositorios abiertos, canalizaciones CI/CD automatizadas y filtros mal diseñados podría encontrarse en una situación muy similar.
Respuesta de AWS: correcciones rápidas y auditoría global
Tras recibir la notificación responsable de Wiz el 25 de agosto de 2025, AWS reaccionó con rapidez. Según su propio comunicado, el equipo mitigó el problema principal —el bypass de actor ID por expresiones regulares sin anclar— en menos de 48 horas, ajustando los filtros afectados para que exigieran coincidencias exactas.
Además de corregir la configuración de los repositorios señalados, la compañía procedió a rotar las credenciales expuestas, reforzar las protecciones de todos los procesos de compilación que manejan tokens de GitHub u otras credenciales en memoria y revisar el diseño de sus canalizaciones públicas. El objetivo declarado era reducir al mínimo el riesgo de que una condición similar volviera a producirse.
En paralelo, AWS llevó a cabo una auditoría completa de otros entornos de compilación públicos y de los registros de actividad asociados, incluidos los logs de CloudTrail. De acuerdo con la versión oficial, este análisis no encontró evidencias de que ningún otro actor hubiera aprovechado este mismo fallo antes de la investigación de Wiz.
La compañía insiste en que se trataba de desconfiguraciones específicas de proyectos y no de una vulnerabilidad general en el servicio CodeBuild en sí. También afirma que, según sus análisis, no hubo impacto sobre la confidencialidad o integridad de entornos de clientes ni sobre la prestación de servicios de AWS.
Más allá de la respuesta técnica, el caso pone de manifiesto la presión regulatoria y de confianza que pesa sobre los grandes proveedores de nube, especialmente en regiones como la Unión Europea, donde normativas como NIS2 y el futuro Reglamento de Ciberresiliencia obligan a mejorar la visibilidad y la protección de cadenas de suministro digitales.
Lecciones para empresas en España y Europa: endurecer la seguridad CI/CD
Los investigadores de Wiz describen CodeBreach como un ejemplo de manual de por qué los entornos de CI/CD se han convertido en un objetivo prioritario para atacantes. Son complejos, orquestan grandes volúmenes de datos y, sobre todo, concentran credenciales privilegiadas y procesos automatizados que pocos revisan con lupa día a día.
Para compañías españolas y europeas que usan CodeBuild, GitHub Actions u otras plataformas, el mensaje es claro: no basta con confiar en la configuración por defecto. Es necesario revisar de forma activa cómo se gestionan los disparadores de compilación, qué permisos tienen los tokens y qué código puede ejecutarse en entornos de build que poseen acceso a secretos delicados.
Entre las medidas de mitigación recomendadas destacan varias que pueden aplicarse tanto en AWS como en otras soluciones CI/CD:
- Asegurarse de que las expresiones regulares de filtros de webhook estén correctamente ancladas con ^ y $, evitando coincidencias parciales de IDs.
- Impedir que contribuciones no confiables, como PRs desde forks externos, desencadenen compilaciones con privilegios elevados.
- Habilitar mecanismos adicionales como el Pull Request Comment Approval en CodeBuild, de forma que una persona autorizada valide expresamente qué PR puede ejecutar un build privilegiado.
- Emplear tokens de GitHub de alcance mínimo, idealmente uno distinto por proyecto, y limitar sus permisos al estricto necesario para el flujo de trabajo.
- Valorar el uso de cuentas de GitHub dedicadas y poco privilegiadas para integraciones de CI/CD, en lugar de tokens vinculados a usuarios humanos con permisos amplios.
En Europa, donde muchas organizaciones manejan datos especialmente sensibles —sanidad, administración electrónica, infraestructuras críticas—, este tipo de buenas prácticas se alinean, además, con la creciente exigencia de demostrar debida diligencia en ciberseguridad. Un incidente de cadena de suministro que afecte a bibliotecas ampliamente distribuidas podría tener implicaciones regulatorias, reputacionales y económicas significativas.
El caso CodeBreach se enmarca también en una serie de investigaciones recientes sobre debilidades en flujos de trabajo de CI/CD, desde problemas con GitHub Actions y el disparador pull_request_target hasta incidentes en extensiones de desarrollo como Amazon Q para VS Code. El hilo común: pequeñas decisiones de diseño en automatizaciones críticas pueden abrir grandes agujeros si no se revisen con criterio de seguridad.
El episodio de CodeBreach ilustra hasta qué punto una simple configuración descuidada en la automatización de builds puede convertirse en un riesgo sistémico para la cadena de suministro de software, especialmente cuando se ve involucrado un proveedor tan extendido como AWS. Aunque la vulnerabilidad se descubrió y corrigió a tiempo, sin explotación conocida, el incidente deja claro que las organizaciones europeas que apoyan su actividad en servicios cloud deben mirar con lupa sus canalizaciones CI/CD, endurecer permisos, anclar sus filtros y tratar cada paso automatizado como un posible punto de entrada. La enseñanza de fondo es incómoda pero útil: la seguridad de la nube no solo depende del proveedor, sino también de cómo se construye y se protege el software que corre sobre ella.
