CVE-2026-46552

NocoDB साझा-आधार लिंक वास्तविक आधार सदस्यों को आमंत्रित कर सकते हैं और साझा रद्दीकरण से बच सकते हैं

परिचय

मुझे यह समस्या NocoDB की समीक्षा करते समय मिली, जिसमें एक सरल सुरक्षा प्रश्न था:

क्या कोई सार्वजनिक साझा-आधार लिंक अस्थायी साझा पहुँच से वास्तविक प्रमाणित आधार सदस्यता की सीमा पार कर सकता है?

इस मामले में, उत्तर हाँ था।

एक साझा-आधार सत्र जो केवल xc-shared-base-id द्वारा प्रमाणित था, ACL उद्देश्यों के लिए एक सामान्य आधार दर्शक के रूप में माना गया। क्योंकि दर्शक अनुमतियाँ अभी भी सदस्य-प्रबंधन एंडपॉइंट तक पहुँचती थीं, एक उपयोगकर्ता जिसके पास केवल साझा-आधार UUID था, वह मौजूदा आधार सदस्यों की गणना कर सकता था और एक मनमाना ईमेल पते को वास्तविक सदस्य के रूप में आधार में आमंत्रित कर सकता था।

वह आमंत्रित उपयोगकर्ता तब सामान्य साइनअप प्रवाह के माध्यम से आमंत्रण को भुना सकता था, एक मानक प्रमाणित खाता प्राप्त कर सकता था, और मालिक द्वारा साझा-आधार लिंक को अक्षम करने के बाद भी आधार पहुँच बनाए रख सकता था।

वह समस्या CVE-2026-46552 बन गई।

परियोजना: NocoDB

प्रभावित संस्करण मान्य: 0.301.3

इसने NocoDB को प्रभावित किया, अपनी आधिकारिक साइट पर NocoDB को 35,000+ संगठनों द्वारा विश्वसनीय बताया गया है, जिसमें 20+ मिलियन डाउनलोड हैं। साइट Accenture, Western Digital, Hyundai, Walmart, PwC, Bosch, और American Express जैसी कंपनियों को भी सूचीबद्ध करती है।

---

आक्रमण श्रृंखला

सार्वजनिक साझा-आधार लिंक -> xc-shared-base-id को सामान्य आधार दर्शक माना जाता है -> दर्शक ACL सदस्य-प्रबंधन एंडपॉइंट तक पहुँचता है -> हमलावर आधार उपयोगकर्ताओं को सूचीबद्ध करता है और मनमाना ईमेल आमंत्रित करता है -> आमंत्रित उपयोगकर्ता सामान्य साइनअप टोकन भुनाता है -> टिकाऊ प्रमाणित आधार पहुँच साझा-लिंक रद्दीकरण से बचती है

---

NocoDB क्या करता है

NocoDB एक डेटाबेस-उन्मुख सहयोग प्लेटफॉर्म है जो ब्राउज़र-आधारित आधार पहुँच, साझाकरण, मेटाडेटा प्रबंधन और उपयोगकर्ता सदस्यता कार्यप्रवाहों को उजागर करता है।

इसका अर्थ है कि इसका साझाकरण मॉडल एक वास्तविक सुरक्षा सीमा है।

यहाँ महत्वपूर्ण प्रश्न यह नहीं था कि क्या साझा-आधार लिंक साझा सामग्री पढ़ सकते हैं।

असली प्रश्न था:

क्या कोई सार्वजनिक साझा प्राचार्य ऐसी कार्रवाइयाँ कर सकता है जो केवल प्रमाणित आधार सदस्यों की होनी चाहिए?

इस मामले में, यह कर सकता था।

---

यह सतह देखने लायक क्यों थी

सार्वजनिक साझाकरण सुविधाओं को कम आंकना आसान है।

यह एक गलती है।

एक बार जब कोई एप्लिकेशन समर्थन करता है:

• अनाम या लिंक-आधारित पहुँच,
• भूमिका मानचित्रण,
• और उसी ACL सिस्टम के पीछे सामान्य प्रमाणित प्रबंधन API,

तो मुख्य जोखिम केवल डेटा एक्सपोज़र नहीं है।

अधिक गंभीर जोखिम है सीमा पतन:

