
Rails Active Storage/libvips CVE-2026-66066 की जाँच के लिए फ़ॉरेंसिक टूलकिट और एजेंट कौशल: तैयार किए गए ब्लॉब संकेतकों, एक्सपोज़र विंडो और डेटा एक्सफ़िल्ट्रेशन का पता लगाता है।
Rails एप्लिकेशन और CVE-2026-66066 के बारे में दो प्रश्नों का उत्तर देने के लिए टूलिंग और विधि, जिसे Active Storage और libvips मनमानी फ़ाइल पढ़ने की समस्या के रूप में जाना जाता है, जिसका नाम KindaRails2Shell है:
सलाहकार GHSA-xr9x-r78c-5hrm ने भेद्यता को समझाया और पैच किए गए संस्करणों के नाम बताए, लेकिन इन प्रश्नों का मूल्यांकन करने के लिए पर्याप्त विवरण प्रकट नहीं किया। यह परियोजना उसमें सहायता करने के लिए है।
यह एक पुस्तकालय के बजाय एक दस्तावेज़ीकरण और कौशल रिपॉजिटरी है। यहाँ कुछ भी आपके एप्लिकेशन में स्थापित नहीं किया जाता है। एक एजेंट इसे पढ़ता है और आपके एप्लिकेशन के विरुद्ध काम करता है जो कहीं और चेकआउट किया गया है, और उत्पादन में चलने वाली एकमात्र स्क्रिप्ट एक एकल स्व-निहित फ़ाइल है जिसे आप एक कंटेनर में कॉपी करते हैं।
Rails यह तय करता है कि एक ब्लॉब को इमेज-प्रोसेस किया जा सकता है, एक content_type कॉलम पढ़कर जिसे एक सीधा अपलोड क्लाइंट को बाइट्स की कभी जाँच किए बिना सेट करने देता है। libvips फिर यह तय करता है कि फ़ाइल वास्तव में क्या है, मैजिक बाइट्स को सूंघकर। एक फ़ाइल जिसके पहले दस बाइट्स MATLAB 5.0 का दावा करते हैं, उसे libvips के MATLAB लोडर पर रूट किया जाता है, जो इसे libmatio को सौंपता है, जो एक भिन्न बाइट रेंज पर डिस्पैच करता है और MAT 7.3 पाता है, जो HDF5 है। HDF5 की External File List एक डेटासेट के बाइट्स को पथ और ऑफ़सेट द्वारा नामित किसी अन्य फ़ाइल में रहने देती है, इसलिए "इमेज" को रेंडर करने से सर्वर से एक हमलावर-चयनित फ़ाइल पढ़ी जाती है और उसकी सामग्री पिक्सेल के रूप में लौटाई जाती है। वही भ्रम, दो बार, दो परतों पर जो एक-दूसरे के फ़ील्ड नहीं देख सकतीं।
reference/the-attack.md पूरी कॉल चेन का पता लगाता है, इनबाउंड अनुरोध से लेकर उस बिंदु तक जहाँ libmatio लक्ष्य फ़ाइल खोलता है, चार भार-वहन करने वाले जंक्शनों को चिह्नित करते हुए। reference/the-investigation.md फिर समझाता है कि हमला जाँचने योग्य क्यों है: यह बढ़ती ताकत के तीन कलाकृतियाँ छोड़ता है, और उनमें से सबसे मजबूत रेंडर किया गया वेरिएंट है, जो चुराए गए बाइट्स को आपके अपने ऑब्जेक्ट स्टोर में पिक्सेल मानों के रूप में रखता है।
दो कौशल क्रम में चलते हैं। पहला एक्सपोज़र विंडो उत्पन्न करता है; दूसरा उसके बिना शुरू नहीं हो सकता।
| कौशल | प्रश्न | उत्पन्न करता है |
|---|---|---|
kr2s-was-i-vulnerable | क्या यह एप्लिकेशन कभी उजागर था? | एक एक्सपोज़र विंडो और वे तथ्य जिनकी स्वीप को आवश्यकता है |
kr2s-was-i-exploited | क्या किसी ने इसका उपयोग किया, और उन्हें क्या मिला? | एक लिखित फोरेंसिक विश्लेषण |
दोनों एक एजेंट के लिए लिखे गए हैं, और दोनों उस व्यक्ति द्वारा पढ़े जा सकते हैं जो काम हाथ से करना चाहता है। प्रत्येक में एक SKILL.md प्रवेश बिंदु और एक references/guide.md है जो वास्तविक प्रक्रिया, उसके eval जाँच और उसके विफलता मोड रखता है।
यदि आप पैच किए गए हैं और जानना चाहते हैं कि आपको परवाह करनी चाहिए या नहीं, तो पहला चलाएँ। इसका डिलीवरेबल हाँ या नहीं के बजाय एक विंडो है, क्योंकि इसे पढ़ने वाले अधिकांश लोगों के लिए वर्तमान-काल का उत्तर "नहीं, हमने पैच कर दिया" है, और उपयोगी उत्तर यह है कि एक जाँच को किन वर्षों को कवर करना होगा।
इस रिपॉजिटरी को क्लोन करें और क्लोन रखें। दोनों कौशल reference/ में संदर्भ दस्तावेज़ साझा करते हैं, और उनके गाइड उन्हें रिपॉजिटरी-सापेक्ष पथ द्वारा पढ़ते हैं, इसलिए अकेले कहीं कॉपी की गई एक कौशल निर्देशिका डेड-एंड हो जाएगी।
सबसे आसान तरीका यह है कि अपने एजेंट को क्लोन के अंदर शुरू करें और उसे बताएँ कि आपका एप्लिकेशन कहाँ है। AGENTS.md वहाँ से इसे उन्मुख करता है, जिसमें वह हिस्सा भी शामिल है जिसे लोग गलत समझते हैं, जो यह है कि यह रिपॉजिटरी टूल है और विषय नहीं।
अन्यथा, फ़ाइल की ओर इंगित करें और ऐसा कहें, जो किसी भी एजेंट में काम करता है जो स्थानीय फ़ाइलें पढ़ सकता है:
Read /path/to/rails-forensics-CVE-2026-66066/skills/kr2s-was-i-vulnerable/SKILL.md
and follow it. My application is at /path/to/my-app.
Claude Code में आप उन्हें इस तरह इंस्टॉल कर सकते हैं कि वे स्वयं ट्रिगर हों, कॉपी करने के बजाय सिमलिंक बनाकर, जिससे वे क्लोन की ओर इंगित रहते हैं:
ln -s "$PWD/skills/kr2s-was-i-vulnerable" ~/.claude/skills/
ln -s "$PWD/skills/kr2s-was-i-exploited" ~/.claude/skills/
किसी एक एप्लिकेशन तक सीमित रखना चाहें तो ~/.claude/skills/ के बजाय प्रोजेक्ट के अंदर .claude/skills/ का उपयोग करें।
किसी भी तरह से, एजेंट को बताएं कि आपका एप्लिकेशन कहाँ है। स्किल्स में स्पष्ट रूप से कहा गया है कि यह रिपॉज़िटरी और जाँच के अधीन एप्लिकेशन दो अलग-अलग रूट हैं, और वे दूसरे को पढ़ सकते हैं लेकिन उसमें कभी लिख नहीं सकते।
AGENTS.md orientation for an agent started in this directory
reference/the-attack.md how the vulnerability works, traced call by call
reference/the-investigation.md why an investigation is possible, and where it runs out
skills/ the two skills
RUNBOOK.md operator's guide to the scanner: flags, verdicts, resuming
lib/crafted_mat_file.rb the detector
bin/ the scanner and three analysis utilities
test/ the test suite
दो संदर्भ दस्तावेज़ इस रिपॉज़िटरी का सरल-अंग्रेज़ी वाला आधा हिस्सा हैं और वे अपने आप में पूर्ण हैं। यदि आप समस्या को समझना चाहते हैं तो उन्हें पढ़ें, यदि आप किसी विशेष एप्लिकेशन के बारे में उत्तर चाहते हैं तो स्किल्स चलाएँ।
bin/kr2s_scan_active_storage_blobs.rb rake build द्वारा lib/ से उत्पन्न होता है
और कमिट किया जाता है, इसलिए इसे प्रोडक्शन में चलाने के लिए किसी बिल्ड चरण और किसी दूसरी
फ़ाइल की आवश्यकता नहीं होती।
lib/crafted_mat_file.rb उस क्राफ़्टेड फ़ाइल की पहचान करता है जिसकी इस हमले के लिए आवश्यकता होती है। यह
किसी ऑब्जेक्ट के पहले 128 बाइट्स में से दो हेडर फ़ील्ड पढ़ता है और इसके अलावा
कुछ नहीं चाहता, यही कारण है कि स्कैन किसी उम्मीदवार को डाउनलोड करने के बजाय रेंज्ड रीड से
वर्गीकृत कर सकता है। reference/the-attack.md बताता है कि कौन-से फ़ील्ड और
क्यों कोई वैध लेखक उस संयोजन को उत्पन्न नहीं करता।
यह रिपॉज़िटरी जानबूझकर ऐसा कोई कोड नहीं देती जो क्राफ़्टेड फ़ाइलें बनाता हो, और न ही कोई
क्राफ़्टेड फ़ाइल। डिटेक्टर के परीक्षण जिन 128 बाइट्स हेडर की उन्हें आवश्यकता होती है उन्हें शुद्ध Ruby में संश्लेषित करते हैं, जो कि डिटेक्टर पढ़ता है वह सब है। reference/the-attack.md
संरचना का पूरी तरह वर्णन करता है, इसलिए हमले को समझने का प्रयास करने वाले पाठक से कुछ भी
छिपाया नहीं जा रहा है। जो छिपाया जा रहा है वह एक कार्यशील जनरेटर है जिसे
एक आर्ग्युमेंट बदलकर किसी मनमाने पथ पर पुनः लक्षित किया जा सकता है।
कवर किया गया: Active Storage, :vips वेरिएंट
प्रोसेसर का उपयोग करने वाले एप्लिकेशनों पर, जहाँ वेरिएंट रिकॉर्ड ट्रैक किए गए थे।
कवर नहीं किया गया: कोई भी अन्य स्थान जहाँ कोई एप्लिकेशन उपयोगकर्ता-प्रदत्त फ़ाइलें
libvips को सौंपता है। अन्य अपलोड लाइब्रेरी, सीधे ऑब्जेक्ट-स्टोर क्लाइंट, और विशिष्ट
अवतार या लोगो सिस्टम — प्रत्येक के लिए अपना अलग सर्वेक्षण आवश्यक है, और यहाँ का स्कैनर
ऐसा नहीं करेगा। kr2s-was-i-vulnerable आपको उन्हें सूचीबद्ध करवाएगा ताकि उनका नाम लिया जाए
बजाय इसके कि वे किसी निष्कर्ष से चुपचाप छूट जाएँ।
इस टूलिंग से प्राप्त स्वच्छ परिणाम प्रबल प्रमाण है, प्रमाण नहीं। दोनों स्किल्स यह बार-बार और विशेष रूप से कहते हैं, और विश्लेषण टेम्पलेट में एक सीमाएँ अनुभाग है जो वैकल्पिक नहीं है।
यह 37signals में एक वास्तविक जाँच से निकला है, जिसमें उस पूरी अवधि में एक बड़े प्रोडक्शन Active Storage स्टोर का सर्वेक्षण किया गया जितने समय तक यह भेद्यता विद्यमान थी। टूलिंग ने उन सुरक्षा शोधकर्ताओं द्वारा अपलोड की गई परीक्षण फ़ाइलों की सही पहचान की जिन्होंने इस दोष की रिपोर्ट की थी, जो कि उपलब्ध एकमात्र बाह्य प्रमाण है कि डिटेक्टर वह पाता है जो उसे पाना चाहिए।
kr2s-was-i-exploited/references/analysis-template.md में दिया गया विस्तृत विश्लेषण
काल्पनिक है। यह वास्तविक विश्लेषण पर आधारित है, लेकिन इसमें प्रत्येक पहचानकर्ता, पता और
तिथि मनगढ़ंत है।