rails-activestorage-vips-audit

एक Agent Skill जो Ruby on Rails रिपॉज़िटरीज़ का CVE-2026-66066 (KindaRails2Shell) के प्रति एक्सपोज़र के लिए ऑडिट करता है — यह Active Storage libvips वेरिएंट-प्रोसेसिंग वल्नरेबिलिटी है जो मनमानी फ़ाइल पढ़ने और, Rails एप्लिकेशन में, रिमोट कोड एक्ज़िक्यूशन की अनुमति देती है।

यह स्किल एक कॉन्फ़िगरेशन ऑडिटर और रेमेडिएशन सहायता है। इसमें कोई एक्सप्लॉइट कोड नहीं है और यह अटैक चेन का वर्णन नहीं करता।

वल्नरेबिलिटी

CVE	CVE-2026-66066
गंभीरता	Critical, CVSS 9.5
पैकेज	activestorage (RubyGems)
प्रभावित	< 7.2.3.2, >= 8.0 < 8.0.5.1, >= 8.1 < 8.1.3.1
पैच्ड	7.2.3.2, 8.0.5.1, 8.1.3.1
एडवाइज़री	GHSA-xr9x-r78c-5hrm

libvips ऑपरेशन्स के माध्यम से फ़ॉर्मेट पढ़ता और लिखता है, जिनमें से कुछ को यह unfuzzed के रूप में चिह्नित करता है — यानी अविश्वसनीय कंटेंट के लिए असुरक्षित। Active Storage ने उन्हें अक्षम नहीं किया, इसलिए एक हमलावर जो एक तैयार की गई फ़ाइल अपलोड कर सकता है, उन तक पहुँच सकता है।

एक एप्लिकेशन केवल तभी एक्सपोज़्ड होता है जब चारों शर्तें पूरी हों:

1. activestorage एक प्रभावित वर्ज़न रेंज में है
2. Active Storage उपयोग में है
3. config.active_storage.variant_processor का मान :vips है
4. एप्लिकेशन अविश्वसनीय उपयोगकर्ताओं से अपलोड स्वीकार करता है

शर्त 3 निर्णायक है। प्रभावित रेंज < 7.2.3.2 में हर Rails 6.x रिलीज़ शामिल है, लेकिन 6.x डिफ़ॉल्ट रूप से :mini_magick का उपयोग करता है, इसलिए 6.x केवल गैर-डिफ़ॉल्ट कॉन्फ़िगरेशन के अंतर्गत एक्सपोज़्ड है, और 6.0 से पहले की रिलीज़ में variant_processor सेटिंग बिल्कुल नहीं है। Rails 7.0 और बाद के वर्ज़न config.load_defaults 7.0 के माध्यम से डिफ़ॉल्ट रूप से :vips का उपयोग करते हैं, यही कारण है कि सामान्य कॉन्फ़िगरेशन एक्सपोज़्ड है। Rails 8.1 :disabled भी स्वीकार करता है, जिससे शर्त 3 असत्य हो जाती है।

इंस्टॉलेशन

Claude Code प्लगइन के रूप में, इस रिपॉज़िटरी में बंडल किए गए मार्केटप्लेस के माध्यम से:

/plugin marketplace add paveg/rails-activestorage-vips-audit
/plugin install rails-activestorage-vips-audit@paveg-skills

skills CLI के साथ, जो उसी skill को Claude Code, Codex, Cursor, Copilot CLI और अन्य agents में इंस्टॉल करता है:

npx skills add paveg/rails-activestorage-vips-audit

या मैन्युअल रूप से:

git clone https://github.com/paveg/rails-activestorage-vips-audit.git
cp -r rails-activestorage-vips-audit/skills/rails-activestorage-vips-audit ~/.claude/skills/

~/.agents/skills/ Codex, Copilot CLI, और Gemini CLI के लिए एक क्रॉस-रनटाइम स्थान के रूप में काम करता है। स्किल में कुछ भी इस बात पर निर्भर नहीं करता कि यह कहाँ इंस्टॉल है — कोई पूर्ण पथ नहीं हैं, और collect-evidence.sh सब कुछ उस एप्लिकेशन रूट के सापेक्ष हल करता है जिसकी ओर इसे इंगित किया जाता है।

उपयोग

स्किल के दो मोड हैं, और दोनों कई एप्लिकेशन पथ स्वीकार करते हैं।

report <app>...   # read-only audit, one verdict per application
fix <app>...      # applies remediation on a branch; never commits or pushes unprompted

प्लगइन के रूप में इंस्टॉल होने पर, प्रत्येक मोड एक कमांड भी है, इसलिए मोड को आर्ग्युमेंट के रूप में टाइप करने की आवश्यकता नहीं है:

/rails-activestorage-vips-audit:report path/to/app another/app
/rails-activestorage-vips-audit:fix path/to/app

ये कमांड्स आपके लिए प्रवेश बिंदु हैं, एजेंट के लिए नहीं: इन्हें इस तरह चिह्नित किया गया है कि Claude इन्हें स्वयं कभी नहीं चलाता। जब कोई अनुरोध इससे मेल खाता है तो Claude अभी भी स्किल को स्वयं आमंत्रित करता है, यही कारण है कि fix किसी मनुष्य के अनुरोध के बिना शुरू नहीं हो सकता।