• एक निम्न-विश्वास प्राचार्य उच्च-विश्वास क्षमताओं को प्राप्त करता है,
• प्रबंधन क्रियाएँ सार्वजनिक-साझा संदर्भ से पहुँच योग्य हो जाती हैं,
• और अस्थायी पहुँच को स्थायी पहुँच में परिवर्तित किया जा सकता है।

यही यहाँ वास्तविक समस्या थी।

यह लॉगिन सत्यापन में कोई बग नहीं था। यह टोकन जालसाजी का मुद्दा नहीं था। यह पासवर्ड-रीसेट दोष नहीं था।

यह एक क्लासिक प्राधिकरण सीमा विफलता थी:

• एक साझा-लिंक प्राचार्य को सामान्य आधार भूमिकाओं में मैप किया गया था,
• उन भूमिकाओं में अभी भी सदस्य-प्रबंधन क्षमताएँ शामिल थीं,
• और वास्तविक टिकाऊ पहुँच-नियंत्रण स्थिति को सार्वजनिक-साझा संदर्भ से संशोधित किया जा सकता था।

---

वह सीमा जिस पर मैंने ध्यान केंद्रित किया

मैंने बेतरतीब ढंग से एंडपॉइंट की जाँच करके और यह उम्मीद करके संपर्क नहीं किया कि कुछ दिलचस्प प्रतिक्रिया देगा।

मजबूत मार्ग पहले सबसे उच्च-मूल्य विश्वास सीमा की पहचान करना था।

NocoDB के लिए, वह सीमा थी:

• साझा-आधार पहुँच
• और प्रमाणित आधार सदस्यता

ये दो स्थितियाँ आपस में बदलने योग्य नहीं होनी चाहिए।

एक साझा-आधार लिंक को गुंजाइशयुक्त, प्रतिसंहरणीय, लिंक-आधारित पहुँच का प्रतिनिधित्व करना चाहिए। इसे आधार के अंदर नए दीर्घकालिक प्राचार्य नहीं बनाने चाहिए।

यही वह सटीक सीमा है जो यहाँ विफल हुई।

---

मूल कारण

कमजोरी इस बात से आई कि साझा-आधार पहुँच को सामान्य ACL पथ में कैसे एकीकृत किया गया था।

साझा-आधार फ्रंटएंड प्रवाह में, xc-shared-base-id इंजेक्ट किया गया था जबकि सामान्य प्रमाणीकरण हेडर हटा दिए गए थे।

फिर, बैकएंड में, BaseViewStrategy ने xc-shared-base-id को स्वीकार किया और साझा लिंक को सीधे साझा-आधार कॉन्फ़िगरेशन से प्राप्त सामान्य roles / base_roles में अनुवादित किया।

यह पहली समस्या थी।

दूसरी समस्या यह थी कि दर्शक-स्तर की अनुमतियों में अभी भी सदस्य-प्रबंधन क्रियाएँ शामिल थीं।

ACL परत में, ProjectRoles.VIEWER तक पहुँच सकता था:

• baseUserList
• userInvite

उन अनुमतियों ने सामान्य मेटा रूट्स की रक्षा की:

• GET /api/v2/meta/bases/:baseId/users
• POST /api/v2/meta/bases/:baseId/users

इसलिए एक सार्वजनिक-साझा सत्र को प्रभावी रूप से वास्तविक आधार प्रतिभागियों के लिए अभिप्रेत सदस्यता एंडपॉइंट तक पहुँचने की अनुमति थी।

अंतिम चरण स्वयं आमंत्रण प्रवाह में था।

BaseUsersService.userInvite() ने भूमिका शक्ति की जाँच की, फिर बनाया:

• एक वास्तविक उपयोगकर्ता पंक्ति जिसमें invite_token था
• लक्ष्य आधार के लिए एक वास्तविक आधार-सदस्यता पंक्ति

और साझा-आधार सत्रों के लिए:

• invited_by null हो गया

क्योंकि अनुरोध के पीछे कोई वास्तविक प्रमाणित आमंत्रितकर्ता पहचान नहीं थी।

यह पूरी बग श्रृंखला है।

यह शोषणीय क्यों है

क्योंकि साझा-आधार लिंक का कब्जा पर्याप्त था।

हमलावर को आवश्यकता नहीं थी:

