Wiz · 26 octobre 2026 · Cyber & GRC
GitHub Actions : les attaques Pwn Request restent possibles malgré les changements
Les changements apportés par GitHub à Actions en 2026 compliquent les attaques pull_request_target sans les rendre impossibles. Wiz examine la surface d’attaque résiduelle et les moyens de l’auditer.
Ce qui est annoncé
Wiz publie une analyse des risques qui subsistent dans GitHub Actions face aux attaques dites « Pwn Request ». Son constat : les protections décrites pour 2026 compliquent les attaques les plus directes, sans supprimer cette catégorie de vulnérabilités. Le texte présente notamment le blocage par défaut de certaines récupérations de code provenant de forks dans actions/checkout, des jetons de cache limités à la lecture et des règles de contrôle des événements. Il indique également qu’un blocage par défaut de pull_request_target est prévu pour les dépôts publics dépourvus de politique explicite, sans concerner les dépôts privés ou internes.
L’analyse souligne surtout que la protection dépend du chemin suivi par chaque workflow. Une référence SHA figée sur une ancienne version de actions/checkout peut conserver un code dépourvu des correctifs. Les scripts de récupération personnalisés et les actions tierces ne bénéficient pas automatiquement des mêmes contrôles. Wiz relève aussi des risques liés à certains déclencheurs privilégiés, à l’injection de données non fiables dans les scripts et à l’exécution d’artefacts issus de workflows moins fiables. Enfin, l’état persistant des runners auto-hébergés et la désactivation explicite des protections restent des points de vigilance.
Ce que ça change pour les entreprises
Pour les DSI et les équipes IT, ces évolutions invitent à examiner les workflows au-delà de leur seule version affichée. Une revue peut porter sur les références effectivement utilisées, les autorisations des personnes déclenchant les traitements et les données transmises aux commandes. Le verrouillage par SHA conserve un intérêt pour maîtriser le code exécuté, mais nécessite de suivre les versions corrigées. De même, l’approbation exigée pour les contributions externes ne constitue pas une barrière applicable à pull_request_target.
La séparation entre traitements fiables et non fiables reste donc déterminante. Les contrôles du cache ne couvrent ni tous les échanges d’artefacts ni les fichiers conservés sur les runners. Selon les usages, des runners éphémères, des groupes distincts et une validation humaine des tâches privilégiées peuvent contribuer à réduire l’exposition, sans remplacer l’examen des entrées et des permissions.
Comment UNEETY peut vous accompagner
Une ESN comme UNEETY peut accompagner le cadrage d’une revue de GitHub Actions, l’identification des workflows sensibles et l’intégration de contrôles adaptés. Cet accompagnement peut également couvrir la sécurisation des pratiques et leur adoption par les équipes de développement et d’exploitation.
Découvrez notre offre Cyber & GRC ou contactez-nous.
Source : annonce Wiz du 26 octobre 2026.