0xmrma/cve-2026-32722ब्लूमबर्ग मेम्रे में अनएस्केप्ड कमांड-लाइन मेटाडेटा के माध्यम से संग्रहीत XSS
ब्लूमबर्ग Memray की अनएस्केप्ड कमांड-लाइन मेटाडेटा के माध्यम से स्टोर्ड XSS
मैंने यह समस्या Memray की समीक्षा करते समय पाई, जो Bloomberg का Python मेमोरी प्रोफाइलर है, और मन में एक सरल प्रश्न था:
क्या आक्रमणकारी-नियंत्रित रनटाइम मेटाडेटा असुरक्षित रूप से ब्राउज़र-रेंडर्ड रिपोर्ट आउटपुट में प्रवेश कर सकता है?
इस मामले में, उत्तर हाँ था।
बग Memray के HTML रिपोर्ट जनरेशन पथ में था, जहाँ कमांड-लाइन मेटाडेटा को बिना एस्केपिंग के ब्राउज़र में खोली गई रिपोर्ट में रेंडर किया गया था। इसने एक ऑपरेशनल फ़ील्ड को एक्ज़ीक्यूटेबल HTML सिंक में बदल दिया और अंततः CVE-2026-32722 बन गया।
प्रोजेक्ट: GitHub पर Memray
एडवाइज़री: GHSA-r5pr-887v-m2w9 /CVE-2026-32722
attacker-controlled argv → metadata.command_line → HTML template sink without escaping → raw markup in generated report → browser-side JavaScript execution
Memray एक Python मेमोरी प्रोफाइलर है।
यह Python प्रोसेस को इंस्ट्रूमेंट करता है, आवंटन व्यवहार रिकॉर्ड करता है, और रिपोर्ट तैयार करता है जो डेवलपर्स को समझने में मदद करती हैं:
उनमें से कुछ रिपोर्ट HTML के रूप में उत्सर्जित होती हैं और ब्राउज़र में खोली जाती हैं।
यह रिपोर्ट जनरेशन को एक वास्तविक सुरक्षा सीमा बनाता है।
प्रासंगिक प्रश्न यह नहीं है कि Memray एक “लोकल टूल” है या नहीं।
प्रासंगिक प्रश्न यह है कि क्या आक्रमणकारी-नियंत्रित डेटा असुरक्षित रूप से ब्राउज़र-रेंडर्ड आउटपुट में प्रवेश कर सकता है।
इस मामले में, यह कर सकता था।
बहुत से लोग डेवलपर टूलिंग को कम आंकते हैं।
यह एक गलती है।
जब कोई टूल:
तो वह एक वेब एप्लिकेशन के समान आउटपुट-एन्कोडिंग जोखिम प्राप्त कर लेता है।
यही यहाँ की मुख्य समस्या थी।
यह बग प्रोफाइलिंग लॉजिक में नहीं था। यह आवंटन ट्रैकिंग में नहीं था। यह नेटिव मेमोरी हैंडलिंग में नहीं था।
यह एक क्लासिक ट्रस्ट-बाउंड्री विफलता थी:
वास्तविक कमज़ोरी पैदा करने के लिए यह पर्याप्त है।
मैंने Memray तक रैंडम CLI विकल्पों को फज़ करके या क्रैश का पीछा करके नहीं पहुँचा।
सबसे मज़बूत तरीका पहले उच्चतम-संभावना वाली सुरक्षा सतह की पहचान करना था।
Memray के लिए, वह HTML रिपोर्ट जनरेशन था।
क्यों?
क्योंकि HTML आउटपुट एक ब्राउज़र सिंक पेश करता है, और ब्राउज़र सिंक सामान्य मेटाडेटा बग को सुरक्षा समस्याओं में बदल देते हैं यदि:
यहाँ ठीक यही हुआ।
बग दो पंक्तियों में सिमट जाता है।
इसमें:
def get_render_environment() -> jinja2.Environment:
loader = jinja2.PackageLoader("memray.reporters")
env = jinja2.Environment(loader=loader)
Jinja एन्वायरनमेंट बिना autoescape के बनाया गया है।
फिर इसमें:
Command line: <code>{{ metadata.command_line }}</code><br>
metadata.command_line को सीधे HTML में रेंडर किया जाता है।
यही पूरी कमज़ोरी है।
क्योंकि metadata.command_line आक्रमणकारी-प्रभावित है।
Memray प्रोफाइल किए गए प्रोग्राम को चलाने के लिए उपयोग की गई कमांड लाइन रिकॉर्ड करता है।
इसका मतलब है कि argv से उपयोगकर्ता-नियंत्रित मान मेटाडेटा के रूप में संरक्षित रहते हैं और बाद में रिपोर्ट में डाले जाते हैं।
तो शोषण श्रृंखला सीधी है:
metadata.command_line में संग्रहीत करता हैयह मेटाडेटा को एक्ज़ीक्यूटेबल ब्राउज़र सामग्री में बदल देता है।
महत्वपूर्ण अंतर एक्ज़ीक्यूशन है।
कई बग विकृत HTML उत्पन्न करते हैं। अकेला यह पर्याप्त नहीं है।
यहाँ, आक्रमणकारी-नियंत्रित सामग्री केवल पेज सोर्स में दिखाई नहीं दे रही थी। इसे ब्राउज़र द्वारा सक्रिय HTML के रूप में व्याख्या किया गया और JavaScript के रूप में निष्पादित किया गया।
यही अंतर है:
तो प्रश्न यह नहीं था:
“क्या HTML रिपोर्ट में प्रकट हो सकता है?”
असली प्रश्न था:
“क्या आक्रमणकारी-नियंत्रित HTML रिपोर्ट खोले जाने पर एक्ज़ीक्यूटेबल बन सकता है?”
उत्तर हाँ था।
मेरे शुरुआती रिप्रोड्यूसर ने एक स्पष्ट स्क्रिप्ट और एक आक्रमणकारी-नियंत्रित तर्क का उपयोग किया:
cat > victim.py <<'PY'
x = [b"A" * 1024 for _ in range(1000)]
print("done")
PY
python -m memray run -o poc.bin victim.py ''
python -m memray flamegraph -o poc.html poc.bin
जनरेटेड HTML में कच्चा आक्रमणकारी-नियंत्रित मार्कअप था:
Command line: <code>~/memray/src/memray/__main__.py run -o poc.bin victim.py </code><br>
जनरेटेड रिपोर्ट को खोलने या रीफ्रेश करने से JavaScript निष्पादन ट्रिगर हुआ।
इसने मूल दावे को स्थापित किया:
बाद में, समन्वित प्रकटीकरण के दौरान, मेंटेनर ने रिप्रोड्यूसर को और सरल बना दिया:
python -m memray run -o poc.bin -c '# '
यह संस्करण बेहतर है क्योंकि यह कमज़ोर सीमा को अधिक सीधे अलग करता है:
पेलोड जानबूझकर सरल था:
यह आकर्षक पेलोड के बारे में नहीं है।
यह एक स्वच्छ निष्पादन जांच है क्योंकि:
इस प्रकार के बग के लिए, यह पर्याप्त है।
समस्या को उचित ठहराने के लिए एक रिपोर्ट प्रकार पहले से ही पर्याप्त होता।
लेकिन मैं जानना चाहता था कि यह अलग-थलग था या संरचनात्मक।
मैंने निम्नलिखित में समान व्यवहार की पुष्टि की:
--no-web के साथ जनरेट की गई flamegraph रिपोर्टयह दो कारणों से महत्वपूर्ण था।
इसने दिखाया कि कमज़ोर सिंक कई HTML आउटपुट में पुनः उपयोग किया गया था।
इसने साबित किया कि बग बाहरी CDN-होस्टेड एसेट्स पर निर्भर नहीं था।
--no-web ने अभी भी समस्या को पुनः उत्पन्न किया, जिसका मतलब है कि समस्या Memray के स्वयं के जनरेटेड HTML और टेम्पलेट हैंडलिंग में थी, रिमोट JS व्यवहार में नहीं।
इसने मामले को और मज़बूत बना दिया।
मेंटेनर की मुख्य चिंता व्यावहारिक आक्रमणकारी नियंत्रण थी।
यह उचित है।
यह उस प्रकार की समस्या नहीं है जहाँ एक अनप्रमाणित रिमोट आक्रमणकारी एक खुले HTTP एंडपॉइंट पर हमला करता है और तुरंत प्रभाव प्राप्त करता है।
शोषण की स्थिति संकीर्ण है:
इसलिए यथार्थवादी वर्गीकरण लो गंभीरता था।
यह इसे एक कमज़ोर बग नहीं बनाता।
गंभीरता शोषण की स्थितियों और संभावित प्रभाव के बारे में है। वैधता इस बारे में है कि समस्या वास्तविक है या नहीं।
यह समस्या स्पष्ट रूप से वास्तविक थी:
इसीलिए यह अभी भी एक CVE बन गया।
फिक्स न्यूनतम और सही था।
मेंटेनर ने बदला:
{{ metadata.command_line }}
को:
{{ metadata.command_line|e }}
यह सही फिक्स है क्योंकि यह कमज़ोर सिंक को सीधे संबोधित करता है।
इसके बजाय कच्चा मार्कअप उत्सर्जित करने के:
टेम्पलेट अब एस्केप्ड टेक्स्ट उत्सर्जित करता है:
<img src=x onerror=alert(1)>
यह कमांड-लाइन फ़ील्ड के सूचनात्मक मूल्य को संरक्षित करता है जबकि ब्राउज़र निष्पादन पथ को हटा देता है।
मेंटेनर ने शेष टेम्पलेट संदर्भ की भी समीक्षा की और निष्कर्ष निकाला कि:
|tojson के साथ रेंडर किए गए थेइसलिए समस्या को सही ढंग से metadata.command_line तक सीमित कर दिया गया।
वास्तविक प्रकटीकरण में आप ठीक इसी तरह की फिक्स समीक्षा चाहते हैं।
यह GitHub Security Advisories के माध्यम से निजी रूप से रिपोर्ट किया गया था।
मेंटेनर्स ने:
समस्या को सौंपा गया: CVE-2026-32722
यहाँ मुख्य सबक सरल है:
मेटाडेटा केवल इसलिए स्वचालित रूप से विश्वसनीय नहीं होता क्योंकि यह ऑपरेशनल दिखता है।
जब आक्रमणकारी-नियंत्रित सामग्री बिना एस्केपिंग के ब्राउज़र-रेंडर्ड आउटपुट में प्रवेश कर जाती है, तो इनमें से कुछ भी मायने नहीं रखता।
जिस क्षण कोई टूल HTML उत्सर्जित करता है, उसे HTML-उत्पादक एप्लिकेशन की तरह माना जाना चाहिए।
यही वास्तविक निष्कर्ष है।
यह कमज़ोरी किसी चतुर पेलोड के बारे में नहीं थी।
यह सही सीमा की पहचान करने के बारे में थी।
Memray ने आक्रमणकारी-प्रभावित कमांड-लाइन मेटाडेटा लिया और इसे बिना एस्केपिंग के जनरेटेड HTML में रेंडर कर दिया।
बाकी काम ब्राउज़र ने किया।
इसीलिए यह CVE-2026-32722 बन गया।
Memray 1.19.2 में फिक्स किया गया।
