CVE-2026-105752: vLLM में cache_salt छूटना

vLLM Responses में GPT-OSS टूल निरंतरता अनुरोध का cache_salt छोड़ सकती थी और बिना salt वाला prefix-cache namespace उपयोग कर सकती थी। vLLM 0.30.0 या बाद में अपडेट करें और हर निरंतरता में tenant-विशिष्ट salt बनाए रखें।^{[1], [5]}

💡 आसान भाषा में (ELI5)

कल्पना करें कि हर ग्राहक के कागज़ निजी रंग-टैग वाले लॉकर में रखे हैं। पहले अनुरोध पर सही टैग लगता है, लेकिन अगला चरण शुरू करने के लिए टूल कागज़ लौटाते समय टैग खो देता है। साझा शेल्फ़ cache hit से बता सकती है कि अनुमानित पन्ने वहाँ हैं या नहीं; वह पन्ने स्वयं नहीं देती।^[1]

इस पेज के मुख्य शब्द

Prefix caching: समान prefix के लिए मॉडल key/value blocks का पुनः उपयोग।^[6]
cache_salt: अलग salts वाले cache अलग रखने हेतु पहले block के hash में मिलाया गया मान।^[6]
Harmony continuation: Harmony प्रतिक्रिया के बाद अगला model input, tool call के बाद भी।^[1]
Membership oracle: अनुमानित prefix की मौजूदगी बताने वाला संकेत, सामग्री उजागर किए बिना।^[1]
CWE-524: संवेदनशील जानकारी वाले cache का उपयोग; सलाह का मुख्य वर्गीकरण।^[1]

फ्रेमवर्क मैपिंग

इस गाइड में बताई गई कमजोरी के लिए CWE संदर्भ: CWE-524

मूल कारण विश्लेषण (Root Cause)

vLLM सलाह POST /v1/responses के GPT-OSS Harmony पथ का वर्णन करती है। शुरुआती input request.cache_salt को tokens_input तक पहुँचाता था; built-in या MCP tool के बाद continuation बिना salt के tokens_input(token_ids) चलाती थी। helper salt तभी सहेजता है जब वह दिया जाए। साझा deployment में automatic prefix caching चालू होने पर continuation बिना salt वाला namespace उपयोग करती थी। सलाह 0.30.0 से पुराने संस्करणों को प्रभावित बताती है, 0.25.1 पर पुष्टि करती है और निचली सीमा को अनिश्चित कहती है। परिणाम cached_tokens_per_turn से cache membership का संकेत है, मनमाने prompt पाठ का सीधा खुलासा नहीं। CWE-200 भी प्रभाव के रूप में सूचीबद्ध है; यहाँ CWE-524 एकमात्र मुख्य कमजोरी है।^{[1], [3], [4]}

हमले का चरण-दर-चरण प्रवाह

चरण 1

साझा सेवा आवश्यक शर्तें पूरी करती है

इसके लिए प्रभावित संस्करण, GPT-OSS Harmony Responses, prefix caching और tool चाहिए; पीड़ित cache_salt सेट करके continuation तक पहुँचता है।^[1]

चरण 2

पहले engine input में salt रहता है

पहली tokens_input कॉल में request.cache_salt होता है, इसलिए prefix कॉलर के salt वाले namespace में जाता है।^[1]

चरण 3

tool continuation salt छोड़ देती है

Tool result के बाद continuation मूल salt के बिना tokens_input(token_ids) चलाती है; prefix साझा बिना-salt namespace में जा सकता है।^[1]

चरण 4

cache count सदस्यता बता सकता है

दूसरा tenant prefix बना सके तो cached_tokens_per_turn से उसकी मौजूदगी का अनुमान लगा सकता है, पर मनमाना prompt पाठ नहीं पा सकता।^[1]

चरण 5

renderer हर turn में salt बनाए रखता है

मर्ज किया renderer refactor Harmony rendering में cache_salt बनाए रखता और हर नए engine input में देता है; 0.30.0+ पर अपडेट करें।^{[1], [3], [7]}

सोर्स कोड: कमज़ोर बनाम सुरक्षित कार्यान्वयन

सोर्स अंश: vLLM Responses Harmony renderer (अलग revisions के अंश)

कमज़ोर कार्यान्वयन

# प्रारंभिक अनुरोध पथ में salt था, लेकिन टूल के बाद की निरंतरता में नहीं।
engine_input = tokens_input(token_ids, cache_salt=request.cache_salt)

# टूल के परिणाम के बाद, निरंतरता इनपुट को इस तरह फिर से बनाती थी:
engine_input = tokens_input(token_ids)

सुरक्षित और सुदृढ़ फ़िक्स

# Harmony रेंडरिंग संदर्भ में अनुरोध का salt बनाए रखें।
cache_salt = cast(str | None, engine_input.get("cache_salt"))
engine_input = self.online_renderer.render_responses_harmony_messages(
    context.messages,
    cache_salt=cache_salt,
    tok_params=tok_params,
)

# रेंडरर इंजन इनपुट बनाते समय हर बार salt देता है।
engine_input = tokens_input(prompt["prompt_token_ids"], cache_salt=cache_salt)

इंजीनियरिंग और सिस्टम सुरक्षा चेकलिस्ट

✓vLLM 0.30.0 या बाद में अपडेट करें और चल रहे संस्करण जाँचें।^{[1], [5]}
✓विश्वसनीय gateway पर अप्रत्याशित cache_salt बनाएँ और हर अनुरोध व continuation में भेजें।^{[6], [1]}
✓जाँचें कि tool के बाद हर Harmony continuation salt बनाए रखती और tenants अलग रखती है।^[7]
✓कड़े isolation के लिए tenants को process या deployment स्तर पर अलग करें।^[6]
✓साझा सुविधाएँ जाँचें और cached_tokens_per_turn metrics तक पहुँच सीमित करें।^[1]
✓जोखिम को prefix inference कहें, मनमाने prompt का खुलासा नहीं।^[1]