InvoiceShelf ने CVE-2026-55610 के लिए एक पैच जारी किया है, जो एक गंभीर खामी है जिससे एक कंपनी का कोई भी ओनर दूसरी कंपनी के यूजर अकाउंट्स को हाईजैक कर सकता था। CVSS स्केल पर 8.7 रेटिंग वाली यह भेद्यता (vulnerability), ऐप के Laravel कोड में 'tenant-scope check' की कमी के कारण आई थी।

यह खामी कैसे काम करती थी

InvoiceShelf Laravel पर बना एक SaaS टूल है जो कंपनियों को एक सिंगल डैशबोर्ड से यूजर्स, इनवॉइस और सेटिंग्स मैनेज करने की सुविधा देता है। यह प्लेटफॉर्म टेनेंट (tenant) की पहचान करने के लिए एक कस्टम हेडर को पढ़ता है। जब कोई ओनर यूजर रिकॉर्ड का अनुरोध करता है, तो कोड केवल यह जांचता है, "क्या अनुरोध करने वाला अपनी कंपनी का ओनर है?"

यह कभी भी यह सत्यापित (verify) नहीं करता कि लक्षित यूजर (target user) उसी टेनेंट से संबंधित है या नहीं। Laravel का 'implicit route-model binding', यूजर ID को ग्लोबल यूजर्स टेबल की एक रो (row) से जोड़ देता है, और ऑथोराइजेशन पॉलिसी केवल अनुरोध करने वाले की भूमिका (role) के आधार पर अनुरोध को मंजूरी दे देती है।

इसलिए, एक हमलावर:

  • अनुरोध URL में कोई भी न्यूमेरिक यूजर ID दे सकता था।
  • ईमेल सहित पूरा यूजर रिकॉर्ड प्राप्त कर सकता था।
  • एक अपडेट जारी कर सकता था जो पीड़ित के ईमेल, पासवर्ड को बदल दे और यहाँ तक कि अकाउंट को सुपर-एडमिन के रूप में हमलावर की कंपनी को फिर से सौंप दे।

व्यवहार में, एक दुर्भावनापूर्ण ओनर ने कंपनी-मैनेजमेंट टूल को यूनिवर्सल अकाउंट-टेकओवर हथियार में बदल दिया। इसके लिए "Owner" से अधिक किसी अन्य विशेषाधिकार (privilege) की आवश्यकता नहीं थी।

कौन प्रभावित है

2.4.1 से पहले का वर्जन चलाने वाला प्रत्येक InvoiceShelf ग्राहक इससे प्रभावित था। क्योंकि यह खामी कोर रिक्वेस्ट-हैंडलिंग पाथ (core request-handling path) में मौजूद थी, इसलिए आकार या सुरक्षा स्थिति की परवाह किए बिना, किसी भी टेनेंट को किसी अन्य टेनेंट के ओनर द्वारा निशाना बनाया जा सकता था। इसके प्रभाव में गोपनीयता की हानि (ईमेल पते) और अखंडता (integrity) की हानि (अनधिकृत पासवर्ड परिवर्तन, सुपर-एडमिन में अपग्रेड) शामिल है।

पैच

डेवलपर्स ने वर्जन 2.4.1 जारी किया, जिसमें यूजर रिकॉर्ड पर किसी भी रीड या राइट ऑपरेशन से पहले एक स्पष्ट टेनेंट चेक (explicit tenant check) जोड़ा गया है। यह फिक्स क्वेरी को सक्रिय कंपनी आइडेंटिफायर (active company identifier) तक सीमित कर देता है, जिससे Laravel केवल उन्हीं रो (rows) को वापस करने के लिए मजबूर होता है जो अनुरोध करने वाले के टेनेंट से संबंधित हैं।

डेवलपर्स को क्या सीखना चाहिए

  • मल्टी-टेनेंट एप्लिकेशन में कभी भी ग्लोबल प्राइमरी कीज़ (global primary keys) पर भरोसा न करें।
  • हर डेटाबेस लुकअप पर टेनेंट फ़िल्टर लागू करें, न कि केवल डिलीट या क्रिएट एक्शन पर।
  • ऑथोराइजेशन पॉलिसीज़ से एक्टर की भूमिका और लक्षित ऑब्जेक्ट की टेनेंसी (tenancy), दोनों को सत्यापित करवाएं।
  • रूट-मॉडल बाइंडिंग जैसी इम्प्लिसिट फ्रेमवर्क सुविधाओं को ऐसी सुविधा के रूप में मानें जो सुरक्षा अंतराल (security gaps) को छिपा सकती हैं, जब तक कि आप स्पष्ट स्कोपिंग (explicit scoping) न जोड़ दें।

भविष्य की ओर देखते हुए

यह घटना किसी भी ऐसे SaaS के लिए व्यापक जोखिम को दर्शाती है जो टेबल्स साझा करता है। सुरक्षा ऑडिट को उन सभी एंडपॉइंट्स की समीक्षा करनी चाहिए जो आइडेंटिफायर स्वीकार करते हैं और यह पुष्टि करनी चाहिए कि टेनेंट स्कोपिंग (tenant scoping) को समान रूप से लागू किया गया है।

निष्कर्ष: एक भी छूटा हुआ टेनेंट चेक एक विशेषाधिकार प्राप्त यूजर रोल को यूनिवर्सल बैकडोर में बदल सकता है। उचित स्कोपिंग वैकल्पिक नहीं है; यह किसी भी मल्टी-टेनेंट सिस्टम में डेटा आइसोलेशन (data isolation) की नींव है।