HackTricks-wiki · carlospolop · Aug 17, 2026
diff --git a/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md b/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md
@@ -1,5 +1,7 @@
 # Ansible Tower / AWX / Automation controller Security
 
+{{#include ../banners/hacktricks-training.md}}
+
 ## Basic Information
 
 **Ansible Tower** or it's opensource version [**AWX**](https://github.com/ansible/awx) is also known as **Ansible’s user interface, dashboard, and REST API**.<sup>[[3]](#references)</sup> With **role-based access control**, job scheduling, and graphical inventory management, you can manage your Ansible infrastructure from a modern UI. Tower’s REST API and command-line interface make it simple to integrate it into current tools and workflows.

diff --git a/src/pentesting-ci-cd/apache-airflow-security/README.md b/src/pentesting-ci-cd/apache-airflow-security/README.md
@@ -1,5 +1,7 @@
 # Apache Airflow Security
 
+{{#include ../../banners/hacktricks-training.md}}
+
 ### Basic Information
 
 [**Apache Airflow**](https://airflow.apache.org) serves as a platform for **orchestrating and scheduling data pipelines or workflows**. The term "orchestration" in the context of data pipelines signifies the process of arranging, coordinating, and managing complex data workflows originating from various sources. The primary purpose of these orchestrated data pipelines is to furnish processed and consumable data sets. These data sets are extensively utilized by a myriad of applications, including but not limited to business intelligence tools, data science and machine learning models, all of which are foundational to the functioning of big data applications.<sup>[[1]](#references)</sup>
@@ -198,4 +200,3 @@ If they are used for example inside a a bash command, you could perform a comman
 
 {{#include ../../banners/hacktricks-training.md}}
 
-
diff --git a/src/pentesting-ci-cd/apache-airflow-security/airflow-configuration.md b/src/pentesting-ci-cd/apache-airflow-security/airflow-configuration.md
@@ -1,5 +1,7 @@
 # Airflow Configuration
 
+{{#include ../../banners/hacktricks-training.md}}
+
 ## Configuration File
 
 **Apache Airflow** generates a **config file** in all the airflow machines called **`airflow.cfg`** in the home of the airflow user. This config file contains configuration information and **might contain interesting and sensitive information.**<sup>[[10]](#references)</sup>

diff --git a/src/pentesting-ci-cd/apache-airflow-security/airflow-rbac.md b/src/pentesting-ci-cd/apache-airflow-security/airflow-rbac.md
@@ -1,5 +1,7 @@
 # Airflow RBAC
 
+{{#include ../../banners/hacktricks-training.md}}
+
 ## RBAC
 
 Airflow ships with five default roles: **Admin**, **User**, **Op**, **Viewer**, and **Public**. Only **`Admin`** users can configure or alter role permissions, and the defaults should remain unchanged; create a custom role when a more granular permission set is needed.<sup>[[1]](#references)</sup>
@@ -47,4 +49,3 @@ No permissions.<sup>[[3]](#references)</sup>
 
 {{#include ../../banners/hacktricks-training.md}}
 
-
diff --git a/src/pentesting-ci-cd/argocd-security.md b/src/pentesting-ci-cd/argocd-security.md
@@ -1,5 +1,7 @@
 # Argo CD Security
 
+{{#include ../banners/hacktricks-training.md}}
+
 ## Basic Information
 
 [Argo CD](https://argo-cd.readthedocs.io/) is a GitOps continuous delivery platform for Kubernetes. It watches Git repositories, renders Kubernetes manifests with tools such as Helm, Kustomize, Jsonnet or config management plugins, and reconciles the live cluster state with the desired state stored in Git.<sup>[[2]](#references)</sup>

diff --git a/src/pentesting-ci-cd/atlantis-security.md b/src/pentesting-ci-cd/atlantis-security.md
@@ -1,5 +1,7 @@
 # Atlantis Security
 
+{{#include ../banners/hacktricks-training.md}}
+
 ### Basic Information
 
 Atlantis is a pull-request-driven service that runs Terraform commands from comments on a Git host.<sup>[[1]](#references)[[13]](#references)</sup>
@@ -391,4 +393,3 @@ You can also pass these as environment variables `ATLANTIS_WEB_BASIC_AUTH=true`
 - [29] [Managing protected branches | GitHub Docs](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches)
 
 {{#include ../banners/hacktricks-training.md}}
-
diff --git a/src/pentesting-ci-cd/chef-automate-security/README.md b/src/pentesting-ci-cd/chef-automate-security/README.md
@@ -1,5 +1,7 @@
 # Chef Automate Security
 
+{{#include ../../banners/hacktricks-training.md}}
+
 ## What is Chef Automate
 
 Chef Automate is a platform for infrastructure automation, compliance, and application delivery.<sup>[[1]](#references)</sup> It exposes a web UI (often Angular) that talks to backend gRPC services via a gRPC-Gateway, providing REST-like endpoints under paths such as /api/v0/.<sup>[[3]](#references)</sup>

diff --git a/...entesting-ci-cd/chef-automate-security/chef-automate-enumeration-and-attacks.md b/...entesting-ci-cd/chef-automate-security/chef-automate-enumeration-and-attacks.md
@@ -1,5 +1,7 @@
 # Chef Automate Enumeration & Attacks
 
+{{#include ../../banners/hacktricks-training.md}}
+
 ## Overview
 
 This page collects practical techniques to enumerate and attack Chef Automate instances, with emphasis on:

diff --git a/src/pentesting-ci-cd/circleci-security.md b/src/pentesting-ci-cd/circleci-security.md
@@ -1,5 +1,7 @@
 # CircleCI Security
 
+{{#include ../banners/hacktricks-training.md}}
+
 ### Basic Information
 
 [**CircleCI**](https://circleci.com/docs/2.0/about-circleci/) is a Continuos Integration platform where you can **define templates** indicating what you want it to do with some code and when to do it. This way you can **automate testing** or **deployments** directly **from your repo master branch** for example.<sup>[[1]](#references)</sup>
@@ -85,6 +87,27 @@ These are secrets that are **org wide**. By **default**, a new context uses the
 
 ### Attacks
 
+#### CircleCI MCP server: `Host`/`Origin` bypass to pipeline RCE
+
+CircleCI's remote MCP transport can be deployed in **shared-token mode**: the server keeps the organization's `CIRCLECI_TOKEN`, while `REQUIRE_REQUEST_TOKEN=false` lets callers access `/mcp` without presenting their own credential. In versions `0.16.1` through `0.19.1`, combining this mode with the default `MCP_BIND_HOST=0.0.0.0` exposed that delegated token to any peer able to route to the listening port.<sup>[[11]](#references)[[12]](#references)</sup>
+
+The vulnerable gate treated an allowlisted `Host` plus an absent `Origin` as sufficient. This only mitigates browser-based DNS rebinding: a direct HTTP client controls `Host` and can simply omit `Origin`. Moreover, `Host: localhost` identifies the requested virtual host, **not** the interface through which the TCP connection arrived, so it does not prove that a wildcard-bound request came from loopback.<sup>[[11]](#references)[[12]](#references)</sup>
+
+During an authorized assessment, compare a rejected host with the expected loopback spelling (include the listening port if the allowlist does). `curl` sends no `Origin` by default; `-H 'Origin:'` also ensures that the header is omitted. A change from the guard's `403` to an MCP/HTTP transport response shows that the client-controlled headers passed the gate—it does not by itself prove tool authorization.<sup>[[11]](#references)[[12]](#references)</sup>
+
+```bash
+target='http://10.0.0.10:8000'
+
+curl -i "$target/mcp" -H 'Host: rejected.invalid'
+curl -i "$target/mcp" -H 'Host: localhost:8000' -H 'Origin:'
+```
+
+Once unauthorized MCP access is obtained, `run_pipeline` supplies the execution primitive: it accepts attacker-controlled CircleCI pipeline YAML, so a configuration containing a shell-capable `run:` step executes inside CI using the server's delegated token. No separate command-injection bug is required; the resulting job may inherit project variables, contexts, cloud/OIDC identity, signing keys, or registry credentials according to its CircleCI permissions. The [environment-exfiltration pipeline below](#exfiltrate-project-secrets) illustrates the downstream primitive.<sup>[[11]](#references)[[12]](#references)</sup>
+
+For detection, flag `Host: localhost`/loopback hostnames received from non-loopback peers, missing `Origin` on externally reachable MCP requests, and unexpected `run_pipeline` calls. Correlate MCP request/tool identifiers with CircleCI pipeline and job IDs, the submitted configuration, context use, and cloud or secret-manager audit events; endpoint-only logs miss the consequential activity in the delegated CI job.<sup>[[11]](#references)[[12]](#references)</sup>
+
+Upgrade to `0.19.2` or later. On older releases, set `REQUIRE_REQUEST_TOKEN=true`; if shared-token mode is unavoidable, bind to loopback with `MCP_BIND_HOST=127.0.0.1` and restrict reachability. The patch refuses to start unauthenticated remote transport on a non-loopback bind unless `MCP_ALLOW_UNAUTHENTICATED_NETWORK_ACCESS=true` explicitly acknowledges the risk. It deliberately still allows absent `Origin` and retains the wildcard default because these headers remain a DNS-rebinding defense, while caller authentication is the actual security boundary.<sup>[[12]](#references)</sup>
+
 #### Search Clear Text Secrets
 
 If you have **access to the VCS** (like github) check the file `.circleci/config.yml` of **each repo on each branch** and **search** for potential **clear text secrets** stored in there.
@@ -262,6 +285,7 @@ jobs:
 - [8] [Secure secrets handling](https://circleci.com/docs/guides/security/security-recommendations/)
 - [9] [CircleCI’s self-hosted runner overview](https://circleci.com/docs/guides/execution-runner/runner-overview/)
 - [10] [Configuration reference](https://circleci.com/docs/reference/configuration-reference/)
+- [11] [Critical Unauthenticated Remote Code Execution in CircleCI's MCP Server](https://remedio.io/blog/the-critical-unauthenticated-rce-vulnerability-in-circlecis-mcp-server)
+- [12] [GHSA-xv5j-cwgj-22r4: Remote transport Host/Origin authentication bypass](https://github.com/CircleCI-Public/mcp-server-circleci/security/advisories/GHSA-xv5j-cwgj-22r4)
 
 {{#include ../banners/hacktricks-training.md}}
-
diff --git a/src/pentesting-ci-cd/cloudflare-security/README.md b/src/pentesting-ci-cd/cloudflare-security/README.md
@@ -1,5 +1,7 @@
 # Cloudflare Security
 
+{{#include ../../banners/hacktricks-training.md}}
+
 In a Cloudflare account there are some **general settings and services** that can be configured. In this page we are going to **analyze the security related settings of each section:**
 
 <figure><img src="../../images/image (117).png" alt=""><figcaption></figcaption></figure>

diff --git a/src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md b/src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md
@@ -1,5 +1,7 @@
 # Cloudflare Domains
 
+{{#include ../../banners/hacktricks-training.md}}
+
 In each zone configured in Cloudflare there are **general settings and services** that can be configured. In this page we are going to **analyze the security-related settings of each section:**
 
 <figure><img src="../../images/image (101).png" alt=""><figcaption></figcaption></figure>
@@ -171,4 +173,3 @@ TODO
 - [37] [API deprecations](https://developers.cloudflare.com/fundamentals/api/reference/deprecations/)
 
 {{#include ../../banners/hacktricks-training.md}}
-
diff --git a/...-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md b/...-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md
@@ -1,5 +1,7 @@
 # Abusing Cloudflare Workers as pass-through proxies (IP rotation, FireProx-style)
 
+{{#include ../../banners/hacktricks-training.md}}
+
 Cloudflare Workers can be deployed as transparent HTTP pass-through proxies where the upstream target URL is supplied by the client. Requests egress from Cloudflare's network so the target observes Cloudflare IPs instead of the client's. This mirrors the well-known FireProx technique on AWS API Gateway, but uses Cloudflare Workers.<sup>[[1]](#references)[[4]](#references)</sup>
 
 ### Key capabilities

diff --git a/src/pentesting-ci-cd/cloudflare-security/cloudflare-zero-trust-network.md b/src/pentesting-ci-cd/cloudflare-security/cloudflare-zero-trust-network.md
@@ -1,5 +1,7 @@
 # Cloudflare Zero Trust Network
 
+{{#include ../../banners/hacktricks-training.md}}
+
 In a **Cloudflare Zero Trust Network** account there are some **settings and services** that can be configured. In this page we are going to **analyze the security related settings of each section:**
 
 <figure><img src="../../images/image (206).png" alt=""><figcaption></figcaption></figure>

diff --git a/src/pentesting-ci-cd/concourse-security/README.md b/src/pentesting-ci-cd/concourse-security/README.md
@@ -1,5 +1,7 @@
 # Concourse Security
 
+{{#include ../../banners/hacktricks-training.md}}
+
 ## Basic Information
 
 Concourse allows you to **build pipelines** to automatically run tests, actions and build images whenever you need it (time based, when something happens...)<sup>[[1]](#references)[[2]](#references)</sup>
@@ -35,4 +37,3 @@ concourse-enumeration-and-attacks.md
 
 {{#include ../../banners/hacktricks-training.md}}
 
-
diff --git a/src/pentesting-ci-cd/concourse-security/concourse-architecture.md b/src/pentesting-ci-cd/concourse-security/concourse-architecture.md
@@ -1,5 +1,7 @@
 # Concourse Architecture
 
+{{#include ../../banners/hacktricks-training.md}}
+
 ## Concourse Architecture
 
 
@@ -42,4 +44,3 @@ In order to execute tasks, Concourse must have some workers. These workers **reg
 - [7] [Baggageclaim](https://github.com/concourse/baggageclaim)
 
 {{#include ../../banners/hacktricks-training.md}}
-
diff --git a/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md b/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md
@@ -1,5 +1,7 @@
 # Concourse Enumeration & Attacks
 
+{{#include ../../banners/hacktricks-training.md}}
+
 ## Concourse Enumeration & Attacks
 
 

diff --git a/src/pentesting-ci-cd/concourse-security/concourse-lab-creation.md b/src/pentesting-ci-cd/concourse-security/concourse-lab-creation.md
@@ -1,5 +1,7 @@
 # Concourse Lab Creation
 
+{{#include ../../banners/hacktricks-training.md}}
+
 ## Testing Environment
 
 ### Running Concourse
@@ -172,4 +174,3 @@ Check a YAML pipeline example that triggers on new commits to master in [https:/
 - [15] [Across Step Modifier - Concourse](https://concourse-ci.org/docs/steps/modifier-and-hooks/across/)
 
 {{#include ../../banners/hacktricks-training.md}}
-
diff --git a/src/pentesting-ci-cd/docker-build-context-abuse.md b/src/pentesting-ci-cd/docker-build-context-abuse.md
@@ -1,5 +1,7 @@
 # Abusing Docker Build Context in Hosted Builders (Path Traversal, Exfil, and Cloud Pivot)
 
+{{#include ../banners/hacktricks-training.md}}
+
 ## TL;DR
 
 If a CI/CD platform or hosted builder lets contributors specify the Docker build context path and Dockerfile path, you can often set the context to a parent directory (e.g., "..") and make host files part of the build context. Then, an attacker-controlled Dockerfile can COPY and exfiltrate secrets found in the builder user’s home (for example, ~/.docker/config.json). Stolen registry tokens may also work against the provider’s control-plane APIs, enabling org-wide RCE.<sup>[[1]](#references)[[3]](#references)[[4]](#references)[[5]](#references)[[6]](#references)</sup>

diff --git a/src/pentesting-ci-cd/gitblit-security/README.md b/src/pentesting-ci-cd/gitblit-security/README.md
@@ -1,5 +1,7 @@
 # Gitblit Security
 
+{{#include ../../banners/hacktricks-training.md}}
+
 ## What is Gitblit
 
 Gitblit is a self‑hosted Git server written in Java.<sup>[[1]](#references)</sup> It can run as a standalone JAR or in servlet containers and ships an embedded SSH service (Apache MINA SSHD) for Git over SSH.<sup>[[1]](#references)[[2]](#references)[[3]](#references)[[4]](#references)</sup>

diff --git a/...sting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md b/...sting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md
@@ -1,5 +1,7 @@
 # Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
 
+{{#include ../../banners/hacktricks-training.md}}
+
 ## Summary
 
 CVE-2024-28080 is an authentication bypass in Gitblit's embedded SSH transport caused by session state being treated as authenticated before a public-key signature is verified. In the vulnerable v1.9.3 implementation, a matching public key populated the SSH client state and the password authenticator accepted any subsequent password without validating it, so an attacker who knows a Gitblit username and one of that account's registered public keys can authenticate without the private key or a valid password.<sup>[[1]](#references)[[5]](#references)[[6]](#references)[[7]](#references)[[9]](#references)</sup>
@@ -130,4 +132,3 @@ Related protocol/design notes and literature:
 - [15] [OpenSSH client public-key authentication source](https://github.com/openssh/openssh-portable/blob/master/sshconnect2.c)
 
 {{#include ../../banners/hacktricks-training.md}}
-
diff --git a/src/pentesting-ci-cd/gitea-security/README.md b/src/pentesting-ci-cd/gitea-security/README.md
@@ -1,5 +1,7 @@
 # Gitea Security
 
+{{#include ../../banners/hacktricks-training.md}}
+
 ## What is Gitea
 
 **Gitea** is a **self-hosted community managed lightweight code hosting** solution written in Go.<sup>[[1]](#references)</sup>
@@ -158,4 +160,3 @@ If you are inside the server you can also **use the `gitea` binary** to access/m
 - [21] [Gitea Command Line | Gitea Documentation](https://docs.gitea.com/1.26/administration/command-line)
 
 {{#include ../../banners/hacktricks-training.md}}
-
diff --git a/src/pentesting-ci-cd/gitea-security/basic-gitea-information.md b/src/pentesting-ci-cd/gitea-security/basic-gitea-information.md
@@ -1,5 +1,7 @@
 # Basic Gitea Information
 
+{{#include ../../banners/hacktricks-training.md}}
+
 ## Basic Structure
 
 The basic Gitea environment structure is to group repos by **organization(s),** each of them may contain **several repositories** and **several teams.** However, note that just like in github users can have repos outside of the organization.<sup>[[1]](#references)</sup>

diff --git a/src/pentesting-ci-cd/github-security/README.md b/src/pentesting-ci-cd/github-security/README.md
@@ -1,5 +1,7 @@
 # Github Security
 
+{{#include ../../banners/hacktricks-training.md}}
+
 ## What is Github
 
 (From [here](https://kinsta.com/knowledgebase/what-is-github/)) At a high level, **GitHub is a website and cloud-based service that helps developers store and manage their code, as well as track and control changes to their code**.<sup>[[8]](#references)</sup>
@@ -485,4 +487,3 @@ For more information, see [Chainguard’s imposter-commits research](https://www
 - [54] [GitHub public SSH keys (example: octocat)](https://github.com/octocat.keys)
 
 {{#include ../../banners/hacktricks-training.md}}
-
diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
@@ -1,5 +1,7 @@
 # Abusing Github Actions
 
+{{#include ../../../banners/hacktricks-training.md}}
+
 ## Tools
 
 The following tools are useful to find Github Action workflows and even find vulnerable ones:
@@ -954,4 +956,3 @@ An organization in GitHub is very proactive in reporting accounts to GitHub. All
 - [45] [Vulnerable GitHub Actions Workflows: CI/CD Pipeline Attacks](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks)
 - [46] [actions/toolkit core package - GitHub](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret)
 {{#include ../../../banners/hacktricks-training.md}}
-
diff --git a/...g-ci-cd/github-security/abusing-github-actions/gh-actions-artifact-poisoning.md b/...g-ci-cd/github-security/abusing-github-actions/gh-actions-artifact-poisoning.md
@@ -1,6 +1,7 @@
 # Gh Actions - Artifact Poisoning
 
+{{#include ../../../banners/hacktricks-training.md}}
+
 ## References
 
 {{#include ../../../banners/hacktricks-training.md}}
-
diff --git a/...ting-ci-cd/github-security/abusing-github-actions/gh-actions-cache-poisoning.md b/...ting-ci-cd/github-security/abusing-github-actions/gh-actions-cache-poisoning.md
@@ -1,5 +1,7 @@
 # GH Actions - Cache Poisoning
 
+{{#include ../../../banners/hacktricks-training.md}}
+
 ## Overview
 
 The GitHub Actions cache is shared across workflow runs in a repository, subject to branch and tag scope, rather than isolated per workflow or job. Historically, any workflow run with cache-write access that knew a cache `key` (or `restore-keys`) could populate that entry even if the job only had `permissions: contents: read`, so an attacker who compromised a low-privilege job could poison a cache that a privileged release job later restored.<sup>[[1]](#references)[[2]](#references)[[6]](#references)</sup> This is how the Ultralytics compromise pivoted from a `pull_request_target` workflow into the PyPI publishing pipeline.<sup>[[1]](#references)[[5]](#references)</sup>

diff --git a/.../github-security/abusing-github-actions/gh-actions-context-script-injections.md b/.../github-security/abusing-github-actions/gh-actions-context-script-injections.md
@@ -1,5 +1,7 @@
 # Gh Actions - Context Script Injections
 
+{{#include ../../../banners/hacktricks-training.md}}
+
 ## Understanding the risk
 
 GitHub Actions renders expressions ${{ ... }} before the step executes. The rendered value is pasted into the step’s program (for run steps, a shell script). If you interpolate untrusted input directly inside run:, the attacker controls part of the shell program and can execute arbitrary commands.<sup>[[5]](#references)[[7]](#references)[[8]](#references)</sup>

diff --git a/...-cd/github-security/abusing-github-actions/gh-actions-npm-supply-chain-abuse.md b/...-cd/github-security/abusing-github-actions/gh-actions-npm-supply-chain-abuse.md
@@ -1,5 +1,7 @@
 # GH Actions - npm Supply Chain Abuse
 
+{{#include ../../../banners/hacktricks-training.md}}
+
 ## Overview
 
 After an attacker gets code execution in a GitHub Actions release workflow, maintainer workstation, or package build pipeline, npm publishing becomes a high-impact pivot. The goal is usually to steal publisher identity material, publish malicious versions, and turn downstream installs into more credential-generation nodes.<sup>[[1]](#references)</sup>

diff --git a/src/pentesting-ci-cd/github-security/accessible-deleted-data-in-github.md b/src/pentesting-ci-cd/github-security/accessible-deleted-data-in-github.md
@@ -1,5 +1,7 @@
 # Accessible Deleted Data in GitHub
 
+{{#include ../../banners/hacktricks-training.md}}
+
 These ways to access data from GitHub that was supposedly deleted were [**reported in this blog post**](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github).<sup>[[1]](#references)</sup>
 
 ## Accessing Deleted Fork Data
@@ -54,4 +56,3 @@ The latter uses a short SHA-1 value that can be brute-forced.<sup>[[1]](#referen
 - [3] [Git revisions documentation](https://git-scm.com/docs/revisions)
 
 {{#include ../../banners/hacktricks-training.md}}
-
diff --git a/src/pentesting-ci-cd/github-security/basic-github-information.md b/src/pentesting-ci-cd/github-security/basic-github-information.md
@@ -1,5 +1,7 @@
 # Basic Github Information
 
+{{#include ../../banners/hacktricks-training.md}}
+
 ## Basic Structure
 
 The basic github environment structure of a big **company** is to own an **enterprise** which owns **several organizations** and each of them may contain **several repositories** and **several teams.**. Smaller companies may just **own one organization and no enterprises**.<sup>[[4]](#references)[[13]](#references)</sup>
@@ -300,4 +302,3 @@ This chain prevents a single collaborator from retagging or force-publishing rel
 - [39] [About rulesets](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)
 
 {{#include ../../banners/hacktricks-training.md}}
-
diff --git a/src/pentesting-ci-cd/gogs-security/README.md b/src/pentesting-ci-cd/gogs-security/README.md
@@ -1,5 +1,7 @@
 # Gogs Security
 
+{{#include ../../banners/hacktricks-training.md}}
+
 ## What is Gogs
 
 **Gogs** is a **self-hosted lightweight Git service** written in Go. From an attacker point of view, treat it as a **multi-tenant Git hosting platform** where a low-privileged user may still control branch names, pull requests, webhooks, tokens, and repository settings.<sup>[[1]](#references)</sup>