• xc-auth
• एक पूर्व-मौजूदा खाता
• चुराए गए क्रेडेंशियल
• या आधार में पूर्व सदस्यता

शोषण श्रृंखला सीधी थी:

• हमलावर एक साझा-आधार UUID प्राप्त करता है
• UUID को आधार दर्शक प्राचार्य के रूप में स्वीकार किया जाता है
• दर्शक ACL सदस्य-प्रबंधन एंडपॉइंट तक पहुँचता है
• हमलावर वर्तमान आधार सदस्यों को सूचीबद्ध करता है
• हमलावर एक मनमाना ईमेल पता आमंत्रित करता है
• आमंत्रित उपयोगकर्ता सामान्य साइनअप प्रवाह के माध्यम से टोकन भुनाता है
• नया खाता एक वास्तविक प्रमाणित आधार सदस्य बन जाता है
• मालिक बाद में साझा लिंक को अक्षम करता है
• आमंत्रित खाता अभी भी सामान्य प्रमाणित पहुँच रखता है

यह प्रतिसंहरणीय लिंक-साझाकरण को टिकाऊ सदस्यता में परिवर्तित करता है।

---

यह केवल अजीब साझाकरण व्यवहार नहीं, बल्कि एक सुरक्षा मुद्दा क्यों है

महत्वपूर्ण अंतर प्रतिसंहरण पर स्थायित्व है।

यह सिर्फ यह नहीं था:

"एक दर्शक एक दर्शक एंडपॉइंट को कॉल कर सकता है"

कमजोर प्राचार्य एक सामान्य प्रमाणित दर्शक नहीं था।

यह एक सार्वजनिक-साझा सत्र था।

यह मायने रखता है क्योंकि एप्लिकेशन ने एक क्षणिक, लिंक-गुंजाइश वाले प्राचार्य को ऐसे भरोसेमंद माना जैसे वह:

• वास्तविक सदस्यों की गणना कर सकता है,
• पहुँच-नियंत्रण स्थिति बदल सकता है,
• और आधार के अंदर नए टिकाऊ प्राचार्य बना सकता है

असली प्रश्न यह नहीं था:

"क्या कोई साझा उपयोगकर्ता साझा डेटा पढ़ सकता है?"

असली प्रश्न था:

"क्या सार्वजनिक-साझा पहुँच को स्थायी प्रमाणित पहुँच में परिवर्तित किया जा सकता है जो साझा रद्दीकरण से बचती है?"

उत्तर हाँ था।

यही कारण है कि यह एक वास्तविक प्राधिकरण कमजोरी है, न कि केवल आश्चर्यजनक एप्लिकेशन व्यवहार।

---

PoC

मैंने इसे स्थानीय रूप से मान्य किया:

• उत्पाद संस्करण: 0.301.3
• कमिट: dac49b0122c5ee655fb8f46a1b6e42dfeec1f3ad
• आधार URL: http://127.0.0.1:8080

पुनरुत्पादन सीधा था।

पहले, मैंने एक सामान्य मालिक खाते के रूप में साइन इन किया, एक नया आधार बनाया, एक तालिका बनाई, और viewer के रूप में साझा-आधार पहुँच सक्षम की:

PATCH /api/v2/meta/bases/<baseId>/shared
Content-Type: application/json

{
  "roles": "viewer"
}

इसने साझा-आधार UUID लौटाया।

फिर, बिना कोई xc-auth भेजे, मैंने केवल उपयोग किया:

xc-shared-base-id: <sharedBaseUuid>

केवल उस हेडर का उपयोग करके, मैंने कॉल किया:

GET /api/v2/meta/bases/<baseId>/users

इसने 200 OK लौटाया और वास्तविक आधार सदस्यों को उजागर किया, जिसमें ईमेल पते शामिल थे।

अभी भी केवल xc-shared-base-id का उपयोग करते हुए, मैंने कॉल किया:

POST /api/v2/meta/bases/<baseId>/users
Content-Type: application/json

{
  "email": "[email protected]",
  "roles": "viewer"
}

इसने भी 200 OK लौटाया।

स्थानीय प्रयोगशाला सत्यापन के लिए ईमेल वितरण के बिना, मैंने सीधे SQLite मेटा डेटाबेस में पुष्टि की कि: