Productos FTTH

Tienda FFTH desde 2004

Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon GitHub actualiza actions/checkout para bloquear patrones comunes de ataques Pwn Request


GitHub actualizará actions/checkout para bloquear ataques de pwn request que explotan el disparador pull_request_target. Esta medida evita que código malicioso de repositorios forkeados se ejecute con privilegios completos y acceda a secretos. El cambio será efectivo a partir de junio de 2026 para fortalecer la seguridad de la cadena de suministro de software.



GitHub se está moviendo para reforzar la seguridad de la cadena de suministro de software actualizando "actions/checkout" para bloquear los ataques de "pwn request" que explotan el uso riesgoso del activador de flujo de trabajo "pull_request_target" para ejecutar código malicioso con todos los privilegios del flujo de trabajo.

A partir del 18 de junio de 2026, la versión más reciente de "actions/checkout", la acción oficial de GitHub para extraer un repositorio en el ejecutor del flujo de trabajo, rechazará por defecto los patrones comunes de pwn request. Se espera que el cambio se incorpore a todas las versiones principales compatibles actualmente el 16 de julio de 2026.

"Actions/checkout v7 se niega a obtener el código de una solicitud de extracción (pull request) de un fork en los flujos de trabajo pull_request_target y workflow_run (este último solo cuando workflow_run.event es un evento pull_request*)," añadió GitHub.

El rechazo ocurre cuando la solicitud de extracción proviene de un fork y se cumple cualquiera de los siguientes criterios, a menos que los autores del flujo de trabajo opten explícitamente por desactivarlo configurando la bandera "allow-unsafe-pr-checkout" como "true" en "actions/checkout":

* repository: se resuelve al repositorio de la solicitud de extracción del fork
* ref: coincide con refs/pull/number/head o refs/pull/number/merge
* ref: se resuelve al commit SHA de la cabeza o de la fusión de una solicitud de extracción de un fork

El cambio está destinado a evitar la forma más común de pwn requests en el ecosistema de Actions. Como resultado, "actions/checkout" fallará para los "eventos pull_request_target" provenientes de forks con entradas inseguras.

"Pull_request_target" es un activador de flujo de trabajo que se ejecuta automáticamente sin requerir aprobación manual cuando se abre o reabre una solicitud de extracción, o cuando se actualiza la rama principal de la misma. Es importante que sepas que el evento se ejecuta en el contexto de la rama predeterminada del repositorio base, exponiendo potencialmente secretos y un GITHUB_TOKEN privilegiado con permisos tanto de lectura como de escritura.

"Ejecutar código no confiable en el activador pull_request_target puede provocar vulnerabilidades de seguridad", señala GitHub en su documentación. "Estas vulnerabilidades incluyen el envenenamiento de la caché y la concesión de acceso no intencionado a privilegios de escritura o secretos".

El peligro surge cuando se combina "pull_request_target" con "actions/checkout" para descargar y ejecutar código enviado por un fork no confiable. Si un actor malintencionado envía una solicitud de extracción que contenga scripts maliciosos y el flujo de trabajo extrae y ejecuta el código, puede permitir que el atacante robe el GITHUB_TOKEN y otros secretos, lo que lleva a lo que se denomina un ataque de pwn request pwn request attack.

"Los flujos de trabajo activados por pull_request_target se ejecutan con el GITHUB_TOKEN del repositorio base, los secretos y el acceso a la caché de la rama predeterminada", dijo GitHub. "Extraer la cabeza de una solicitud de extracción no revisada de un fork dentro de uno de estos flujos de trabajo normalmente permite que el código controlado por el atacante se ejecute con los privilegios completos del flujo de trabajo".

En los últimos meses, varios ataques a la cadena de software han aprovechado este comportamiento. El más grave fue el compromiso de múltiples paquetes asociados con el sistema de construcción Nx como parte de una campaña llamada s1ngularity, así como la brecha de PostHog, TanStack y el popular paquete de Emacs, "kubernetes-el/kubernetes-el".

"Pull_request_target fue diseñado para la automatización confiable en torno a las solicitudes de extracción, como el etiquetado, los comentarios o la aplicación de metadatos del proyecto", dijo Socket. "Pero el paso de checkout controla qué código llega realmente al espacio de trabajo del ejecutor. Si extrae código de una solicitud de extracción ramificada, el flujo de trabajo puede terminar ejecutando código controlado por el atacante con los privilegios del repositorio base".

Dicho esto, la filial propiedad de Microsoft enfatizó que los pwn requests activados a través de otros tipos de eventos además de pull_request_target (por ejemplo, issue_comment) o a través de otros medios, como git o la CLI de GitHub, están fuera del alcance de este cambio.

"Este cambio solo bloquea las extracciones de la cabeza de la solicitud de extracción del fork y los commits de fusión", añadió. "No bloquea las extracciones de otros repositorios no confiables. Por ejemplo, configurar repository: a un repositorio de terceros no relacionado no está bloqueado. Extraer y ejecutar cualquier código no confiable en un evento privilegiado sigue siendo un riesgo de pwn request que debe ser revisado".

Para contrarrestar el riesgo que plantea "pull_request_target", se aconseja a los desarrolladores evaluarlo y usarlo solo cuando sea necesario, cambiar a "pull_request" si el flujo de trabajo no requiere permisos elevados o acceso a secretos, restringir los permisos concedidos a los flujos de trabajo y asegurarse de que la entrada controlada por el usuario no resulte en la ejecución de código no confiable.

"La protección en esta actualización solo cubre las extracciones realizadas a través de actions/checkout", dijo Socket. "Eso convierte a esto en una barrera de seguridad, no en una solución completa para la seguridad de Actions. Los flujos de trabajo que se ejecutan con secretos, permisos de escritura, permisos de despliegue o acceso de publicación OIDC siguen necesitando una revisión cuidadosa".

Fuente:
THN

0 comments :

Post a Comment

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.