stylesmuggler-ioc-toolkit

StyleSmuggler (CVE-2026-75650) Magento Open Source और Adobe Commerce के लिए IOC टूलकिट। समझौता किए गए स्टोर, Rust इम्प्लांट, PHP वेब शेल, पर्सिस्टेंस आर्टिफैक्ट्स और ज्ञात संक्रमण संकेतकों का पता लगाएं।

Adobe का आधिकारिक पैच कवरेज — सुरक्षित मानने से पहले इसे जांचें

यदि आप पुराने, असमर्थित संस्करण पर हैं, तो Adobe आपको फिक्स नहीं भेज रहा है, भले ही आप उतने ही शोषण-योग्य हों। अपने विकल्पों के लिए docs/PATCHING.md देखें।

यह जानकारी तेज़ी से बदलती है। कार्रवाई से पहले प्राथमिक स्रोतों से क्रॉस-चेक करें: Sansec की सलाह और Adobe का बुलेटिन। चल रहे लॉग के लिए docs/TIMELINE.md देखें और यहां कुछ भी अपडेट करते समय अपने स्रोतों का हवाला दें।

StyleSmuggler वास्तव में क्या है

Magento का अपना GraphQL styles पैरामीटर और इसका डिपेंडेंसी-इंजेक्शन-आधारित फ़ाइल स्कैनिंग एकल स्पष्ट इंजेक्शन बिंदु के बजाय दो-चरणीय, फ़ाइल-आधारित विलंबित-निष्पादन प्रिमिटिव के रूप में दुरुपयोग किया जाता है:

1. पॉइज़न। हमलावर-नियंत्रित डेटा Magento-जनित लॉग या रिपोर्ट फ़ाइल (var/log/system.log एक अमान्य स्टोर कोड के माध्यम से जिसे Magento शब्दशः लॉग करता है, या var/report/<hash>) तक पहुँचता है, जो GraphQL styles[] पैरामीटर, एक उत्परिवर्तित अनुरोध हेडर, या (नीचे दूसरे, असंबंधित हमलावर के लिए) Store: हेडर के माध्यम से तस्करी किया जाता है।
2. विस्फोट। हमलावर Magento के मानक "Payment Transaction Failed Reminder" ईमेल को ट्रिगर करता है। उस ईमेल को रेंडर करना (Magento का getProcessedTemplate पथ) एक कोड पथ पर चलता है जो Magento के अपने DI/कोड स्कैनर को पॉइज़न की गई फ़ाइल को include() करने देता है, जिससे हमलावर का PHP चलता है। आपको ईमेल खोलने की आवश्यकता नहीं है — इसे सर्वर-साइड पर रेंडर करना पर्याप्त है — और यह श्रृंखला तब भी चल सकती है जब मेल डिलीवरी स्वयं विफल हो जाए।

एक आसान, बिना-टूलिंग वाला प्रारंभिक चेतावनी संकेत: आपके इनबॉक्स में कच्चे, अनरेंडर किए गए {{var ...}} टैग और .invalid में समाप्त होने वाले कस्टमर पते के साथ एक विकृत "Payment Transaction Failed Reminder" ईमेल। यह अक्सर पहला दृश्य संकेत होता है, इससे पहले कि कोई लॉग जांचे।

Sansec के अपडेट ने उसी Rust-इम्प्लांट अभियान के लिए एक दूसरा, स्वतंत्र शोषण पथ पुष्ट किया: यहां तक कि जिन स्टोर्स ने सत्र संग्रहण को Redis से हटाकर डेटाबेस पर स्थानांतरित कर दिया था, वे भी समझौता किए गए — उसी ऑपरेटर का दूसरा प्रयास सेकंडों बाद Magento के कस्टमर कस्टम विकल्प सुविधा के माध्यम से अपलोड की गई फ़ाइल का उपयोग करके सफल हुआ। सत्र संग्रहण को स्थानांतरित करना अपने आप में कोई फिक्स नहीं है।

