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 मेटा डेटाबेस में पुष्टि की कि:

nc_users_v2 में गैर-शून्य invite_token के साथ आमंत्रित उपयोगकर्ता था
nc_base_users_v2 में लक्ष्य आधार के लिए एक वास्तविक सदस्यता पंक्ति थी
invited_by NULL था

फिर मैंने सामान्य साइनअप प्रवाह के माध्यम से आमंत्रण भुनाया:

POST /api/v2/auth/user/signup
Content-Type: application/json

{
  "email": "[email protected]",
  "password": "Password123.",
  "token": "<invite_token>"
}

लौटाए गए xc-auth का उपयोग करके, मैंने कॉल किया:

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

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

अंत में, मालिक के रूप में, मैंने साझा-आधार लिंक को अक्षम किया:

DELETE /api/v2/meta/bases/<baseId>/shared

उसके बाद:

xc-shared-base-id के साथ साझा-लिंक पहुँच 401 के साथ विफल हुई
सामान्य xc-auth का उपयोग करने वाला आमंत्रित खाता अभी भी 200 के साथ सफल हुआ

देखे गए परिणाम

साझा उपयोगकर्ता सूची: 200
साझा आमंत्रण: 200
साइनअप: 200
साझा अक्षम करने से पहले आमंत्रित प्रमाणित तालिका पहुँच: 200
साझा अक्षम: 200
अक्षम करने के बाद साझा-लिंक तालिका पहुँच: 401
अक्षम करने के बाद आमंत्रित प्रमाणित तालिका पहुँच: 200

इसने केंद्रीय सुरक्षा दावा स्थापित किया:

सार्वजनिक साझा पहुँच सदस्यता एंडपॉइंट तक पहुँच सकती थी
सदस्यता परिवर्तनों ने वास्तविक टिकाऊ प्रमाणित पहुँच बनाई
मूल साझा को रद्द करने से वह पहुँच नहीं हटी

पुनरुत्पादन क्यों मायने रखता है

एक सफल साझा-आधार आमंत्रण पहले से ही प्राधिकरण विफलता दिखाने के लिए पर्याप्त होता।

लेकिन पूर्ण सत्यापन श्रृंखला दो कारणों से मायने रखती थी।

पहला

इसने दिखाया कि यह केवल एंडपॉइंट एक्सपोज़र नहीं था।

सार्वजनिक-साझा सत्र ने केवल एक प्रतिबंधित API तक नहीं पहुँचा। इसने पूर्ण विशेषाधिकार-रूपांतरण श्रृंखला पूरी की:

सदस्यों की गणना करें
एक नया प्राचार्य आमंत्रित करें
आमंत्रण भुनाएँ
सामान्य प्रमाणित पहुँच प्राप्त करें

दूसरा

इसने साबित किया कि यह स्व-रद्द करने वाला नहीं था।

अधिक गंभीर प्रभाव साझा-लिंक अक्षम करने के बाद आया:

मूल लिंक मर गया
हमलावर-निर्मित खाता नहीं मरा

यही वह है जिसने अस्थायी लिंक पहुँच को टिकाऊ पहुँच स्थायित्व में बदल दिया।

प्रभाव

यह कमजोरी किसी भी व्यक्ति को जिसके पास साझा-आधार लिंक है, अनुमति देती है:

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

प्राथमिक प्रभाव गोपनीयता है, क्योंकि एक हमलावर एक सामान्य प्रमाणित खाते के माध्यम से साझा-आधार डेटा तक स्थायी पढ़ने की पहुँच बनाए रख सकता है।

इसके अलावा अखंडता प्रभाव भी है, क्योंकि एक सार्वजनिक-साझा प्राचार्य आधार में नए सदस्य जोड़कर पहुँच-नियंत्रण स्थिति को संशोधित कर सकता है।