report डिफ़ॉल्ट है। fix के लिए पहले उसी एप्लिकेशन के लिए report का निर्णय आवश्यक है, क्योंकि सही उपचार इसी पर निर्भर करता है — Rails 6.x, 7.0.x, और 7.1.x के लिए उसी श्रृंखला का कोई पैच नहीं है, इसलिए वहाँ fix अंतरिम शमन लागू करता है और यह बताता है कि फ्रेमवर्क अपग्रेड आवश्यक है, बजाय इसे स्वयं करने का प्रयास करने के।

साक्ष्य संग्रह को अलग से भी चलाया जा सकता है:

skills/rails-activestorage-vips-audit/scripts/collect-evidence.sh path/to/app another/app

स्क्रिप्ट तथ्यों को एकत्र करती है और जानबूझकर इसमें कोई निर्णय लॉजिक नहीं होता। किसी अविभेदित मोनोरेपो रूट के बजाय किसी एप्लिकेशन रूट को पास करें। मोनोरेपो के लिए, प्रत्येक डिप्लॉय करने योग्य Rails डायरेक्टरी को उसके अपने Gemfile.lock और config/application.rb के साथ एक अलग आर्ग्युमेंट के रूप में पास करें। कलेक्टर उन नेस्टेड एप्लिकेशन रूट्स को पैरेंट के एविडेंस स्ट्रीम से बाहर रखता है, जबकि नेस्टेड लॉकफ़ाइल रूट्स को बनाए रखता है जो माउंटेड इंजन या पाथ डिपेंडेंसी हो सकते हैं।

यह आपको क्या नहीं बताएगा

• रनटाइम libvips संस्करण। यह किसी रिपॉज़िटरी से निर्णायक रूप से जाना नहीं जा सकता, और यह मायने रखता है: libvips 8.13 से नीचे असुरक्षित ऑपरेशन्स को बिल्कुल भी अक्षम नहीं किया जा सकता। किसी अनपैच्ड एप्लिकेशन पर इसका मतलब है कि कोई भी शमन काम नहीं कर सकता; किसी पैच्ड एप्लिकेशन पर इसका मतलब है कि Active Storage बिना सुरक्षा के चलने के बजाय बूट के दौरान त्रुटि उठाता है, इसलिए एक अनचेक्ड अपग्रेड एक साइलेंट छेद छोड़ने के बजाय डिप्लॉय को विफल कर देता है। जहाँ एप्लिकेशन चलता है वहाँ vips --version से सत्यापित करें। रिपोर्ट्स इसे एक्सपोज़र निर्णय को सशर्त बनाने के बजाय रनटाइम तैयारी और उपचार के अंतर्गत रखती हैं।
• क्या कोई शमन सक्रिय है। किसी Dockerfile में VIPS_BLOCK_UNTRUSTED यह साबित नहीं करता कि डिप्लॉय किया गया वातावरण इसे सेट करता है। स्किल ऐसे निष्कर्षों को "अंतरिम शमन मौजूद है, अपग्रेड अभी भी आवश्यक है" तक सीमित रखता है और कभी भी किसी एक को स्वच्छ निर्णय उत्पन्न नहीं करने देता।

उपचार सारांश

अपनी श्रृंखला से मेल खाते हुए 7.2.3.2, 8.0.5.1, या 8.1.3.1 में अपग्रेड करें। पहले रनटाइम libvips >= 8.13 और ruby-vips >= 2.2.1 की पुष्टि करें: जहाँ ruby-vips इंस्टॉल है, वहाँ पैच्ड Active Storage बूट के दौरान त्रुटि उठाता है जब तक दोनों पूरे न हों, और यह जाँच :mini_magick एप्लिकेशन्स पर भी लागू होती है।

अंतरिम शमन, जिनमें से कोई भी अपग्रेड का विकल्प नहीं है:

• VIPS_BLOCK_UNTRUSTED एनवायरनमेंट वेरिएबल सेट करें (libvips >= 8.13; किसी gem परिवर्तन की आवश्यकता नहीं)
• किसी इनिशियलाइज़र से Vips.block_untrusted(true) कॉल करें (ruby-vips >= 2.2.1, साथ ही libvips >= 8.13)

ruby-vips < 2.2.1 पर इनिशियलाइज़र मार्ग ऐसी विधि को कॉल करता है जो अभी मौजूद नहीं है, इसलिए पहले gem को अपग्रेड करें या एनवायरनमेंट-वेरिएबल मार्ग अपनाएँ, जो इस पर निर्भर नहीं करता।

यदि कोई एप्लिकेशन उजागर हुआ था, तो एप्लिकेशन प्रोसेस द्वारा पढ़े जा सकने वाले प्रत्येक सीक्रेट को compromised मानें और उसे रोटेट करें: secret_key_base, मास्टर की, Active Storage सेवा क्रेडेंशियल्स, डेटाबेस क्रेडेंशियल्स, और तृतीय-पक्ष टोकन।

यहाँ WAF कोई शमन नहीं है। क्या यह पेलोड देख सकता है यह स्टोरेज सेवा और अपलोड विधि पर निर्भर करता है, इसलिए इसकी प्रभावशीलता कॉन्फ़िगरेशन पर इतनी निर्भर है कि उस पर भरोसा नहीं किया जा सकता।

अस्वीकरण