अलग से, 7 सितंबर को, Sansec ने एक पूरी तरह से असंबंधित हमलावर पाया जो बहुत सरल पेलोड के लिए उसी StyleSmuggler प्रवेश बिंदु का उपयोग कर रहा था: Magento के अपने उत्पाद-छवि कैश में गिराया गया एक PHP वेब शेल (pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php), जिससे पहले एक टोही जांच हुई जो अपने पेलोड को Store: HTTP हेडर में छिपाती है और अपने निष्कर्षों को HTTP प्रतिक्रिया के बजाय DNS पर एक्सफिलट्रेट करती है। Sansec के अनुसार यह "रेडी-मेड टूलिंग" है — कोई स्थायी अभियान नहीं — लेकिन इसका मतलब है कि एक कमजोर होस्ट एक ही दोष के माध्यम से दो असंबंधित घुसपैठ ले जा सकता है। Rust इम्प्लांट को साफ करने का मतलब यह नहीं है कि आपका स्टोर साफ है।

Rust इम्प्लांट स्वयं भी विकसित हुआ है: मूल [kworker/u:8:0]-भेष बिल्ड (सितंबर 4) के बाद एक fc-cache-भेष बिल्ड v2.1.4 (सितंबर 6) आया जो NTP ट्रैफ़िक के रूप में प्रच्छन्न होकर बीकन करता है, और फिर उसी इम्प्लांट, उसी एजेंट ID का chronyd-भेष पुनर्नियोजन v2.1.5 (सितंबर 7) — इसका प्रमाण कि हमलावर आपके प्रकाशित किसी भी डिटेक्शन से बचने के लिए सक्रिय रूप से पुनरावृत्ति कर रहा है। Sansec कहता है कि उसने अभी तक इस इम्प्लांट के दृढ़ता/रिकॉन से परे हथियारीकरण का सबूत नहीं देखा है — उसी एक्सेस पथ पर असंबंधित हमलावर के काम कर रहे वेब शेल को देखते हुए इसे आश्वासन के रूप में न पढ़ें।

त्वरित उत्तरों के लिए docs/FAQ.md, पूर्ण तकनीकी विवरण और सोर्सिंग के लिए docs/VULNERABILITY.md, Adobe का आधिकारिक फिक्स लागू करने के लिए docs/PATCHING.md, और यदि स्कैनर कुछ पाता है तो क्या करें, इसके लिए docs/INCIDENT_RESPONSE.md देखें।

त्वरित प्रारंभ

1. पैच करें, यदि आपका संस्करण कवर है:

2. पैच स्थिति की परवाह किए बिना मौजूदा समझौते के लिए स्कैन करें — पैचिंग नए शोषण को रोकती है, यह मौजूदा बैकडोर या वेब शेल को साफ नहीं करती:

या संरचित (JSON) आउटपुट के लिए Python संस्करण, जैसे SIEM को फीड करने के लिए:

दोनों स्क्रिप्ट डिफ़ॉल्ट रूप से केवल-पठनीय हैं — वे पता लगाती हैं और रिपोर्ट करती हैं, वे प्रोसेस को नहीं मारतीं या फ़ाइलों को हटाती नहीं जब तक आप --remediate पास नहीं करते, क्योंकि समय से पहले सफाई फोरेंसिक सबूत नष्ट कर देती है (docs/INCIDENT_RESPONSE.md देखें)।

स्कैनर क्या जांचता है

• तीनों देखे गए Rust-इम्प्लांट बिल्ड में ज्ञात फाइलसिस्टम दृढ़ता कलाकृतियाँ:
  • [kworker/u:8:0] बिल्ड: ~/.local/share/.gvfsd/gvfsd-user, इसकी लॉक फ़ाइलें, /tmp/.kw_*, /tmp/.gvfsd_*
  • fc-cache बिल्ड v2.1.4 (सितंबर 6): ~/.cache/fontconfig/fc-cache, /tmp/.fc_<8hex>.lock
  • chronyd बिल्ड v2.1.5 (सितंबर 7): /tmp/.chrony-<8hex>/chronyd