यह सामान्य डेटा रिसाव से अधिक मजबूत परिणाम है। यह अनाम साझाकरण और प्रमाणित सदस्यता के बीच विशेषाधिकार-सीमा का उल्लंघन है।

गंभीरता और वर्गीकरण

इस मुद्दे को उचित रूप से गोपनीयता प्रभाव के साथ क्रॉस-स्कोप प्राधिकरण दोष के रूप में वर्गीकृत किया गया है।

CVSS:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N

वह वेक्टर यहाँ मुख्य व्यवहार पर फिट बैठता है:

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

सुझाया गया शमन

सुधार की दिशा सीधी है।

साझा-आधार सत्रों को सदस्य-प्रबंधन क्षमताएँ विरासत में नहीं मिलनी चाहिए।

न्यूनतम रूप से:

baseUserList और userInvite को xc-shared-base-id के माध्यम से पहुँच योग्य किसी भी अनुमति से हटाएँ
एक स्पष्ट ब्लॉक लागू करें ताकि साझा/सार्वजनिक प्राचार्य आधार सदस्यता एंडपॉइंट जैसे GET और POST /api/v2/meta/bases/:baseId/users को कॉल न कर सकें
साझा-आधार पहुँच को सीधे सामान्य आधार दर्शक अनुमतियों पर मैप करने के बजाय एक अलग प्राचार्य प्रकार के रूप में मानें
प्रतिगमन परीक्षण जोड़ें जो सत्यापित करें कि साझा-आधार अनुरोध सदस्यों की गणना नहीं कर सकते, उपयोगकर्ताओं को आमंत्रित नहीं कर सकते, और ऐसी टिकाऊ पहुँच नहीं बना सकते जो साझा रद्दीकरण से बचती है

प्रकटीकरण

यह मुद्दा स्थानीय रूप से NocoDB 0.301.3 पर कमिट dac49b0122c5ee655fb8f46a1b6e42dfeec1f3ad पर मान्य किया गया था।

रिपोर्ट ने प्रदर्शित किया:

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

मुद्दे को सौंपा गया:

CVE-2026-46552

यह बग वास्तव में क्या सिखाता है

यहाँ मुख्य सबक सरल है:

साझा-लिंक पहुँच, भरोसेमंद सदस्यता के समान नहीं है।

बहुत सारे सिस्टम परेशानी में पड़ जाते हैं जब वे इन दो विचारों को एक ही भूमिका मॉडल में समेट देते हैं।

एक साझा लिंक परिचालन रूप से एक दर्शक खाते के समान दिख सकता है, लेकिन विश्वास की धारणाएँ भिन्न हैं:

साझा लिंक को पुनर्वितरित करना आसान है
साझा लिंक प्रतिसंहरणीय होने के लिए अभिप्रेत हैं
साझा लिंक आमतौर पर निम्न-आश्वासन प्राचार्य हैं

यदि वह निम्न-आश्वासन प्राचार्य प्रबंधन क्रियाएँ कर सकता है या नए टिकाऊ पहचान बना सकता है, तो साझाकरण सीमा पहले ही टूट चुकी है।

यही वास्तविक निष्कर्ष है।

मुख्य बिंदु

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

अंतिम शब्द

यह कमजोरी पूरी तरह से प्रमाणीकरण को दरकिनार करने के बारे में नहीं थी।

यह दो विश्वास स्तरों को समेटने के बारे में था जो अलग रहने चाहिए थे।

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

यही कारण है कि यह CVE-2026-46552 बन गया।

CVE-2026-46552

सबसे लोकप्रिय

CVE-2026-46552

परिचय

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

NocoDB क्या करता है

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

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

मूल कारण

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

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

PoC

देखे गए परिणाम

पुनरुत्पादन क्यों मायने रखता है

पहला

दूसरा

प्रभाव

गंभीरता और वर्गीकरण

सुझाया गया शमन

प्रकटीकरण

यह बग वास्तव में क्या सिखाता है

मुख्य बिंदु

अंतिम शब्द