GitHub Actions endurece seguridad ante ataques 'pwn request'

¿Qué ha ocurrido?

El 18 de junio de 2026, GitHub anunció el lanzamiento de actions/checkout v7, una actualización de seguridad que bloquea automáticamente los workflows que intenten obtener código de pull requests sin revisar cuando se ejecutan bajo los eventos pull_request_target o workflow_run. A partir de ahora, los desarrolladores deben añadir explícitamente el parámetro allow-unsafe-pr-checkout para permitir este comportamiento, que antes era la norma. Este cambio es parte de una iniciativa más amplia de GitHub para adoptar una postura de 'seguro por defecto', tras un incremento significativo de ataques que explotan esta debilidad.

La vulnerabilidad subyacente no es nueva: se conoce desde al menos 2021, cuando investigadores de seguridad documentaron por primera vez los riesgos de usar pull_request_target con checkout sin revisión. Sin embargo, GitHub no había implementado medidas hasta ahora, presionado por una ola de ataques en 2025 y 2026 que comprometieron miles de repositorios y paquetes. Según datos de Endor Labs, los ataques 'pwn request' aumentaron un 340% en el primer trimestre de 2026 en comparación con el mismo período de 2025.

¿Por qué es importante?

Los ataques 'pwn request' han aumentado en los últimos meses, especialmente por parte del grupo TeamPCP, que logró comprometer 170 paquetes npm en mayo de 2026, según informó InfoWorld. El problema radica en que el trigger pull_request_target otorga acceso a secretos (como claves API) que pull_request normal no permite. Si un workflow usa actions/checkout para descargar el código del fork sin revisar, un atacante puede inyectar código malicioso que se ejecute con los privilegios completos del workflow. A diferencia del evento pull_request, que ejecuta el workflow en un entorno aislado sin secretos, pull_request_target se ejecuta en el contexto del repositorio base, con acceso a secretos y tokens de despliegue.

El impacto es masivo: según GitHub, más de 1.2 millones de workflows en repositorios públicos utilizaban pull_request_target de forma insegura antes de este cambio. La mayoría de estos workflows pertenecen a proyectos open source, que son particularmente vulnerables porque aceptan contribuciones de forks externos. El ataque típico consiste en que un atacante crea un pull request con código malicioso que, al ser procesado por el workflow, extrae secretos o ejecuta comandos arbitrarios en el runner.

Consecuencias y contexto

Este cambio marca el inicio de una política de 'seguro por defecto' en GitHub Actions, donde la plataforma impone restricciones en lugar de dejarlo a criterio del desarrollador. A partir del 16 de julio, los nuevos defaults se retrocederán a todas las versiones mayores compatibles (v4, v5, v6). Los workflows que usen etiquetas flotantes (como @v4) recibirán el cambio automáticamente; los que usen SHA específicos o versiones menores deberán actualizar manualmente. GitHub también ha anunciado que explorará endurecimientos adicionales para otros eventos, como workflow_run y deployment, en futuras versiones.

La decisión de GitHub no está exenta de críticas. Algunos desarrolladores señalan que el cambio puede romper workflows legítimos que dependen de revisar código de forks, como aquellos que ejecutan análisis de calidad o pruebas de seguridad automatizadas. Para mitigar esto, GitHub ha proporcionado un mecanismo de exclusión voluntaria (allow-unsafe-pr-checkout), pero advierte que su uso debe ser cuidadoso y solo cuando se comprendan los riesgos. La compañía también recomienda usar pull_request en lugar de pull_request_target siempre que sea posible, y limitar el uso de secretos en workflows que procesen código no revisado.

Qué deben saber los lectores

• No es una vulnerabilidad nueva: La debilidad en pull_request_target se conoce desde hace años, pero GitHub no había actuado hasta ahora. La primera advertencia pública data de 2021 en un informe de seguridad de la empresa Endor Labs.
• No afecta a todos los workflows: Solo aquellos que usen pull_request_target o workflow_run y checkout sin revisión. Los workflows que usan pull_request normal no se ven afectados.
• Medidas adicionales: GitHub advierte que se explorarán más endurecimientos en el futuro para otros eventos, como issue_comment y pull_request_review.
• Para desarrolladores: Revisar workflows que usen pull_request_target y asegurarse de que no dependan de código no revisado. Si es necesario, usar el opt-out con precaución. Se recomienda también auditar los secretos expuestos y rotar aquellos que hayan podido estar comprometidos.

“El cambio señala el comienzo de una nueva era 'segura por defecto' en la que la seguridad será definida por el sistema GitHub en lugar de quedar a discreción de los desarrolladores.” — InfoWorld

Impacto en el ecosistema

La medida reduce significativamente la superficie de ataque para repositorios open source, que eran los más afectados. Según estimaciones de GitHub, el cambio protegerá aproximadamente 800,000 repositorios públicos que utilizan pull_request_target. Sin embargo, expertos señalan que los ataques 'pwn request' pueden ocurrir por otras vías, como la manipulación de acciones de terceros o la inyección de scripts en el entorno del runner. Por ejemplo, un atacante podría modificar el contenido de una acción de terceros que se ejecute en el workflow, o aprovechar variables de entorno mal sanitizadas.

La comunidad de seguridad celebra el paso, pero pide más transparencia en la detección de estos ataques. Actualmente, GitHub no proporciona herramientas nativas para detectar intentos de 'pwn request' antes de que se ejecuten, lo que obliga a los desarrolladores a confiar en auditorías manuales o herramientas externas. Empresas como Endor Labs y Datadog han lanzado soluciones de monitoreo, pero su adopción sigue siendo baja. En palabras de un investigador de seguridad citado por InfoWorld: "Este es un paso en la dirección correcta, pero no es suficiente. GitHub debería implementar alertas en tiempo real y bloqueo de acciones sospechosas".

En términos de mercado, la decisión de GitHub refuerza su posición como plataforma líder en DevOps, pero también pone presión sobre competidores como GitLab y Bitbucket para que implementen medidas similares. GitLab ya ha anunciado que estudiará cambios en su propia implementación de CI/CD para evitar ataques similares. Mientras tanto, los equipos de seguridad de las empresas deberán actualizar sus flujos de trabajo y capacitar a sus desarrolladores sobre las nuevas prácticas seguras.