• स्व-पुनर्स्थापित crontab प्रविष्टियाँ जो इम्प्लांट सीधे क्रॉन स्पूल में लिखता है — gvfsd-user बिल्ड के लिए हर 5 मिनट में, fc-cache के लिए घंटे में दो बार (13,43 * * * *)
• एक भेष बदलने वाली प्रक्रिया जिसका नाम [kworker/u:8:0], fc-cache, या chronyd है जो नहीं है root के स्वामित्व में (या, fc-cache/chronyd के लिए, वास्तविक सिस्टम बाइनरी से मेल नहीं खाती)
• डिस्क पर बाइनरी और लाइव /proc/<pid>/exe छवि दोनों की SHA-256 (दोनों भिन्न हो सकते हैं — इम्प्लांट को मेमोरी में स्वयं अपडेट करते हुए देखा गया है)
• इंजेक्टेड PHP के लिए पॉइज़न की गई लॉग/रिपोर्ट फ़ाइलें (var/log/system.log, var/report/), दो ज्ञात ट्रिगर-हेडर आकार (X-TRACE-<10hex> और X-<12hex>), और दूसरे, असंबंधित हमलावर के अभियान मार्कर (ss5_/ss6_<hex>) और DNS-कैनरी डोमेन (oast.site)
• निष्पादन-प्रमाण प्रतिक्रिया मार्कर (MG<20hex>::...::/MG<20hex>) जो पेलोड वास्तव में चलने पर लॉग में पीछे छूट जाते हैं
• pub/media के अंतर्गत PHP फ़ाइलें — जिनमें सही ढंग से कॉन्फ़िगर किए गए Magento स्टोर पर कभी भी निष्पादन योग्य PHP नहीं होनी चाहिए — दूसरे हमलावर के वेब-शेल ड्रॉप पैटर्न से मेल खाती हैं
• प्रकाशित C2/डाउनलोड होस्ट से स्थापित कनेक्शन — जिसमें fc-cache/chronyd बिल्ड का NTP-आकार बीकनिंग ntp.timesync.to:123/UDP (और फ़ॉलबैक) तक, और सार्वजनिक IP-लुकअप सेवाओं के लिए इसके सादे-HTTP कॉल शामिल हैं
• असामान्य स्थानीय Redis कनेक्शन गणना (सत्र संग्रहण पूरी तरह से 127.0.0.1:6379 पर देखा गया है, शून्य आउटबाउंड C2 ट्रैफ़िक के साथ — एक शांत नेटवर्क स्वच्छ नेटवर्क नहीं है) — और ध्यान दें कि सत्रों को अकेले Redis से हटाने से दूसरा, फ़ाइल-अपलोड-आधारित शोषण वेक्टर बंद नहीं होता

सोर्सिंग के साथ पूरी संकेतक सूची: iocs/।

पैचिंग और शमन

1. Adobe का आधिकारिक हॉटफिक्स (VULN-39341 / APSB26-146) लागू करें यदि आपका संस्करण कवर है — पहचानकर्ताओं, इसे कहाँ से प्राप्त करें, और इसे कैसे लागू करें, इसके लिए docs/PATCHING.md देखें। नीचे दिए गए अंतरिम शमन से पहले यह अब प्राथमिकता है।
2. यदि आप तुरंत पैच नहीं कर सकते, या आपका संस्करण कवर नहीं है, तो mitigations/ में अंतरिम शमन का उपयोग करें:
   • GraphQL के styles[] डिलीवरी पथ को ब्लॉक या रेट-लिमिट करें (nginx / Apache)
   • pub/media/pub/static के अंतर्गत PHP निष्पादन ब्लॉक करें (nginx / Apache) — दूसरे, असंबंधित हमलावर की वेब-शेल तकनीक के खिलाफ लक्षित रक्षा
   • POST-बॉडी निरीक्षण के लिए ModSecurity नियम और प्रतिक्रियाशील बैकस्टॉप के रूप में fail2ban
   • दायरे की सीमाओं के लिए mitigations/README.md देखें — इनमें से कोई भी कस्टमर-कस्टम-विकल्प वेक्टर या दूसरे हमलावर के Store:-हेडर डिलीवरी को बंद नहीं करता।
3. पैच/शमन स्थिति की परवाह किए बिना समझौता स्कैनर चलाएं। पैचिंग और शमन नए शोषण को रोकते हैं; दोनों में से कोई भी पहले से गिराए गए बैकडोर या वेब शेल को साफ नहीं करता।
4. यदि स्कैनर कुछ पाता है, तो होस्ट को पूरी तरह से समझौता किया हुआ मानें, न कि केवल "बैकडोर मौजूद।" साइट उपयोगकर्ता के रूप में कोड निष्पादन उस उपयोगकर्ता द्वारा पढ़ी जा सकने वाली हर चीज़ को उजागर करता है, जिसकी शुरुआत app/etc/env.php से होती है। न्यूनतम रूप से, रोकथाम के बाद: सत्र संग्रहण (Redis और/या DB) फ्लश करें, Magento crypt/key घुमाएं, सभी एडमिन पासवर्ड (और मौजूदा एडमिन सत्र अमान्य करें), डेटाबेस पासवर्ड, env.php में हर पेमेंट-प्रदाता API कुंजी और अन्य एकीकरण क्रेडेंशियल, और कोई भी SSH/डिप्लॉय कुंजी जो साइट उपयोगकर्ता पढ़ सकता है। स्टोर को साफ मानने से पहले रोग एकाउंट के लिए admin_user तालिका और गिराए गए वेबशेल के लिए pub/media/ / pub/static/ / थीम निर्देशिकाएं भी जांचें — दोनों Rust इम्प्लांट के और असंबंधित दूसरे हमलावर के। पूर्ण क्रमबद्ध चरण: docs/INCIDENT_RESPONSE.md।

