La mayoría de los equipos conciben una vulnerabilidad de escalada de privilegios como un error del kernel o un uso indebido. sudo en un servidor de producción. En 2026, la versión más peligrosa reside en otro lugar: en el pipeline que construye y distribuye tu código. Un CI/CD El trabajo habitualmente mantiene acceso de escritura a sus repositorios, tokens para sus registros de paquetes y credenciales para su nube. Un atacante que consiga ejecutar código dentro de ese trabajo no necesita escalar mucho. pipeline ya lo ha hecho por ellos.
Esta guía explica cómo se ve una vulnerabilidad de escalada de privilegios en CI/CD pipelineEl libro analiza los contenedores y las rutas más comunes que utilizan los atacantes, y muestra cómo cerrar cada una de ellas.
TL;DR: vulnerabilidad de escalada de privilegios en CI/CD pipelines
En un pipeline, el atacante a menudo no necesita escalar privilegios. pipeline ya los tiene. Una vulnerabilidad de escalada de privilegios en CI/CD Por lo general, se trata de un permiso más amplio de lo que la tarea necesita, esperando que se ejecute código no confiable dentro de él.
- PipelineLos s son privilegiados por diseño. Leen el código fuente, gestionan Secretos, publican artefactos y los implementan en producción, lo que los convierte en uno de los objetivos de escalamiento más valiosos de su organización.
- La mayoría de las vías de escalada de vulnerabilidades se deben a configuraciones incorrectas, no a exploits. Tokens predeterminados amplios,
pull_request_targetLos flujos de trabajo que ejecutan código bifurcado y las claves en la nube de larga duración causan más daño que cualquier vulnerabilidad de día cero. - La escalada de privilegios de contenedor convierte una tarea en el ejecutor completo. Los contenedores con privilegios, los usuarios root y un socket Docker montado convierten al contenedor de compilación en una puerta de entrada, no en una barrera.
- Esto ya ocurre a gran escala. El gusano CHAINDROP utilizó privilegios de acceso elevados en los ejecutores de GitHub Actions para leer las credenciales directamente de la memoria del ejecutor.
- La solución consiste en aplicar el principio de mínimo privilegio de forma continua. Analiza el alcance de cada token, refuerza la seguridad de cada contenedor y detecta cualquier desviación de permisos antes de que un atacante la encuentre.
¿Qué es una vulnerabilidad?
Una vulnerabilidad de escalada de privilegios es cualquier debilidad que permite a un usuario, proceso o fragmento de código obtener permisos más allá de los que debería tener. MITRE ATT&CK la rastrea como parte de su propia táctica. TA0004: Escalada de privilegios, porque es el paso que convierte un pequeño punto de apoyo en un daño real.
Existen dos formas clásicas:
- Escalada vertical: ascender de rango, por ejemplo, de usuario normal a root, o de un token de solo lectura a uno que pueda escribir.
- Escalada horizontal: moverse lateralmente, por ejemplo, utilizando el acceso de un trabajo para llegar al repositorio, Secretos o entorno de otro equipo.
Los atacantes explotan una vulnerabilidad de escalada de privilegios a través de tres tipos de debilidades: errores de software, configuraciones incorrectas y permisos excesivos. En los servidores, los errores reciben la mayor parte de la atención. CI/CD pipelineLas configuraciones incorrectas y los permisos excesivos hacen casi todo el trabajo.
Por qué es tan peligroso en CI/CD pipelines
A pipeline No es solo una herramienta de compilación. Es una identidad automatizada con uno de los accesos más amplios de su empresa. Un trabajo típico puede:
- Revisa y modifica el código fuente.
- Lee Secretos desde variables de entorno, bóvedas y servicios de metadatos en la nube.
- Publicar paquetes, imágenes y artefactos de lanzamiento
- Implementar en entornos de prueba y producción.
El OWASP Top 10 Seguridad en CI/CD Riesgos Nombra este problema directamente. Su riesgo CICD-SEC-5: Insuficiente Pipeline-Controles de acceso basados en describe cómo los atacantes que ejecutan código malicioso en un pipeline abusar de los permisos otorgados para moverse lateralmente, dentro o fuera del CI/CD .
Esto no es teórico. Durante la campaña CHAINDROP en agosto de 2026, el malware Se extrajeron credenciales temporales de la memoria del ejecutor de GitHub Actions. y utilizó tokens de publicación robados para infectar más paquetes. En los ejecutores de Linux, la carga útil hizo pasar su recolector a través de sudo leer la memoria del proceso del corredor. Eso es una escalada de privilegios en CI/CD pipelines en su forma más pura: una dependencia envenenada, acceso elevado en el ejecutor y cada Secreto que el trabajo pudiera tocar. Es el mismo patrón que vemos en nuestros hallazgos semanales sobre paquetes npm maliciosos.
¿Dónde se esconde una vulnerabilidad de escalada de privilegios en un... pipeline?
Seis rutas comunes, qué ventajas ofrece cada una a un atacante y el control que la cierra.
| Ruta de escalada | Como sucede | Lo que obtiene el atacante | Cómo cerrarlo |
|---|---|---|---|
| Privilegiados pipeline token | Los flujos de trabajo se ejecutan con ámbitos de token predeterminados amplios porque no permissions El bloque está configurado | Acceso de escritura al código, versiones y otros flujos de trabajo. | Establezca valores predeterminados de solo lectura y otorgue acceso de escritura por trabajo, solo donde sea necesario. |
| Envenenado pipeline ejecución | pull_request_target o activadores similares extraen y ejecutan código de una bifurcación no confiable | Secretos del repositorio y un token de escritura, desde un único pull request | Nunca ejecute código fork en un contexto privilegiado; separe las tareas de confianza de las que no lo son. |
| Escalada de privilegios de contenedor | Crea contenedores que se ejecutan como root, en modo privilegiado o con el socket de Docker montado. | Acceso root al host del ejecutor y acceso a todos los trabajos que ejecuta. | Ejecutar como usuario no root, eliminar capacidades y bloquear la escalada de privilegios en la especificación del contenedor. |
| Credenciales en la nube de larga duración | Claves estáticas en la nube almacenadas como Secretos o variables de entorno. | Acceso persistente a cuentas en la nube, mucho después de que finalice el trabajo. | Utilice credenciales federadas de corta duración y revocar automáticamente los Secretos expuestos |
| Corredores persistentes autoalojados | Los ejecutores se reutilizan en diferentes trabajos y repositorios sin necesidad de reconstruirlos. | Persistencia y la capacidad de manipular las construcciones de otros equipos. | Utilice corredores efímeros y aíslelos por nivel de confianza. |
| Relatos humanos privilegiados | Los administradores inactivos, los colaboradores externos y los cambios de permisos no revisados se acumulan. | Una cuenta válida que puede cambiar pipeliney protecciones de ramas | Revise el acceso continuamente y reciba alertas sobre cambios de permisos anómalos. |
Escalada de privilegios de contenedor: cuando el contenedor de compilación no es un límite
Los contenedores se sienten como aislamiento, por lo que los equipos a menudo los tratan como un límite de seguridad. CI/CD, con frecuencia no lo son. La escalada de privilegios de contenedor ocurre cuando el código dentro de un contenedor de compilación obtiene el control del host y, con él, de todos los demás trabajos que se ejecutan allí.
La mayoría de los casos se dan con tres configuraciones:
- Ejecutándose como root. Si el proceso dentro del contenedor es root, cualquier fuga comienza desde la posición más fuerte posible.
- Modo privilegiado. Un contenedor con privilegios tiene prácticamente el mismo acceso al host que un proceso que se ejecuta directamente en él.
- Un socket Docker montado. Montaje
/var/run/docker.socken un trabajo para que pueda construir imágenes de manera efectiva le da a ese trabajo acceso de administrador en el host, porque puede iniciar nuevos contenedores privilegiados.
Investigadores de seguridad han demostrado cómo se desarrolla esto en sistemas CI reales. En un caso bien documentado, los investigadores pasaron de scripts de compilación que se ejecutaban dentro de un contenedor CI a un Escape completo del contenedor en los hosts de compilación de Cloudflare Pages., porcisprincipalmente porque el contenedor estaba siendo tratado como un límite de seguridad.
Así es como se ve una especificación de trabajo de Kubernetes reforzada. La configuración clave es allowPrivilegeEscalation: false, el cual impide que un proceso obtenga más privilegios que su proceso padre., por ejemplo, a través de binarios setuid.
# Pod de compilación reforzado: bloquea las rutas de escalada de privilegios de contenedor más comunes versión api: v1 tipo: Vaina metadatos: nombre : compilación de CI especulación: contexto de seguridad: ejecutarComoNoRoot: su verdadero ejecutarComoUsuario: 10001 Perfil de seccomp: tipo: Valor predeterminado de tiempo de ejecución contenedores: - nombre : construimos imagen: registry.example.com/build-image@sha256: contexto de seguridad: permitir escalada de privilegios: false privilegiado: false Sistema de archivos raíz de solo lectura: su verdadero capacidades:
El mismo principio se aplica al propio Dockerfile. Añada un usuario que no sea root y cambie a él antes del punto de entrada:
# Ejecutar el contenedor como un usuario sin privilegios de administrador. DESDE nodo:22-slim CORRE useradd --uido 10001 --crear-hogar constructor DIR.TRABAJO / aplicación COPIA --chown=constructor:constructor . . USUARIO constructor CMD ["nodo", "index.js"]
La documentación de Kubernetes sobre configurar un contexto de seguridad Cubre cada una de estas configuraciones en detalle.
GitHub Actions: una vulnerabilidad de escalada oculta a plena vista
GitHub Actions es donde muchos equipos se encuentran por primera vez con la escalada de privilegios. CI/CD pipelines, porque los patrones peligrosos parecen completamente normales. Dos merecen ser revisados en todos los repositorios hoy en día.
Alcance del token. Cada flujo de trabajo obtiene un GITHUB_TOKEN. La propia guía de GitHub sobre autenticación automática de token Está claro: una acción puede acceder a ese token incluso si no se pasa explícitamente, por lo que siempre se deben limitar sus permisos al mínimo. Establecer permisos de solo lectura al inicio del flujo de trabajo y otorgar acceso de escritura por trabajo elimina la ruta de escalada más común en un solo paso:
nombre : construimos on: [empuje] # Valor predeterminado para cada trabajo: solo lectura permisos: contenido: read recibas nuevas vacantes en tu correo: compruébalo: se ejecuta en: ubuntu-latest pasos: # Anclar acciones de terceros a un completo commit SHA, no es una etiqueta mutable - usos: acciones/pago@commit-sha> - puedes seguir: npm ci && npm test ,: : compruébalo se ejecuta en: ubuntu-latest # Solo este trabajo puede escribir, y solo lo que necesita permisos: contenido: escribir pasos: - usos: acciones/pago@commit-sha> - puedes seguir: ./scripts/release.sh
Disparadores no confiables. Flujos de trabajo activados por pull_request_target ejecutar con el Secretos del repositorio de destino y un token con capacidad de escritura, incluso cuando el pull request proviene de una bifurcación. Si ese flujo de trabajo luego verifica y ejecuta el código de la bifurcación, cualquiera puede abrir una pull request y ejecutar código con sus privilegios. Esa es una vulnerabilidad de escalada de privilegios que no necesita ser explotada en absoluto, solo una pull requestMantenga los pasos privilegiados en el código de confianza y ejecute el código no confiable en un flujo de trabajo separado sin Secretos.
Si quieres ver estos patrones en un lugar seguro, xygeni-cabra El repositorio recopila información de forma deliberadamente insegura. pipeline y IaC configuraciones para entrenamiento. Para una revisión más amplia de su configuración de GitHub, consulte nuestra guía sobre Cómo saber si una aplicación o repositorio de GitHub es seguro..
Cómo prevenir una vulnerabilidad de escalada de privilegios en CI/CD pipelines
Cierre de la escalada de privilegios en CI/CD pipelineTodo se reduce a un principio: el mínimo privilegio, aplicado en cada nivel y verificado continuamente en lugar de una sola vez. Una lista de verificación práctica:
- Analizar cada token. De forma predeterminada, solo lectura; acceso de escritura por trabajo; y sin tokens para toda la organización en los flujos de trabajo del repositorio.
- Separe el código de confianza del código que no lo es. Nunca ejecute código de bifurcaciones o colaboradores externos en un trabajo que contenga Secretos.
- Refuerce la seguridad de cada contenedor de compilación. Usuarios no root, sin modo privilegiado, sin socket Docker, capacidades eliminadas,
allowPrivilegeEscalation: false. - Reemplazar los Secretos de larga duración. Prefiera las credenciales federadas de corta duración y revoque inmediatamente cualquier información que haya quedado expuesta.
- Fija lo que corres. Referencia a acciones e imágenes de terceros por commit SHA o resumen, por lo que una etiqueta comprometida no puede cambiar su pipeline.
- Esté atento a la deriva. Los permisos se amplían con el tiempo. Alerta sobre nuevos administradores, protección de ramas debilitada y cambios inesperados en el flujo de trabajo.
- Puerta de la pipeline. Si se produce una configuración incorrecta crítica, la compilación fallará antes de que se complete la fusión.
Lo difícil no es conocer estas reglas, sino aplicarlas en cientos de repositorios y flujos de trabajo que cambian a diario.
¿Cómo detiene Xygeni una vulnerabilidad de escalada de privilegios en CI/CD?
Cada ruta de escalada se corresponde con la capacidad de Xygeni que la detecta o la bloquea.
| Supervisión | Lo que hace Xygeni |
|---|---|
| Pipeline configuraciones erróneas | Detectores de configuración incorrecta Analizar las definiciones de trabajos de CI, los scripts de compilación y los archivos de configuración en GitHub, GitLab, Azure DevOps, Bitbucket, CircleCI y Jenkins, y marcar permisos más amplios de lo que permiten las mejores prácticas. |
| Escalada de privilegios de contenedor | IaC y controles de contenedores Cubre Dockerfiles, archivos docker-compose, manifiestos de Kubernetes y gráficos de Helm, incluidos los contenedores que se ejecutan como root. |
| Usuarios con privilegios excesivos e inactivos | El análisis de privilegios mínimos identifica a los usuarios inactivos y con privilegios excesivos, y el Health Check convierte cada hallazgo en un boleto |
| Deriva de permisos | Alertas de detección de anomalías sobre cambios de permisos inusuales, fusiones anómalas e instalaciones de complementos inesperadas. |
| Credenciales expuestas | La detección de secretos abarca el código, pipelineimágenes de contenedores y s, con revocación automática para los tipos de Secreto compatibles. |
| Código malicioso en el pipeline | Bloquea shells inversas y descargas de malware en pipelineen tiempo real, y MEW detecta paquetes maliciosos antes de que exista una firma. |
| Cumplimiento | Pre-commit hooks y CI guardrails Fallar la compilación en problemas críticos, con políticas YAML personalizadas para sus propias reglas. |
Las comprobaciones se alinean con el OWASP Top 10 Seguridad en CI/CD Riesgos y standards tales como CIS, NIST y OpenSSFCada hallazgo desemboca en Xygeni ASPMdonde se le da prioridad junto con el código, las dependencias y los hallazgos de Secretos, de modo que la vulnerabilidad de escalada de privilegios que realmente llega a producción se soluciona primero.
La mayor escalada de privilegios en CI/CD pipelines ya está presente en tus archivos de flujo de trabajo, esperando a que se ejecute código no confiable.
Preguntas Frecuentes
¿Qué es una vulnerabilidad de escalada de privilegios en CI/CD?
Es cualquier debilidad que permite que el código se ejecute en un pipeline obtener más acceso del que requiere el trabajo, como un token con privilegios excesivos, un flujo de trabajo que ejecuta código no confiable con Secretos o un contenedor de compilación que puede llegar al host.
¿Qué es la escalada de privilegios de contenedor?
La escalada de privilegios en un contenedor se produce cuando un proceso dentro de un contenedor obtiene privilegios superiores, a menudo de root en el sistema anfitrión. Las causas comunes son ejecutarse como root, el modo privilegiado y un socket Docker montado.
Does allowPrivilegeEscalation: false ¿Evitar fugas de contenedores?
Bloquea una vía importante: que un proceso obtenga más privilegios que su proceso padre, por ejemplo, mediante binarios setuid. Funciona mejor combinado con un usuario sin privilegios de administrador, capacidades reducidas y sin modo privilegiado.
Is pull_request_target ¿Siempre peligroso?
No por sí solo. Se convierte en una vulnerabilidad de escalada de privilegios cuando el flujo de trabajo extrae y ejecuta código de la pull request, porque ese código se ejecuta con tu Secretos y un token con capacidad de escritura.
¿Cómo puedo encontrar rutas de escalada de privilegios en varios repositorios?
Las revisiones manuales no escalan. Una Seguridad automatizada en CI/CD La herramienta analiza continuamente cada flujo de trabajo, especificación de contenedor y conjunto de permisos, y emite una alerta cuando algo se amplía.
