
Gitea के hostmatcher allow-list में authenticated SSRF को प्रदर्शित करने वाली proof-of-concept lab, जहाँ http://0.0.0.1 पर भेजा गया webhook उन loopback services तक पहुँचता है जहाँ 127.0.0.1 नहीं पहुँच सकता।
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · gitea-hostmatcher-0000-ssrf
Gitea 1.27.3 - Gitea
CVE-2026-22874 ने reservedIPNets जोड़ा। CGNAT, TEST-NET, NAT64, Teredo, Azure WireServer। असली रेंज। RFC 6890 का 0.0.0.0/8 नहीं, पुराना "this network" ब्लॉक। IANA अभी भी इसे प्रकाशित करता है। Go का IsGlobalUnicast 0.0.0.1 के लिए true है। यह IsLoopback (127.0.0.0/8) नहीं है। यह IsPrivate नहीं है। डिफ़ॉल्ट external allow-list इसे सार्वजनिक इंटरनेट मानती है। Linux 0.0.0.1 को लोकल सॉकेट तक पहुँचाएगा यदि वह पता lo पर हो। एक ही लिसनर, दो नाम।
एक साइन-इन उपयोगकर्ता http://0.0.0.1 पर webhook कर सकता है और hook history से HTTP body पढ़ सकता है। उसी पोर्ट पर 127.0.0.1 अस्वीकार कर दिया जाता है।
| ID | अभी तक कोई CVE नहीं |
| CWE | CWE-918 |
| CVSS | High: 7.7 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N |
| Product | Gitea |
| Affected | v1.27.3 (146cc3e) तक; CVE-2026-22874 का अवशेष |
| Auth | साइन-इन उपयोगकर्ता जो repo webhook बना सकता है |
| License | GNU Affero GPL v3.0 |
| Lab | केवल 127.0.0.1 |
रजिस्टर करें (डिफ़ॉल्ट खुला रजिस्ट्रेशन), एक repo बनाएँ, http://0.0.0.1:<local-port>/ पर एक webhook इंगित करें, उसका परीक्षण करें, और hook history से response body पढ़ें। यह वह loopback HTTP है जिस तक उसी पोर्ट पर 127.0.0.1 नहीं पहुँच सकता: Gitea के netns में सुन रही कोई भी चीज़ जो loopback से अधिक व्यापक रूप से बाउंड हुई हो, जिसमें वे सेवाएँ भी शामिल हैं जिन्हें ऑपरेटर ने "केवल localhost" समझा क्योंकि उन्होंने 127.0.0.0/8 को ब्लॉक किया था।
यह X-Gitea-Internal-Auth सेट नहीं करता। यह अपने आप में RCE नहीं है। यह उस पते से एक पूर्ण HTTP body है जिसे allow-list अभी भी external कहती है।
v1.27.3 वह बिल्ड है जिसने 2026 GHSA लहर को बंद किया। मैं फिर भी उस टैग पर टिका रहा। जो पैच allow-list या deny-list जोड़ते हैं, वे एक उपहार हैं: आप सूची पढ़ते हैं, फिर पूछते हैं कि IANA के पास अभी भी क्या है जो सूची भूल गई। इस ट्री पर दो अवशेषों के पहले से लैब थे (keys IDOR और git-redirect SSRF)। उस पोस्ट की अवशेष तालिका में http://0.0.0.1/ पर एक webhook को मैप के रूप में सूचीबद्ध किया गया था। यह SUCCESS है।
Webhook डिलीवरी HTTP body को hook history में संग्रहीत करती है। यह git clone से बेहतर oracle है, जो ज्यादातर "क्या fetch काम कर गया" होता है। मैंने Gitea के netns में पोर्ट 8080 पर एक oracle रखा, NET_ADMIN के साथ lo पर 0.0.0.1/8 जोड़ा, और दो webhooks बनाए। पहले negative control।
पहले से दर्ज गलत मोड़: webhook create HTTP 201 को oracle मानना (history oracle है); 127.0.0.1 डिलीवरी सफल होना (वह एक अलग बग होगा - लैब के लिए आवश्यक है कि यह अस्वीकार हो); X-Gitea-Internal-Auth के साथ /api/internal पर हिट करना; एक reverse shell। नाटक। गवाह hook history में GITEA-0000-SSRF है।
cd lab
./run.sh
लक्ष्य केवल http://127.0.0.1:18131। Oracle पोर्ट 8080 पर Gitea के netns साझा करता है। run.sh lo पर 0.0.0.1/8 जोड़ता है।
create-hook name=neg-loopback status=201
negative-control 127.0.0.1 blocked
create-hook name=hit-0000 status=201
poll id=2 witness=True
SUCCESS GITEA-HOSTMATCHER-0000
reservedIPNets में 0.0.0.0/8 जोड़ें, या IsGlobalUnicast को "डायल करने के लिए सुरक्षित" मानना बंद करें। 0.0.0.1 को उसी तरह अस्वीकार किया जाना चाहिए जैसे 127.0.0.1 किया जाता है।
hostmatcher.goGNU Affero GPL v3.0। देखें LICENSE। केवल loopback लैब। कोई वारंटी नहीं।