diff --git a/src/pentesting-ci-cd/argocd-security.md b/src/pentesting-ci-cd/argocd-security.md
new file mode 100644
index 000000000..0dc9a00f6
--- /dev/null
+++ b/src/pentesting-ci-cd/argocd-security.md
@@ -0,0 +1,219 @@
+# Argo CD Security
+
+{{#include ../banners/hacktricks-training.md}}
+
+## Grundlegende Informationen
+
+[Argo CD](https://argo-cd.readthedocs.io/) ist eine GitOps-Continuous-Delivery-Plattform für Kubernetes. Sie überwacht Git-Repositories, rendert Kubernetes-Manifeste mit Tools wie Helm, Kustomize, Jsonnet oder config management plugins und gleicht den Live-Cluster-Status mit dem gewünschten Status ab, der in Git gespeichert ist.
+
+Aus Sicht eines Angreifers sollte Argo CD als eine **Deployment-Engine mit Kubernetes-Anmeldedaten** betrachtet werden. Ein erfolgreicher Kompromiss von Argo CD kann zu Folgendem führen:
+
+- Zugriff auf private Git-Repositories und Repository-Anmeldedaten.
+- Zugriff auf Kubernetes-Cluster-Secrets, die von Argo CD verwendet werden.
+- Code Execution zur Manifest-Generierung in `argocd-repo-server`.
+- Unautorisierte Bereitstellung von Kubernetes-Objekten über vertrauenswürdige Git-Repositories, Argo-CD-Applications oder Cache-Manipulation.
+
+## Architektur & interessante Komponenten
+
+Gängige Kubernetes-Objekte und Services:
+```bash
+kubectl get pods,svc,endpoints,ingress -A | grep -iE 'argocd|argo-cd'
+kubectl get applications,appprojects,applicationsets -A 2>/dev/null
+kubectl get secrets,configmaps -n argocd 2>/dev/null
+kubectl get networkpolicy -n argocd 2>/dev/null
+```
+Interessante Services:
+
+- **`argocd-server`**: öffentliche API, Web-UI, CLI-API, Authentication und Authorization.
+- **`argocd-application-controller`**: vergleicht gewünschten und aktuellen Zustand und wendet dann Ressourcen auf Kubernetes an.
+- **`argocd-repo-server`**: klont Repositories, cached Git-Daten und führt Helm/Kustomize/Jsonnet/plugins aus, um Manifests zu generieren. Der standardmäßige gRPC-Port ist **8081**.
+- **`argocd-redis`**: Cache für Application-, Manifest- und Git-Referenzdaten. Der standardmäßige Redis-Port ist **6379**.
+- **`argocd-applicationset-controller`**: generiert Argo CD `Application`-Objekte aus Generatoren wie Git, SCM, Clustern und pull requests.
+
+Von einem kompromittierten Pod oder internen Netzwerksegment aus die interne Erreichbarkeit prüfen:
+```bash
+nc -vz <argocd-server> 443
+nc -vz <argocd-repo-server> 8081
+nc -vz <argocd-redis> 6379
+```
+## Public API / UI Attacks
+
+Wenn du Argo CD-Credentials oder eine exponierte Instanz hast, beginne mit der normalen API-Oberfläche:
+```bash
+argocd login <argocd-server>
+argocd account get-user-info
+argocd account list
+argocd proj list
+argocd app list
+argocd repo list
+argocd cluster list
+argocd admin settings rbac can <subject> <action> <resource> <object>
+```
+Nützliche Angriffspfade:
+
+- **Application write access**: `source.repoURL`, `source.path`, Helm values, Kustomize-Optionen, Plugin-Einstellungen oder Sync-Optionen ändern, damit Argo CD vom Angreifer kontrollierte Manifests deployt.
+- **Project misconfiguration**: `AppProject`-Objekte können breite `sourceRepos`, breite `destinations`, unsichere `clusterResourceWhitelist` oder schwache Namespace-Einschränkungen erlauben.
+- **Repository credential abuse**: Repository-Secrets, GitHub-App-Credentials, SSH-Keys und Tokens können das Pushen in vertrauenswürdige Repos oder das Hinzufügen bösartiger Abhängigkeiten ermöglichen.
+- **Cluster credential abuse**: Cluster-Secrets können Bearer-Tokens oder exec-provider-Konfiguration enthalten, die von Argo CD verwendet werden, um in Ziel-Cluster zu deployen.
+- **Local admin / project tokens**: Lang lebige Argo CD-Tokens können über die API wiederverwendet werden, solange sie nicht widerrufen oder abgelaufen sind.
+
+Enumerate configuration from Kubernetes when you have cluster read access:
+```bash
+kubectl get applications.argoproj.io -A -o yaml
+kubectl get appprojects.argoproj.io -A -o yaml
+kubectl get applicationsets.argoproj.io -A -o yaml
+kubectl get secrets -n argocd -o yaml | grep -nE 'repoURL|sshPrivateKey|password|bearerToken|githubApp|tlsClientCertData|tlsClientCertKey'
+kubectl get cm -n argocd argocd-cm argocd-rbac-cm argocd-cmd-params-cm -o yaml
+```
+## Trusted Git Repository Abuse
+
+Wenn du in ein Repository pushen kannst, dem Argo CD vertraut, kannst du normalerweise beeinflussen, was deployed wird. Der Impact hängt von den `AppProject`-Grenzen und den Service-Account-Berechtigungen ab, die der application controller verwendet.
+
+Häufige Payload-Positionen:
+
+- Raw Kubernetes YAML unter einem application path.
+- Helm chart templates und `values.yaml`.
+- Kustomize overlays, remote bases und generators.
+- Jsonnet oder config management plugin input.
+- ApplicationSet generator files, die `Application`-Objekte erstellen oder updaten.
+
+Prüfe, ob die app automated sync, pruning, self-heal, sync windows oder manual approvals verwendet:
+```bash
+kubectl get applications.argoproj.io -A \
+-o custom-columns='NS:.metadata.namespace,APP:.metadata.name,PROJECT:.spec.project,AUTOSYNC:.spec.syncPolicy.automated,REPO:.spec.source.repoURL,PATH:.spec.source.path,DEST:.spec.destination.server'
+```
+## Direktes Missbrauchen von `argocd-repo-server`
+
+Gehe nicht davon aus, dass die öffentliche Argo CD API die einzige Angriffsfläche ist. Interne Argo CD-Komponenten kommunizieren mit `argocd-repo-server` über gRPC. Wenn beliebige Pods repo-server erreichen können, können angreifer-kontrollierte interne Requests die Checks umgehen, die normalerweise von `argocd-server` erzwungen werden.
+
+Praktische Checks:
+```bash
+kubectl get svc -n argocd argocd-repo-server -o yaml
+kubectl get endpoints -n argocd argocd-repo-server -o wide
+nc -vz <argocd-repo-server> 8081
+```
+Interessante Anzeichen:
+
+- Der repo-server gRPC endpoint ist von Non-Argo CD pods aus erreichbar.
+- NetworkPolicies fehlen oder erlauben nur allow-list egress ohne ingress zu deny.
+- Der repo-server hat Zugriff auf custom config management plugins, decryption tools oder repository content von mehreren tenants.
+- Redis ist von Non-Argo CD pods aus erreichbar, was cache inspection oder tampering erlaubt, wenn Credentials verfügbar sind oder nicht erforderlich sind.
+
+## Unauthenticated Repo-Server RCE via Kustomize Options
+
+Im Juli 2026 veröffentlichte Synacktiv eine unauthenticated code execution chain in Argo CD's `repo-server`, wenn ein attacker den internen gRPC service erreichen kann. Der Angriff missbraucht direkten Zugriff auf `/repository.RepoServerService/GenerateManifest` und attacker-controlled `KustomizeOptions`.
+
+Die gefährliche primitive ist, den repo-server dazu zu bringen, attacker-controlled repository content zu klonen und Kustomize mit Helm support auszuführen:
+```bash
+kustomize build <attacker_repo_path> --enable-helm --helm-command ./payload.sh
+```
+Minimal bösartige Kustomize-Eingabe muss Helm-Verarbeitung auslösen:
+```yaml
+helmCharts:
+- name: pwn
+version: 0.0.1
+```
+Warum das funktioniert:
+
+- `argocd-repo-server` klont das Repository vor dem Rendern.
+- `--helm-command ./payload.sh` wird relativ zum geklonten Repository aufgelöst.
+- Code execution erfordert keine Shell-Metazeichen-Injection, wenn der Angreifer das gerenderte Repository und die Kustomize build-Optionen kontrollieren kann.
+
+Zum Zeitpunkt der Offenlegung durch Synacktiv am 1. Juli 2026 berichteten sie, dass es für das Problem keinen offiziellen Fix oder CVE gab. Behandle dies zuerst als ein network-exposure-Problem: Eine Ausnutzung erfordert Erreichbarkeit des internen repo-server gRPC ports.
+
+## Redis Cache Poisoning zum Bereitstellen von Manifests
+
+Nach Code execution in `argocd-repo-server` oder nach direktem Zugriff auf Redis mit gültigen Anmeldedaten solltest du die Redis-gestützten Cache-Einträge prüfen. Argo CD speichert häufig gzip-komprimierte JSON-Werte.
+
+Interessante Key-Präfixe:
+```text
+mfst|...       # cached rendered manifests
+git-refs|...   # Git branch/ref to commit mappings
+app|...        # application resource/cache data
+cluster|...    # cluster cache information
+```
+Der Cache-Poisoning-Angriff, der von Synacktiv beschrieben wird, missbraucht zwei Zustände:
+
+1. Ändere den relevanten `mfst|...` manifest cache-Eintrag, um ein von einem Angreifer kontrolliertes Kubernetes-Manifest einzuschließen.
+2. Ändere das zugehörige `git-refs|...` Mapping, damit Argo CD glaubt, dass sich der Branch verschoben hat, und dann wieder auf die gecachte Revision zurück reconciles.
+
+Impact:
+
+- Mit aktiviertem Auto Sync kann Argo CD das vergiftete gecachte Manifest automatisch anwenden.
+- Ohne Auto Sync kann der Payload trotzdem angewendet werden, wenn ein User die Application manuell syncs.
+- Der endgültige Impact wird durch das Ziel der Application und die Kubernetes-Berechtigungen begrenzt, die Argo CD zur Verfügung stehen.
+
+## ApplicationSet Attacks
+
+ApplicationSet ist besonders sensibel, weil es `Application`-Objekte aus Generator-Output erstellt oder aktualisiert.
+
+Review:
+```bash
+kubectl get applicationsets.argoproj.io -A -o yaml
+kubectl get appprojects.argoproj.io -A -o yaml
+```
+Interessante Muster:
+
+- Git generators lesen von angreifbar schreibbaren Dateien, die App-Namen, Pfade, Projects oder destinations steuern.
+- Pull request generators für öffentliche Repositories, bei denen nicht vertrauenswürdige Contributor generierte applications beeinflussen können.
+- Template-Felder, die breite destination clusters/namespaces erlauben.
+- AppProjects, die `sourceRepos: ["*"]` oder breite `destinations` erlauben.
+- Generierte applications, die automated sync und pruning erben.
+
+## Post-Exploitation
+
+Von einer Argo CD pod shell aus priorisieren:
+```bash
+env
+cat /proc/1/environ 2>/dev/null | tr '\0' '\n'
+find /var/run/secrets /app/config -type f -maxdepth 4 2>/dev/null
+mount | grep -E 'secret|token|config'
+```
+Nützliche Ziele:
+
+- Steal `REDIS_PASSWORD` oder Redis TLS/client material.
+- Extrahiere Repository-Credentials aus gemounteten Secrets oder Argo CD Kubernetes Secrets.
+- Identifiziere Cluster-Credentials, die von Argo CD verwendet werden.
+- Lies generierte Manifeste und Plugin-Output, die injizierte Secrets enthalten können.
+- Prüfe, ob custom plugins, SOPS, Helm secrets, Vault plugins oder cloud CLIs Decryption Keys und Cloud-Credentials preisgeben.
+
+## Detection & Hardening
+
+Wichtige Prüfungen:
+
+- Beschränke den `argocd-repo-server`-Port **8081** und den Redis-Port **6379** mit NetworkPolicies, sodass nur erwartete Argo CD-Komponenten sie erreichen können.
+- Prüfe in Helm deployments, ob NetworkPolicies tatsächlich erstellt werden. Argo CD Helm chart values haben historisch die Erstellung von Component Network Policies standardmäßig deaktiviert.
+- Verwende `argocd-server` als authentifizierten Einstiegspunkt. Interne Services sollten nicht für beliebige Workloads erreichbar sein.
+- Deaktiviere nicht verwendete config management tools und plugins.
+- Beschränke `AppProject` `sourceRepos`, `destinations`, Namespace-Berechtigungen und cluster-scoped resources.
+- Vermeide das Speichern breit gefasster Repository-Credentials, bei denen ein niedrig privilegierter Argo CD user deren Wiederverwendung auslösen kann.
+- Überwache Repo-server-Requests, Kustomize build options, Plugin-Ausführungen, Redis-Writes und unerwarteten Zugriff auf `mfst|` / `git-refs|` Keys.
+- Rotiere Argo CD local users, project tokens, repository credentials und cluster credentials nach einem Kompromiss.
+
+Nützliche Befehle:
+```bash
+kubectl get networkpolicy -n argocd
+kubectl get networkpolicy -A | grep -i argocd
+kubectl describe networkpolicy -n argocd argocd-repo-server-network-policy 2>/dev/null
+kubectl describe networkpolicy -n argocd argocd-redis-network-policy 2>/dev/null
+```
+## Statische Analyse-Hinweis: Typed API Requests in CodeQL
+
+Für Go-Services mit gRPC/REST-Handlern können die default CodeQL remote sources Flows übersehen, sobald raw input in typed request objects unmarshalled wurde. Ein nützliches Model für Argo CD-style Services ist:
+
+- Receiver type wie `Server` oder `Service`.
+- Der erste parameter ist `context.Context`.
+- Der zweite parameter ist ein typed request object.
+
+Modelliere diesen zweiten parameter als remote source und füge custom sinks für `exec.Command` / `exec.CommandContext` arguments hinzu. Das hilft, Flows von internen API request fields in command execution helpers zu finden.
+
+## References
+
+- [Synacktiv - Caught in the Octopus Trap: Unauthenticated RCE in Argo CD with CodeQL](https://www.synacktiv.com/en/publications/caught-in-the-octopus-trap-unauthenticated-rce-in-argo-cd-with-codeql)
+- [Argo CD docs - Security considerations](https://argo-cd.readthedocs.io/en/stable/operator-manual/security/)
+- [Argo CD docs - High Availability](https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/)
+- [Argo CD docs - repo-server command reference](https://argo-cd.readthedocs.io/en/stable/operator-manual/server-commands/argocd-repo-server/)
+- [Argo CD - repo-server NetworkPolicy manifest](https://github.com/argoproj/argo-cd/blob/master/manifests/base/repo-server/argocd-repo-server-network-policy.yaml)
+- [Argo CD docs - metrics](https://argo-cd.readthedocs.io/en/latest/operator-manual/metrics/)
+- [Argo Helm - chart values reference](https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/README.md)
+- [Kustomize - Helm chart generator example](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md)
diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
index f9e23ed5c..70c5be857 100644
--- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
+++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
@@ -6,7 +6,7 @@
 
 ## VCS
 
-VCS steht für **Version Control System**, diese Systeme ermöglichen es Entwicklern, ihren **Source Code zu verwalten**. Das gebräuchlichste ist **git**, und du wirst Unternehmen normalerweise auf einer der folgenden **Plattformen** finden:
+VCS steht für **Version Control System**, diese Systeme ermöglichen es Entwicklern, ihren **Source code zu verwalten**. Das gebräuchlichste ist **git** und du wirst Unternehmen üblicherweise auf einer der folgenden **Plattformen** finden:
 
 - Github
 - Gitlab
@@ -18,39 +18,39 @@ VCS steht für **Version Control System**, diese Systeme ermöglichen es Entwick
 
 ## CI/CD Pipelines
 
-CI/CD pipelines ermöglichen es Entwicklern, die **Ausführung von code zu automatisieren** für verschiedene Zwecke, einschließlich Building, Testing und Deploying von Anwendungen. Diese automatisierten Workflows werden durch **spezifische Aktionen ausgelöst**, wie code pushes, pull requests oder geplante Aufgaben. Sie sind nützlich, um den Prozess von Entwicklung bis Produktion zu vereinfachen.
+CI/CD pipelines ermöglichen es Entwicklern, die **Ausführung von Code zu automatisieren** für verschiedene Zwecke, einschließlich Builden, Testen und Deployen von Anwendungen. Diese automatisierten Workflows werden durch **bestimmte Aktionen ausgelöst**, wie Code-Pushes, Pull Requests oder geplante Aufgaben. Sie sind nützlich, um den Prozess von der Entwicklung bis zur Produktion zu vereinfachen.
 
-Allerdings müssen diese Systeme **irgendwo ausgeführt werden** und normalerweise mit **privilegierten credentials, um code zu deployen oder auf sensitive information zuzugreifen**.
+Diese Systeme müssen jedoch **irgendwo ausgeführt** werden und normalerweise mit **privilegierten Credentials, um Code zu deployen oder auf sensible Informationen zuzugreifen**.
 
 ## VCS Pentesting Methodology
 
 > [!NOTE]
-> Auch wenn einige VCS platforms es erlauben, pipelines zu erstellen, analysieren wir in diesem Abschnitt nur potenzielle attacks auf die Kontrolle des source code.
+> Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.
 
-Plattformen, die den source code deines Projekts enthalten, enthalten sensible information und man muss bei den in dieser Plattform gewährten permissions sehr vorsichtig sein. Dies sind einige häufige Probleme auf VCS platforms, die ein attacker ausnutzen könnte:
+Plattformen, die den Source code deines Projekts enthalten, enthalten sensible Informationen, und man muss sehr vorsichtig mit den innerhalb dieser Plattform gewährten Berechtigungen sein. Dies sind einige häufige Probleme über VCS platforms hinweg, die ein Angreifer ausnutzen könnte:
 
-- **Leaks**: Wenn dein code leaks in den commits enthält und der attacker auf das repo zugreifen kann (weil es öffentlich ist oder weil er Zugriff hat), könnte er die leaks entdecken.
-- **Access**: Wenn ein attacker auf ein account innerhalb der VCS platform zugreifen kann, könnte er **mehr visibility und permissions** erhalten.
-- **Register**: Einige platforms erlauben externen Nutzern einfach, ein account zu erstellen.
-- **SSO**: Einige platforms erlauben Nutzern nicht, sich zu registrieren, aber erlauben jedem den Zugriff mit einem gültigen SSO (also könnte ein attacker zum Beispiel sein Github-Konto verwenden, um einzutreten).
-- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... es gibt mehrere Arten von tokens, die ein user stehlen könnte, um auf irgendeine Weise auf ein repo zuzugreifen.
-- **Webhooks**: VCS platforms erlauben das Erstellen von webhooks. Wenn sie **nicht geschützt** sind mit nicht sichtbaren secrets, könnte ein **attacker sie missbrauchen**.
-- Wenn kein secret vorhanden ist, könnte der attacker den webhook der Drittanbieterplattform missbrauchen
-- Wenn das secret in der URL steht, passiert dasselbe und der attacker hat das secret ebenfalls
-- **Code compromise:** Wenn ein bösartiger Akteur irgendeine Art von **write** access auf die repos hat, könnte er versuchen, **bösartigen code einzuschleusen**. Um erfolgreich zu sein, könnte er **branch protections umgehen** müssen. Diese Aktionen können mit unterschiedlichen Zielen in mid ausgeführt werden:
+- **Leaks**: Wenn dein Code in den Commits leaks enthält und der Angreifer auf das Repo zugreifen kann (weil es öffentlich ist oder weil er Zugriff hat), könnte er die leaks entdecken.
+- **Access**: Wenn ein Angreifer auf **ein Konto innerhalb der VCS platform zugreifen** kann, könnte er **mehr Sichtbarkeit und Berechtigungen** erhalten.
+- **Register**: Einige Plattformen erlauben externen Nutzern einfach, ein Konto zu erstellen.
+- **SSO**: Einige Plattformen erlauben Benutzern nicht, sich zu registrieren, erlauben aber jedem, mit einem gültigen SSO zuzugreifen (also könnte ein Angreifer zum Beispiel sein Github-Konto verwenden, um einzutreten).
+- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... es gibt verschiedene Arten von Tokens, die ein Nutzer stehlen könnte, um auf irgendeine Weise auf ein Repo zuzugreifen.
+- **Webhooks**: VCS platforms erlauben das Erstellen von Webhooks. Wenn sie **nicht geschützt** sind durch nicht sichtbare secrets, könnte ein **Angreifer sie missbrauchen**.
+- Wenn kein secret vorhanden ist, könnte der Angreifer den webhook der Third-Party-Plattform missbrauchen
+- Wenn das secret in der URL steht, passiert dasselbe und der Angreifer hat außerdem das secret
+- **Code compromise:** Wenn ein bösartiger Akteur irgendeine Art von **write**-Zugriff auf die Repos hat, könnte er versuchen, **bösartigen Code einzuschleusen**. Um erfolgreich zu sein, müsste er möglicherweise **branch protections umgehen**. Diese Aktionen können mit verschiedenen Zielen im Blick durchgeführt werden:
 - Den main branch kompromittieren, um **production zu kompromittieren**.
-- Den main (oder andere branches) kompromittieren, um **developer machines zu kompromittieren** (da sie normalerweise test, terraform oder andere Dinge innerhalb des repo auf ihren Maschinen ausführen).
+- Den main (oder andere branches) kompromittieren, um **developer machines zu kompromittieren** (da sie normalerweise tests, terraform oder andere Dinge innerhalb des Repos auf ihren Maschinen ausführen).
 - **Die pipeline kompromittieren** (siehe nächsten Abschnitt)
 
 ## Pipelines Pentesting Methodology
 
-Der häufigste Weg, eine pipeline zu definieren, ist die Verwendung einer **CI configuration file, die im repository gehostet wird**, das die pipeline baut. Diese Datei beschreibt die Reihenfolge der ausgeführten jobs, Bedingungen, die den flow beeinflussen, und die settings der build environment.\
-Diese Dateien haben typischerweise einen festen Namen und ein festes Format, zum Beispiel — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) und die GitHub Actions YAML files unter .github/workflows. Wenn sie ausgelöst wird, **zieht der pipeline job den code** aus der ausgewählten Quelle (z. B. commit / branch) und **führt die in der CI configuration file angegebenen commands** gegen diesen code aus.
+Der gebräuchlichste Weg, eine pipeline zu definieren, ist die Verwendung einer **CI configuration file, die im Repository gehostet wird**, das die pipeline baut. Diese Datei beschreibt die Reihenfolge der ausgeführten Jobs, Bedingungen, die den Ablauf beeinflussen, und Einstellungen der Build-Umgebung.\
+Diese Dateien haben typischerweise einen konsistenten Namen und ein konsistentes Format, zum Beispiel — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), und die GitHub Actions YAML files, die unter .github/workflows liegen. Wenn sie ausgelöst wird, **zieht der pipeline job den code** aus der ausgewählten Quelle (z. B. commit / branch) und **führt die in der CI configuration file angegebenen Befehle** gegen diesen Code aus.
 
-Daher ist das ultimative Ziel des attackers, irgendwie **diese configuration files zu kompromittieren** oder die **commands, die sie ausführen**.
+Daher ist das ultimative Ziel des Angreifers, irgendwie **diese Konfigurationsdateien zu kompromittieren** oder die **Befehle, die sie ausführen**.
 
 > [!TIP]
-> Manche hosted builders lassen contributors den Docker build context und den Dockerfile path wählen. Wenn der context vom attacker kontrolliert wird, kannst du ihn außerhalb des repo setzen (z. B. ".."), um host files während des build einzulesen und secrets zu exfiltrieren. Siehe:
+> Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., "..") to ingest host files during build and exfiltrate secrets. See:
 >
 >{{#ref}}
 >docker-build-context-abuse.md
@@ -58,72 +58,73 @@ Daher ist das ultimative Ziel des attackers, irgendwie **diese configuration fil
 
 ### PPE - Poisoned Pipeline Execution
 
-Der Poisoned Pipeline Execution (PPE) Pfad nutzt permissions in einem SCM repository aus, um eine CI pipeline zu manipulieren und schädliche commands auszuführen. Benutzer mit den erforderlichen permissions können CI configuration files oder andere files, die vom pipeline job verwendet werden, ändern, um bösartige commands einzuschleusen. Dadurch wird die CI pipeline „vergiftet“ und diese bösartigen commands werden ausgeführt.
+Der Poisoned Pipeline Execution (PPE)-Pfad nutzt Berechtigungen in einem SCM repository aus, um eine CI pipeline zu manipulieren und schädliche Befehle auszuführen. Nutzer mit den erforderlichen Berechtigungen können CI configuration files oder andere von der pipeline verwendete Dateien ändern, um bösartige Befehle einzufügen. Dadurch wird die CI pipeline „vergiftet“, was zur Ausführung dieser bösartigen Befehle führt.
 
-Damit ein bösartiger Akteur einen PPE attack erfolgreich durchführen kann, muss er in der Lage sein:
+Damit ein bösartiger Akteur einen PPE-Angriff erfolgreich durchführen kann, muss er in der Lage sein:
 
-- **write access zur VCS platform** zu haben, da pipelines normalerweise ausgelöst werden, wenn ein push oder ein pull request ausgeführt wird. (Siehe die VCS pentesting methodology für eine Zusammenfassung der Möglichkeiten, Zugriff zu erhalten).
+- **Schreibzugriff auf die VCS platform** zu haben, da pipelines normalerweise ausgelöst werden, wenn ein push oder ein pull request durchgeführt wird. (Siehe die VCS pentesting methodology für eine Zusammenfassung der Wege, Zugriff zu erhalten).
 - Beachte, dass manchmal ein **externer PR als "write access" zählt**.
-- Auch wenn er write permissions hat, muss er sicherstellen, dass er die CI config file oder andere files, auf die die config angewiesen ist, **ändern kann**.
+- Selbst wenn er Schreibberechtigungen hat, muss er sicher sein, dass er die CI config file oder andere Dateien, auf die die config angewiesen ist, **ändern kann**.
 - Dafür muss er möglicherweise **branch protections umgehen** können.
 
-Es gibt 3 PPE-Varianten:
+Es gibt 3 PPE-Ausprägungen:
 
-- **D-PPE**: Ein **Direct PPE** attack tritt auf, wenn der Akteur die CI config file **ändert**, die ausgeführt werden soll.
-- **I-DDE**: Ein **Indirect PPE** attack tritt auf, wenn der Akteur eine **file** ändert, auf die sich die CI config file, die ausgeführt werden soll, **verlässt** (wie eine make file oder eine terraform config).
-- **Public PPE oder 3PE**: In manchen Fällen können pipelines von Nutzern ausgelöst werden, die **kein write access im repo haben** (und vielleicht nicht einmal Teil der org sind), weil sie einen PR senden können.
-- **3PE Command Injection**: Normalerweise setzen CI/CD pipelines **environment variables** mit **Informationen über den PR**. Wenn dieser Wert von einem attacker kontrolliert werden kann (wie der title des PR) und an einer **gefährlichen Stelle** verwendet wird (wie beim Ausführen von **sh commands**), könnte ein attacker dort commands **einschleusen**.
+- **D-PPE**: Ein **Direct PPE**-Angriff tritt auf, wenn der Akteur die CI config-Datei **ändert**, die ausgeführt werden soll.
+- **I-DDE**: Ein **Indirect PPE**-Angriff tritt auf, wenn der Akteur eine **Datei** **ändert**, auf die sich die CI config-Datei, die ausgeführt werden soll, **verlässt** (wie eine make file oder eine terraform config).
+- **Public PPE or 3PE**: In manchen Fällen können pipelines von Benutzern ausgelöst werden, die **keinen write access im Repo haben** (und möglicherweise nicht einmal Teil der org sind), weil sie einen PR senden können.
+- **3PE Command Injection**: Üblicherweise setzen CI/CD pipelines **Umgebungsvariablen** mit **Informationen über den PR**. Wenn dieser Wert von einem Angreifer kontrolliert werden kann (wie der Titel des PR) und an einer **gefährlichen Stelle** **verwendet** wird (wie beim Ausführen von **sh commands**), kann ein Angreifer dort **Befehle einschleusen**.
 
 ### Exploitation Benefits
 
-Wenn man die 3 Varianten kennt, um eine pipeline zu vergiften, kann man sehen, was ein attacker nach erfolgreicher exploitation erhalten könnte:
+Wenn man die 3 Ausprägungen kennt, eine pipeline zu vergiften, schauen wir uns an, was ein Angreifer nach erfolgreicher Ausnutzung erhalten könnte:
 
-- **Secrets**: Wie bereits erwähnt, benötigen pipelines **privileges** für ihre jobs (den code abrufen, ihn bauen, deployen...) und diese privileges werden normalerweise in **secrets** gewährt. Diese secrets sind normalerweise über **env variables oder files innerhalb des systems** zugänglich. Daher wird ein attacker immer versuchen, so viele secrets wie möglich zu exfiltrieren.
-- Abhängig von der pipeline platform muss der attacker die **secrets möglicherweise in der config angeben**. Das bedeutet, dass er, wenn er die CI configuration pipeline (**zum Beispiel I-PPE**) nicht ändern kann, **nur die secrets exfiltrieren könnte, die diese pipeline hat**.
-- **Computation**: Der code wird irgendwo ausgeführt; abhängig davon, wo er ausgeführt wird, könnte ein attacker weiter pivotieren.
-- **On-Premises**: Wenn die pipelines on premises ausgeführt werden, könnte ein attacker in einem **internen Netzwerk mit Zugriff auf mehr resources** landen.
-- **Cloud**: Der attacker könnte auf **andere Maschinen in der cloud** zugreifen, aber auch **tokens** von IAM roles/service accounts **exfiltrieren**, um **weiteren Zugriff innerhalb der cloud** zu erhalten.
-- **Platforms machine**: Manchmal werden die jobs auf den **machines der pipelines platform** ausgeführt, die sich normalerweise in einer cloud mit **keinem weiteren Zugriff** befinden.
-- **Select it:** Manchmal ist auf der **pipelines platform mehrere machines konfiguriert**, und wenn du die CI configuration file **ändern** kannst, kannst du **angeben, wo du den bösartigen code ausführen möchtest**. In dieser Situation wird ein attacker wahrscheinlich auf jeder möglichen machine eine reverse shell ausführen, um zu versuchen, sie weiter auszunutzen.
-- **Compromise production**: Wenn du in der pipeline bist und die finale version daraus gebaut und deployt wird, könntest du **den code kompromittieren, der in production ausgeführt werden wird**.
+- **Secrets**: Wie bereits erwähnt, benötigen pipelines **Privilegien** für ihre Jobs (den Code abrufen, bauen, deployen...) und diese Privilegien werden normalerweise in **secrets** gewährt. Auf diese secrets kann normalerweise über **env variables oder Dateien innerhalb des Systems** zugegriffen werden. Daher wird ein Angreifer immer versuchen, so viele secrets wie möglich zu exfiltrieren.
+- Je nach pipeline platform muss der Angreifer **möglicherweise die secrets in der config angeben**. Das bedeutet, dass, wenn der Angreifer die CI configuration pipeline nicht ändern kann (**I-PPE** zum Beispiel), er **nur die secrets exfiltrieren kann, die diese pipeline hat**.
+- **Computation**: Der Code wird irgendwo ausgeführt, und je nachdem, wo er ausgeführt wird, könnte ein Angreifer möglicherweise weiter pivoten.
+- **On-Premises**: Wenn die pipelines on premises ausgeführt werden, könnte ein Angreifer in einem **internen Netzwerk mit Zugriff auf mehr Ressourcen** landen.
+- **Cloud**: Der Angreifer könnte auf **andere Maschinen in der Cloud** zugreifen, aber auch **IAM roles/service accounts tokens** daraus exfiltrieren, um **weiteren Zugriff innerhalb der cloud** zu erhalten.
+- **Platforms machine**: Manchmal werden die Jobs auf den **pipelines platform machines** ausgeführt, die sich normalerweise in einer cloud mit **keinem weiteren Zugriff** befinden.
+- **Select it:** Manchmal hat die **pipelines platform mehrere Maschinen konfiguriert** und wenn du die CI configuration file **ändern kannst**, kannst du **angeben, wo du den bösartigen Code ausführen möchtest**. In dieser Situation wird ein Angreifer wahrscheinlich auf jeder möglichen Maschine eine reverse shell ausführen, um zu versuchen, sie weiter auszunutzen.
+- **Compromise production**: Wenn du in der pipeline bist und die finale Version daraus gebaut und deployed wird, könntest du den Code kompromittieren, der schließlich in production läuft.
 
 ### Dependency & Registry Supply-Chain Abuse
 
-Das Kompromittieren einer CI/CD pipeline oder das Stehlen von credentials daraus kann es einem attacker ermöglichen, von **pipeline execution** zu **ecosystem-wide code execution** zu wechseln, indem dependencies oder release tooling mit Backdoors versehen werden:
+Das Kompromittieren einer CI/CD pipeline oder das Stehlen von Credentials daraus kann einem Angreifer ermöglichen, von **pipeline execution** zu **ecosystem-wide code execution** überzugehen, indem Dependencies oder Release-Tooling backdoored werden:
 
-- **Install-time code execution via package hooks**: eine package version veröffentlichen, die `preinstall`, `postinstall`, `prepare` oder ähnliche hooks hinzufügt, sodass die payload während der dependency installation automatisch auf developer workstations und CI runners ausgeführt wird.
-- **Secondary execution paths**: selbst wenn targets mit `--ignore-scripts` installieren, kann ein bösartiges package trotzdem einen **common CLI name** im `bin`-Feld registrieren, sodass der attacker-controlled wrapper in `PATH` verlinkt wird und später ausgeführt wird, wenn der command verwendet wird.
-- **Runtime bootstrapping**: ein kleiner installer kann während der installation eine zweite runtime oder toolchain herunterladen (zum Beispiel Bun oder einen gepackten interpreter) und dann die Haupt-payload damit starten, wodurch lokale dependency requirements umgangen werden.
-- **Credential harvesting from build environments**: sobald code in CI läuft, prüfe environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs und lokale tooling wie `gh auth token`. In GitHub Actions auch nach runner-spezifischen secrets und artifacts suchen.
-- **Workflow injection with stolen GitHub tokens**: ein token mit **`repo` + `workflow`** permissions reicht aus, um einen branch zu erstellen, eine bösartige file in `.github/workflows/` zu committen, sie auszulösen, die erzeugten artifacts/logs zu sammeln und dann den temporären branch/workflow run zu löschen, um Spuren zu reduzieren.
-- **Wormable registry propagation**: gestohlene npm tokens sollten auf **publish** permissions und darauf geprüft werden, ob sie 2FA umgehen. Wenn ja, writable packages enumerieren, ihre tarballs herunterladen, einen loader wie `setup.mjs` einfügen, `preinstall` so setzen, dass er ihn ausführt, die patch version erhöhen und erneut veröffentlichen. Dadurch wird eine einzige CI compromise in nachgelagerte auto-execution in anderen Umgebungen verwandelt.
+- **Install-time code execution via package hooks**: veröffentliche eine package version, die `preinstall`, `postinstall`, `prepare` oder ähnliche hooks hinzufügt, sodass das payload automatisch auf developer workstations und CI runners während der Dependency-Installation ausgeführt wird.
+- **Secondary execution paths**: selbst wenn Ziele mit `--ignore-scripts` installieren, kann ein bösartiges package dennoch einen **common CLI name** im `bin`-Feld registrieren, sodass der vom Angreifer kontrollierte Wrapper in `PATH` symlinked wird und später ausgeführt wird, wenn der Befehl verwendet wird.
+- **Runtime bootstrapping**: ein kleiner Installer kann während der Installation ein zweites runtime oder Toolchain herunterladen (zum Beispiel Bun oder einen gepackten Interpreter) und dann das main payload damit starten, wodurch lokale Dependency-Anforderungen umgangen werden.
+- **Credential harvesting from build environments**: sobald code innerhalb von CI läuft, überprüfe environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs und lokale Tools wie `gh auth token`. Auf GitHub Actions solltest du auch runner-specific secrets und artifacts suchen.
+- **Workflow injection with stolen GitHub tokens**: ein Token mit **`repo` + `workflow`**-Berechtigungen reicht aus, um einen branch zu erstellen, eine bösartige Datei innerhalb von `.github/workflows/` zu committen, sie auszulösen, die erzeugten artifacts/logs zu sammeln und dann den temporären branch/workflow run zu löschen, um Spuren zu reduzieren.
+- **Wormable registry propagation**: gestohlene npm tokens sollten auf **publish**-Berechtigungen und darauf geprüft werden, ob sie 2FA umgehen. Wenn ja, enumere schreibbare packages, lade ihre tarballs herunter, injiziere einen Loader wie `setup.mjs`, setze `preinstall`, damit er ausgeführt wird, erhöhe die patch version und republiere. Das verwandelt einen einzelnen CI-Komprimittierungsfall in downstream auto-execution in anderen Umgebungen.
 
-#### Praktische checks während einer assessment
+#### Practical checks during an assessment
 
-- Release automation auf package-manager hooks überprüfen, die zu `package.json` hinzugefügt wurden, unerwartete `bin`-Einträge oder version bumps, die nur das release artifact ändern.
-- Prüfen, ob CI langlebige registry credentials in Klartextdateien wie `~/.npmrc` speichert, statt kurzlebiges OIDC oder trusted publishing zu verwenden.
-- Verifizieren, ob GitHub tokens, die in CI verfügbar sind, workflow files schreiben oder branches/tags erstellen können.
-- Wenn ein kompromittiertes package vermutet wird, das veröffentlichte tarball und nicht nur das Git repository untersuchen, weil der bösartige loader/runtime nur im veröffentlichten artifact existieren könnte.
-- Nach unerwarteter package-manager execution in CI suchen, wie `npm install` statt `npm ci`, unerwartete Bun downloads/execution oder neue workflow artifacts, die aus transient branches erzeugt wurden.
+- Überprüfe die Release-Automation auf package-manager hooks, die zu `package.json` hinzugefügt wurden, unerwartete `bin`-Einträge oder Versionssprünge, die nur das Release-Artifact ändern.
+- Prüfe, ob CI langfristige Registry-Credentials in Klartextdateien wie `~/.npmrc` speichert, anstatt kurzlebiges OIDC oder trusted publishing zu verwenden.
+- Verifiziere, ob GitHub tokens, die in CI verfügbar sind, workflow files schreiben oder branches/tags erstellen können.
+- Wenn ein kompromittiertes package vermutet wird, untersuche den veröffentlichten tarball und nicht nur das Git repository, da der bösartige Loader/runtime nur im veröffentlichten Artifact existieren könnte.
+- Suche in CI nach unerwarteter package-manager execution wie `npm install` statt `npm ci`, unerwarteten Bun-Downloads/-Ausführungen oder neuen workflow artifacts, die aus transient branches erzeugt wurden.
+- Überprüfe GitOps deployment engines ebenfalls als CI/CD targets. Argo CD-spezifische Enumeration, repo-server abuse und Redis cache poisoning attacks werden in [Argo CD Security](argocd-security.md) behandelt.
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ist ein Open-Source-Tool zum Prüfen deiner software supply chain stack auf security compliance basierend auf einem neuen [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Das Auditing konzentriert sich auf den gesamten SDLC-Prozess und kann Risiken von code time bis deploy time aufdecken.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ist ein Open-Source-Tool zur Prüfung deines software supply chain stack auf Security-Compliance basierend auf einem neuen [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Das Auditing fokussiert sich auf den gesamten SDLC-Prozess, wobei es Risiken von der code time bis zur deploy time aufdecken kann.
 
 ### Top 10 CI/CD Security Risk
 
-Sieh dir diesen interessanten Artikel über die Top 10 CI/CD risks laut Cider an: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Sieh dir diesen interessanten Artikel über die Top 10 CI/CD-Risiken gemäß Cider an: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- Auf jeder platform, die du lokal ausführen kannst, findest du Hinweise, wie du sie lokal startest, damit du sie so konfigurieren kannst, wie du sie testen möchtest
+- Auf jeder Plattform, die du lokal ausführen kannst, findest du eine Anleitung, wie du sie lokal startest, damit du sie so konfigurieren kannst, wie du sie zum Testen möchtest
 - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
 ### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** ist ein Static Code Analysis Tool für infrastructure-as-code.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** ist ein statisches Code-Analyse-Tool für infrastructure-as-code.
 
 ## References