रिपॉजिटरी लेआउट

अक्सर खोजे जाने वाले शब्द

CVE-2026-75650, APSB26-146, VULN-39341, Magento ज़ीरो-डे 2026, Adobe Commerce ज़ीरो-डे, StyleSmuggler पैच, Magento GraphQL भेद्यता, Magento styles पैरामीटर RCE, gvfsd-user मैलवेयर, fc-cache Magento बैकडोर, chronyd Magento मैलवेयर, Magento kworker प्रोसेस मैलवेयर, Magento Redis सत्र अपहरण, Magento बिना प्रमाणीकरण RCE सितंबर 2026, Magento 2.4.9 एक्सप्लॉइट, Adobe Commerce बैकडोर हटाना, Magento pub/media वेब शेल, eComscan StyleSmuggler, Sansec Shield StyleSmuggler।

सोर्सिंग और उत्पत्ति

इस रिपॉजिटरी में हर संकेतक एक उद्धृत, प्रकाशित स्रोत से जुड़ा है — मुख्य रूप से Sansec की सलाह (कम से कम 2026-09-07 20:50 UTC तक अपडेटेड), Adobe का APSB26-146 बुलेटिन, और लाइव संक्रमणों को संभालने वाले प्रतिक्रियाकर्ताओं के सामुदायिक घटना-प्रतिक्रिया विवरण। iocs/ में प्रत्येक फ़ाइल के नीचे उद्धरण देखें।

यहां किसी भी चीज़ को व्यापक या अंतिम न मानें। IOC (ट्रिगर हेडर, यूज़र-एजेंट स्ट्रिंग, इम्प्लांट भेष, और अब दूसरे हमलावर के अभियान मार्कर) प्रकटीकरण के दिनों के भीतर पहले ही कई बार बदल चुके हैं; उनके फिर से बदलने की उम्मीद करें। जहां भी स्क्रिप्ट आपको अनुमति देती हैं, केवल शाब्दिक स्ट्रिंग नहीं, बल्कि आकार और व्यवहार का मिलान करें।

योगदान

कोई वेरिएंट, नया हैश, नया स्रोत पता, या गलत सकारात्मक देखा? आपने जो देखा और कैसे देखा, उसके साथ एक issue या PR खोलें। कृपया:

• साझा करने से पहले अपने स्वयं के संगठन की पहचान करने वाले विवरण को संपादित करें।
• यहां एक्सप्लॉइट पेलोड या काम करने वाले ट्रिगर अनुरोध पोस्ट न करें — केवल संकेतक और डिटेक्शन लॉजिक।
• अंतर्निहित भेद्यता की रिपोर्ट Sansec और Adobe PSIRT को करें, इस रिपॉजिटरी को नहीं।

लाइसेंस

इस रिपॉजिटरी में कोड के लिए MIT (देखें LICENSE)। संकेतक डेटा रक्षात्मक उपयोग के लिए "जैसा है" प्रदान किया जाता है, जिसमें सोर्सिंग हर जगह नोट की गई है।

अस्वीकरण

यह अनौपचारिक, सामुदायिक-निर्मित रक्षात्मक टूलिंग है, Adobe या Sansec उत्पाद नहीं है, और दोनों में से किसी से संबद्ध नहीं है। यह बिना वारंटी के प्रदान किया जाता है। Adobe का आधिकारिक पैच (APSB26-146) जारी हो चुका है, लेकिन कवरेज विशिष्ट उत्पाद संस्करणों तक सीमित है — अपने इंस्टॉलेशन के कवर या ठीक होने को मानने से पहले Adobe के सुरक्षा बुलेटिन को सीधे जांचें।