rafabd1/vectorfreedlibrsvg के VectorFreed use-after-free RCE चेन (CVE-2026-96889) का दस्तावेज़ीकरण करता है, जिसमें librsvg, Next.js और Satori के लिए एक SVG जनरेटर PoC और उपचार मार्गदर्शन शामिल है।
यह दस्तावेज़ "VectorFreed" प्रस्तुत करता है, एक भेद्यता श्रृंखला जो librsvg में मेरे (@rafabd1) द्वारा खोजे गए use-after-free से शुरू होती है (CVE-2026-96889)। एक Node.js/Sharp/libvips बिल्ड में, इस बग ने कमांड निष्पादन को जन्म दिया। यह बग, अब तक अनुप्रयोगों में पुष्ट किए गए पथ, और अब उपलब्ध समाधानों को कवर करता है।
एक SVG XInclude के माध्यम से दूसरे SVG को शामिल कर सकता है। भेद्य पथ में, librsvg एक शामिल दस्तावेज़ को पार्स करना शुरू करता है जबकि libxml2 अभी भी बाहरी दस्तावेज़ में एक एंटिटी का विस्तार कर रहा होता है। यदि शामिल SVG उसी नाम की एक एंटिटी घोषित करता है, तो librsvg पहली एंटिटी को प्रतिस्थापित और मुक्त कर देता है। libxml2 अभी भी उसका एक पॉइंटर रखता है।
जब शामिल पार्स समाप्त होता है, तो libxml2 उस पुराने पॉइंटर के साथ आगे बढ़ता है। तब तक वह मेमोरी पहले से ही किसी और चीज़ की हो सकती है, इसलिए बाद के लेखन इसे दूषित कर सकते हैं। क्रैश एक परिणाम है। अन्य मामलों में, इसने कमांड निष्पादन को भी जन्म दिया।
हमलावर को librsvg तक पहुँचने के लिए तैयार किए गए SVG मार्कअप की आवश्यकता होती है। यह तब हो सकता है जब कोई अनुप्रयोग SVG फ़ाइल स्वीकार करता है, लेकिन यह तब भी हो सकता है जब अनुप्रयोग उपयोगकर्ता इनपुट से SVG बनाता है। केवल निर्भरता ट्री में कहीं librsvg का उपयोग करना एक शोषणीय पथ स्थापित नहीं करता; छवि रेंडर होने पर इनपुट को प्रभावित बिल्ड तक पहुँचना चाहिए।
हमने जिस Next.js रूट का परीक्षण किया, उसने SVG अपलोड के बजाय टेक्स्ट स्वीकार किया। इसने उस टेक्स्ट को ImageResponse के Node.js संस्करण के लिए एक इनलाइन SVG के अंदर रखा। Satori में एक अलग एस्केपिंग बग ने टेक्स्ट को जनरेट किए गए SVG मार्कअप को बदलने की अनुमति दी। फिर Sharp/libvips ने उस SVG को librsvg को पास कर दिया। Vercel ने Next.js पथ को CVE-2026-94545 के रूप में ट्रैक किया। ImageResponse का Edge संस्करण इस पथ से प्रभावित नहीं है। यहाँ एक संक्षिप्त Next.js प्रतिकृति है।
इस शोध के दौरान, मैंने कई डाउनस्ट्रीम उत्पादों में प्रभावित इनपुट पथों की पहचान की और उनमें से कई में कमांड निष्पादन की पुष्टि की, जिसमें ऊपर वर्णित Next.js मामला भी शामिल है। वह इनपुट librsvg तक कैसे पहुँचता है, यह उत्पाद-दर-उत्पाद भिन्न होता है। यही कारण है कि एक अपस्ट्रीम इमेज पार्सर बग ऐसी जगहों पर प्रकट हो सकता है जो पहली नज़र में संबंधित नहीं लगतीं; हालिया libheif मामला एक और उदाहरण है। इसका मतलब यह नहीं है कि librsvg का उपयोग करने वाला हर उत्पाद दूरस्थ रूप से शोषणीय है।
ImageResponse पथ पर हमलावर-नियंत्रित मानों को SVG सामग्री, विशेषताओं, या शैलियों में डालता है। 16.3.6 में अपग्रेड करें।यदि आप Sharp के प्रीबिल्ट बाइनरीज़ का उपयोग करते हैं, तो जाँचें कि आपके ऐप ने कौन सा @img/sharp-libvips-* पैकेज इंस्टॉल किया है। यह libvips और उसकी निर्भरताओं को बंडल करता है, जिसमें librsvg भी शामिल है। librsvg की सिस्टम प्रति को अपडेट करने से आपका ऐप पुरानी प्रति का उपयोग करता रह सकता है।
UAF PoC में कई इनपुट पथों के लिए एक SVG जनरेटर शामिल है और इसका उपयोग श्रृंखला की शुरुआत में use-after-free की जाँच के लिए किया जा सकता है।
अब तक, मुझे कोई सार्वजनिक एक्सप्लॉइट नहीं मिला है जो इस श्रृंखला को तैयार किए गए SVG से कमांड निष्पादन तक पूरी तरह ले जाता हो। हालाँकि, बग और पैच पहले से ही सार्वजनिक हैं, और वर्तमान AI टूल्स के साथ उनसे पूरी श्रृंखला तक वापस काम करना काफी आसान है। यह देखते हुए, एक्सप्लॉइट को ऐसे मानें जैसे वह पहले से ही सार्वजनिक हो और जितनी जल्दी हो सके प्रभावित निर्भरताओं को अपडेट करें या इनपुट पथ को कम करें।
[!WARNING] इस श्रृंखला के लिए कोई सार्वभौमिक RCE PoC नहीं है; पेलोड को प्रत्येक लक्ष्य के लिए समायोजित करने की आवश्यकता होती है। अब तक देखे गए अधिकांश सार्वजनिक "PoC" वास्तविक RCE श्रृंखला को पुन: उत्पन्न नहीं करते हैं। कुछ दावा किए गए निष्पादन के लिए SVG
<foreignObject>पर निर्भर करते हैं, जो यहाँ वर्णित एक्सप्लॉइट पथ नहीं है।
प्रारंभिक सत्यापन के लिए, UAF PoC अधिक व्यावहारिक है। मैं Next.js मामले (CVE-2026-94545) के लिए एक RCE PoC एक अलग रिपॉजिटरी में प्रकाशित करने की योजना बना रहा हूँ। मैं आने वाले हफ्तों में तकनीकी राइट-अप भी प्रकाशित करूँगा, जिसमें UAF से कमांड निष्पादन तक के चरण और इस श्रृंखला में पिछले महीने के शोध को कवर करने वाला पोस्ट-मॉर्टम शामिल होगा।