diff --git a/src/pentesting-ci-cd/gogs-security/README.md b/src/pentesting-ci-cd/gogs-security/README.md
new file mode 100644
index 000000000..8c9153367
--- /dev/null
+++ b/src/pentesting-ci-cd/gogs-security/README.md
@@ -0,0 +1,103 @@
+# Gogs Security
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Gogs क्या है
+
+**Gogs** एक **self-hosted हल्का Git service** है जो Go में लिखा गया है। attacker के दृष्टिकोण से, इसे एक **multi-tenant Git hosting platform** की तरह समझें, जहाँ low-privileged user भी branch names, pull requests, webhooks, tokens, और repository settings को control कर सकता है।
+
+## refs / branch names के through Git option injection
+
+अगर कोई application attacker-controlled **ref name** को सीधे किसी Git command में **`--` या `--end-of-options` के बिना** pass करती है, तो `--` से शुरू होने वाली branch **Git option** के रूप में parse हो सकती है, data के बजाय।
+
+Typical dangerous pattern:
+```bash
+git <subcommand> <user-controlled-ref>
+```
+डिफेंसिव code में अपेक्षित safer pattern:
+```bash
+git <subcommand> -- <user-controlled-ref>
+# or
+git <subcommand> --end-of-options <user-controlled-ref>
+```
+एक सामान्य गलत धारणा यह है कि ref को `git rev-parse --verify <ref>` से validate करना पर्याप्त है। ऐसा **नहीं** है:
+
+- attacker पहले `--` से शुरू होने वाला नाम वाला एक **real branch** बना सकता है
+- `rev-parse --verify` केवल यह जांचता है कि ref किसी object को resolve करता है
+- बाद में किया गया कोई unsafe Git invocation उसी value को **option** के रूप में parse कर सकता है
+
+यह किसी भी Git-hosting feature को, जो stored branch names को reuse करती है, एक संभावित RCE primitive में बदल देता है।
+
+## RCE के लिए `git rebase --exec` का abuse
+
+`git rebase` `--exec=<cmd>` को support करता है, जो commits को replay करने के बाद command को `sh -c` के through चलाता है। इसलिए, यदि किसी pull request की base branch इस तरह की call तक पहुंचती है:
+```bash
+git rebase --quiet <baseBranch> <headBranch>
+```
+and `<baseBranch>` आक्रमणकर्ता-नियंत्रित है, एक branch जैसे:
+```bash
+--exec=touch${IFS}/tmp/rce_proof
+```
+को एक **Git flag** के रूप में interpret किया जा सकता है, branch name के बजाय।
+
+### `${IFS}` क्यों important है
+
+Git refs में literal spaces नहीं हो सकते, लेकिन shell expansion फिर भी होती है जब Git `--exec` को `sh -c` के जरिए execute करता है। `${IFS}` runtime पर whitespace में expand होता है, जिससे ऐसे payloads संभव होते हैं:
+```bash
+--exec=touch${IFS}/tmp/rce_proof
+--exec=id${IFS}>/tmp/out
+```
+Git-forbidden characters (`:`, `~`, `^`, `?`, `*`, `[`, `\\`, `//`) की आवश्यकता वाले payloads के लिए, real command को encode करें और execution time पर उसे decode करें:
+```bash
+--exec=echo${IFS}<base64_payload>|base64${IFS}-d|sh
+```
+## Windows-specific payload delivery
+
+Windows पर, inline payloads अधिक सीमित होते हैं क्योंकि Git branch refs को files के रूप में store करता है और NTFS filenames में `|` जैसे characters को forbid करता है। एक practical alternative है:
+
+1. repository में एक payload script commit करें (उदाहरण के लिए `.abcdef`)
+2. इस तरह एक branch बनाएं:
+```bash
+--exec=sh${IFS}.abcdef
+```
+यदि Git for Windows **MSYS2 `sh`** के through payload launch करता है, तो PowerShell metacharacters mangled हो सकते हैं. एक practical workaround यह है कि committed script इसको call करे:
+```bash
+cmd.exe //c .abcdef.bat
+```
+where `//c` is the MSYS2-safe form of Windows `/c`.
+
+## Merge / PR state-machine abuse
+
+जब Git-hosting platforms का testing करें, तो सिर्फ final dangerous command ही review न करें। **earlier validation paths** और **background rechecks** भी review करें।
+
+एक useful exploitation pattern है:
+
+1. Initial validation path एक **safe** clone/fetch flow with `--end-of-options` use करती है, ताकि malicious branch को data के रूप में accept किया जाए
+2. pull request **mergeable** बन जाती है
+3. बाद की merge या checkout path stored branch name को एक **unsafe** Git call में reuse करती है
+4. code execution तब भी हो जाती है जब बाद का step fail हो और UI **HTTP 500** return करे
+
+इसका मतलब है कि feature exploitable हो सकता है even when final merge ends in an error, और target repository **corrupted partial rebase state** में छोड़ दिया जा सकता है after the payload already ran.
+
+## Practical hunting ideas
+
+जब किसी Gogs instance या similar Git service को review करें, तो check करें:
+
+- Branch names beginning with `--`
+- Merge failures involving `git checkout '--exec=...'`
+- Pull requests stuck as mergeable even though later branch validation fails
+- Repositories left in partial rebase / broken Git state after failed merges
+- Unexpected committed helper files on Windows payload paths (for example dotfiles plus `.bat` launchers)
+- Suspicious API tokens created shortly before failed PR merges
+
+Example log artifact:
+```text
+merge: git checkout '--exec=<...>': exit status 128 - error: unknown option `exec=<...>'
+```
+## संदर्भ
+
+- [Rapid7 - Authenticated RCE via Argument Injection in Gogs (NOT FIXED)](https://www.rapid7.com/blog/post/ve-authenticated-rce-via-argument-injection-gogs-unfixed)
+- [Metasploit module PR for Gogs rebase argument injection](https://github.com/rapid7/metasploit-framework/pull/21515)
+- [Git rebase documentation (`--exec`)](https://git-scm.com/docs/git-rebase)
+
+{{#include ../../banners/hacktricks-training.md}}