Claude Code की Brotli खामी: सिर्फ़ Node अपडेट काफ़ी नहीं

Claude Code की Brotli खामी की चेतावनी पर कार्रवाई करते समय वही executable अपडेट करें जिसे आप वास्तव में चलाते हैं, क्लाइंट दोबारा शुरू करें और दूसरे टूल के Node.js या Bun रनटाइम पर अलग से पैच लगाएँ। सिस्टम का Node.js अपडेट करने से Claude Code के साथ आने वाला रनटाइम नहीं बदलता; इसमें मौजूदा npm इंस्टॉलेशन से मिलने वाली नेटिव बाइनरी भी शामिल है। 2026-10-23 तक, Anthropic के 2.1.308 रिलीज़ नोट में Brotli सुधार की पुष्टि नहीं है, इसलिए केवल यह संस्करण संख्या सुरक्षा समीक्षा पूरी करने के लिए पर्याप्त प्रमाण नहीं है।

वेब पेज लाने वाले एजेंटों की जाँच क्यों ज़रूरी है

जोखिम तब पैदा होता है जब कोई प्रक्रिया हमलावर के नियंत्रण वाला Brotli डेटा डिकोड करती है। दस्तावेज़ लाते समय या किसी वेबसाइट से सामग्री निकालते समय एजेंट ऐसे डेटा तक पहुँच सकता है—मॉडल को पढ़ने योग्य पेज मिलने से भी पहले।

CVE-2026-111497, Google के Brotli डिकोडर में आवंटित सीमा के बाहर मेमोरी लिखने की खामी है। Google द्वारा तैयार CVE रिकॉर्ड के अनुसार, विशेष रूप से तैयार किए गए संपीड़ित डेटा से मेमोरी की जानकारी लीक हो सकती है, सेवा बाधित हो सकती है या मनमाना कोड चल सकता है। Google ने मूल खामी को CVSS 4.0 पर 9.2, यानी Critical रेटिंग दी है; Node.js सुरक्षा परामर्श में Node.js पर इसके प्रभाव को High बताया गया है।

Bun के fetch दस्तावेज़ बताते हैं कि जवाबों को अपने-आप डीकंप्रेस करना डिफ़ॉल्ट रूप से चालू है और इसमें Brotli का समर्थन है। इसलिए Bun के fetch() का इस्तेमाल करने वाला टूल उस डिकोडर तक पहुँच सकता है जब सर्वर Content-Encoding: br लौटाता है।

इस व्यवहार के कारण स्थानीय रूप से सामग्री लाने वाले टूल की जाँच करनी चाहिए। Claude Code की कोई खास क्रिया प्रभावित डिकोडर तक पहुँचती है या नहीं, यह उसकी बनावट और सामग्री लाने की प्रक्रिया कहाँ चलती है, इस पर निर्भर करता है। स्थानीय MCP सर्वर, शेल कमांड और दूरस्थ सर्वर पर चलने वाली सामग्री-प्राप्ति सेवा अलग-अलग रनटाइम इस्तेमाल कर सकते हैं।

आने वाले अनुरोधों की जाँच करने वाला वेब एप्लिकेशन फ़ायरवॉल हर ऐसे रास्ते को नहीं बचाता। Vercel का परामर्श आने वाले अनुरोधों और एप्लिकेशन द्वारा मँगाए गए जवाबों में स्पष्ट अंतर करता है: WAF सुरक्षा उन जवाबों को संसाधित करने वाले रनटाइम पर पैच लगाने की जगह नहीं लेती।

कौन-से पैच संस्करण पुष्ट हैं?

Node.js और Bun के पैच संस्करणों के लिए प्राथमिक स्रोतों में प्रमाण हैं। Claude Code के लिए सुझाई गई न्यूनतम सुरक्षित रिलीज़ की अलग से पुष्टि चाहिए।

2026-10-23 तक स्थिति:

घटक	सुधार वाला पुष्ट संस्करण	क्या अपडेट करें
Node.js 22.x	22.23.4	उस एप्लिकेशन या टूल द्वारा इस्तेमाल किया जाने वाला Node executable
Node.js 24.x	24.22.1	उस एप्लिकेशन या टूल द्वारा इस्तेमाल किया जाने वाला Node executable
Node.js 26.x	26.12.1	उस एप्लिकेशन या टूल द्वारा इस्तेमाल किया जाने वाला Node executable
आधिकारिक Bun रिलीज़	1.4.4	अलग से इंस्टॉल किया गया Bun, या उसे अपने अंदर शामिल करने वाला एप्लिकेशन
Claude Code	जाँचे गए आधिकारिक प्रमाणों से सुधार वाली पहली रिलीज़ की पुष्टि नहीं हुई है	क्लाइंट को उसके इंस्टॉलेशन माध्यम से अपडेट करें और खास बिल्ड से जुड़ा सत्यापन प्रमाण रखें

21 अक्टूबर का Node.js परामर्श तीनों Node पैच रिलीज़ बताता है। संस्करणों की तुलना उसी रिलीज़ शाखा में करें: Node 24 के लिए 24.22.1 या उसके बाद की पैच वाली रिलीज़ चाहिए, केवल 22.23.4 से संख्यात्मक रूप से बड़ा संस्करण पर्याप्त नहीं है। Node.js 20 को अब यह सुधार नहीं मिलता; Vercel इन उपयोगकर्ताओं को समर्थित रिलीज़ शाखा पर जाने की सलाह देता है।

Bun के सुधार को किसी सामान्य सुरक्षा घोषणा से आगे, खास रिलीज़ के सोर्स तक जाँचा जा सकता है। Jarred Sumner के मर्ज़ किए गए बदलाव में Brotli को 1.2.1 पर अपडेट किया गया है, और Bun 1.4.4 के रिलीज़ टैग की dependency फ़ाइल इसी सुधरे हुए संस्करण को चुनती है। आधिकारिक रिलीज़ 22 अक्टूबर को प्रकाशित हुई थी।

Claude से जुड़ा खास दावा @ryaneshea की 22 अक्टूबर की पोस्ट से आया है: लेखक ने Claude Code 2.1.296 में Bun 1.4.3 मिलने की बात कही और 2.1.308 या नया संस्करण इस्तेमाल करने की सलाह दी। यह समुदाय के एक सदस्य की रिपोर्ट है; संस्करणों के इस संबंध की Anthropic ने पुष्टि नहीं की है।

Anthropic के 2.1.308 रिलीज़ नोट में सिर्फ़ बग ठीक करने और विश्वसनीयता सुधारने की सामान्य बात है। उसके चेंजलॉग में 2.1.309 भी दर्ज है, लेकिन वह 2.1.308 में Bun या Brotli के पैच की पुष्टि नहीं करता। तुरंत अपडेट करें, पर “क्लाइंट अपडेट हो गया” और “अंदर शामिल डिकोडर पर पैच लगने की पुष्टि हुई” को अलग-अलग परिणाम के रूप में दर्ज करें।

Claude Code की वही इंस्टॉलेशन अपडेट करें जिसे आप चलाते हैं

बदलाव करने से पहले सक्रिय इंस्टॉलेशन पहचानें। एक कॉपी अपडेट करने से मदद नहीं मिलेगी अगर टर्मिनल, एडिटर या रनर दूसरी कॉपी चलाता रहे।

Bash में चलाएँ:

type -a claude
claude --version
claude doctor

type -a शेल में बने कमांड उपनाम, फ़ंक्शन और मेल खाने वाले executable के पाथ दिखाता है। CLI संदर्भ के अनुसार, claude doctor इंस्टॉलेशन और सेटिंग्स की केवल जानकारी पढ़कर जाँच करता है और कोई सत्र शुरू नहीं करता।

काम सहेजें और executable बदलने से पहले चालू Claude Code सत्र बंद करें। फिर अपनी इंस्टॉलेशन से मेल खाने वाला अपडेट तरीका चुनें।

नेटिव इंस्टॉलेशन

Bash में चलाएँ:

claude update

अपडेटर autoUpdatesChannel और लागू संस्करण सीमाओं का पालन करता है। इसलिए “अप-टू-डेट” परिणाम का मतलब आपके कॉन्फ़िगरेशन द्वारा अनुमत सबसे नई रिलीज़ भी हो सकता है।

नेटिव इंस्टॉलेशन की रिलीज़ चैनल सेटिंग्स में latest और देर से रिलीज़ पाने वाला stable चैनल अलग हैं। /config → Auto-update channel जाँचें; व्यक्तिगत सेटिंग ~/.claude/settings.json में रहती है। केंद्रीय रूप से प्रबंधित डिप्लॉयमेंट में तैनात संस्करण और उसकी नीति, दोनों को साथ अपडेट करना होगा।

npm इंस्टॉलेशन

npm से प्रबंधित इंस्टॉलेशन को Bash में अपडेट करें:

npm install -g @anthropic-ai/claude-code@latest

मौजूदा npm इंस्टॉलेशन निर्देशों के अनुसार, इंस्टॉल करने के लिए Node.js 22 या नया संस्करण चाहिए। npm पैकेज वही नेटिव बाइनरी देता है जो अलग इंस्टॉलर से मिलती है। ऊपर की तालिका से पैच वाला Node संस्करण चुनें। दस्तावेज़ npm update -g के बजाय स्पष्ट install कमांड सुझाते हैं, क्योंकि npm update -g पैकेज को पुरानी संस्करण सीमा में रख सकता है।

Homebrew के लिए इंस्टॉल किए गए cask के अनुसार brew upgrade claude-code या brew upgrade claude-code@latest इस्तेमाल करें। WinGet के लिए PowerShell में winget upgrade Anthropic.ClaudeCode चलाएँ। इन तरीकों के अपने पैकेज मैनेजर संबंधी अपडेट नियम हैं।

चुना हुआ अपडेट पूरा होने के बाद नया टर्मिनल खोलें। Bash में जाँचें:

hash -r
command -v claude
claude --version
claude doctor

संस्करण वही होना चाहिए जिसे आप इंस्टॉल करना चाहते थे, और कमांड को इच्छित इंस्टॉलेशन ही चुनना चाहिए। अगर command -v किसी फ़ंक्शन या कमांड उपनाम को दिखाता है, तो पहले के type -a आउटपुट से पता करें कि वह किस executable को चलाता है।

एडिटर के भीतर चल रहे और बिना मानवीय निगरानी वाले सत्र अलग से दोबारा शुरू करें। नए टर्मिनल में शुरू किए गए executable की जाँच से यह साबित नहीं होता कि पहले से चल रही पुरानी प्रक्रिया बदल गई है।

अपडेट विफल हो या पुराना संस्करण चलता रहे तो क्या जाँचें

हर चीज़ दोबारा इंस्टॉल करने के बजाय दिखाई दे रहे लक्षण के अनुसार कारण और उपाय चुनें। Anthropic की इंस्टॉलेशन समस्या-निवारण गाइड में कई इंस्टॉलेशन के टकराव, अपडेट विफलताओं और npm से मिलने वाली बाइनरी के गायब होने की स्थितियाँ दी गई हैं।

लक्षण	जाँच और सुधार	परिणाम की पुष्टि
अपडेट पूरा हो गया, लेकिन claude --version अब भी पुरानी रिलीज़ दिखाता है	type -a claude और which -a claude से दूसरी इंस्टॉलेशन खोजें। उस लॉन्चर या PATH प्रविष्टि को ठीक करें जो पुरानी कॉपी चुन रही है।	नया टर्मिनल खोलकर चुनी गई कमांड और संस्करण दोबारा जाँचें।
कस्टम ~/.local/bin/claude लॉन्चर अब भी पुरानी रिलीज़ शुरू करता है	देखें कि वह किस फ़ाइल को चलाता है। नेटिव अपडेटर कस्टम लॉन्चर को बनाए रखता है, इसलिए डिप्लॉयमेंट में लॉन्चर द्वारा चुना गया संस्करण भी बदलें।	उसी लॉन्चर से संस्करण जाँचें, केवल नई डाउनलोड की गई बाइनरी से नहीं।
Error: claude native binary not installed.	जाँचें कि npm ने वैकल्पिक dependencies छोड़ीं या postinstall स्क्रिप्ट चलाना छोड़ दिया। ज़रूरी इंस्टॉलेशन चरण बहाल करके पैकेज दोबारा इंस्टॉल करें।	claude --version सफलतापूर्वक चलता है।
Auto-update failed · Run claude doctor	claude doctor चलाएँ और उसके बताए इंस्टॉलेशन या डाउनलोड संबंधी दोष के लिए गाइड का उचित समाधान अपनाएँ।	उपयुक्त अपडेटर फिर चलाएँ और नई प्रक्रिया में इच्छित संस्करण की पुष्टि करें।

अगर अपडेटर कहता है कि कोई नया अनुमत संस्करण नहीं है, तो काम पूरा मानने से पहले रिलीज़ चैनल और केंद्रीय रूप से लगाई गई अधिकतम संस्करण सीमा जाँचें। इंस्टॉलेशन का सफलतापूर्वक चलना केवल यह बताता है कि प्रोग्राम शुरू हो रहा है; यह Brotli खामी का परीक्षण नहीं है।

क्या Claude Code में बंडल Bun का संस्करण पता किया जा सकता है?

दस्तावेज़ों में दिए गए Claude कमांड एप्लिकेशन का संस्करण और इंस्टॉलेशन की स्थिति बताते हैं। जाँचे गए CLI दस्तावेज़ों में अंदर शामिल Bun का संस्करण दिखाने के लिए कोई समर्थित कमांड नहीं दिया गया है।

bun --version चलाने से आपके PATH पर मौजूद अलग Bun executable का संस्करण मिलता है। इसी तरह सिस्टम की Node प्रक्रिया से संस्करण पूछने पर उसी Node प्रक्रिया की जानकारी मिलती है। इन दोनों में से कोई जाँच Claude Code में शामिल रनटाइम की पहचान नहीं करती।

Bun के दस्तावेज़ों में स्टैंडअलोन executable के लिए BUN_BE_BUN=1 मौजूद है। लेकिन इसे Claude Code की जाँच का समर्थित तरीका नहीं बताया गया है, और kk-mats के Claude Code issue #24575 में संस्करण के अनुसार व्यवहार बदलने की रिपोर्ट है। इसे बिना अतिरिक्त सत्यापन के Claude इंस्टॉलेशन की सुरक्षा जाँच का भरोसेमंद आधार न बनाएँ।

प्रकाशित Claude Code 2.1.308 मैनिफ़ेस्ट में रिलीज़, बिल्ड, प्लेटफ़ॉर्म और चेकसम की जानकारी है, लेकिन Bun का संस्करण नहीं है। Anthropic की हस्ताक्षरित मैनिफ़ेस्ट सत्यापन प्रक्रिया से यह स्थापित किया जा सकता है कि बाइनरी निर्माता की रिलीज़ से मेल खाती है। डिकोडर पर पैच लागू होने की पुष्टि के लिए उस खास फ़ाइल से जुड़े कंपोनेंट या पैच का अतिरिक्त प्रमाण चाहिए।

टीम की सुरक्षा समीक्षा के लिए Claude का संस्करण, प्लेटफ़ॉर्म, इंस्टॉलेशन स्रोत, सक्रिय executable और चेकसम दर्ज करें। अगर अंदर शामिल रनटाइम के सुधार को प्रमाणित करना ज़रूरी है, तो उसी रिलीज़ और प्लेटफ़ॉर्म के लिए निर्माता से पुष्टि लें। प्रमाण मिलने तक परिणाम “क्लाइंट अपडेट हुआ; अंदर शामिल रनटाइम के पैच की स्थिति अपुष्ट है” दर्ज करें और जहाँ जोखिम आकलन इसकी माँग करे, वहाँ प्रभावित प्रक्रियाओं द्वारा बिना निगरानी अविश्वसनीय सामग्री लाना रोकें।

टीम के कंप्यूटर, कंटेनर और CI रनर जाँचें

हर उस वातावरण के अंदर संस्करणों की सूची बनाएँ जहाँ एजेंट का काम वास्तव में चलता है। डेवलपर के लैपटॉप के परिणाम किसी कंटेनर, अपने सर्वर पर चल रहे रनर के खाते या अलग से तैनात MCP सर्वर का विवरण नहीं देते।

मशीनों को केंद्रीय रूप से प्रबंधित करने वाली मौजूदा जॉब या CI चरण में यह Bash ब्लॉक इस्तेमाल करें:

set -u
uname -srm
id -un

for tool in claude node bun; do
  if executable=$(type -P "$tool"); then
    printf '%s\t%s\t' "$tool" "$executable"
    "$executable" --version || exit 1
  else
    printf '%s\tNOT_FOUND\n' "$tool"
  fi
done

आउटपुट में ऑपरेटिंग सिस्टम, प्रक्रिया चलाने वाला उपयोगकर्ता और हर टूल के लिए PATH से चुना गया executable तथा उसका संस्करण मिलता है। NOT_FOUND केवल सूची बनाने का परिणाम है: नेटिव Claude इंस्टॉलेशन के लिए अलग Bun कमांड मौजूद होना ज़रूरी नहीं है।

यह स्क्रिप्ट जानबूझकर सुरक्षा का PASS परिणाम नहीं देती। Node और अलग Bun इंस्टॉलेशन के परिणामों को पुष्ट पैच संस्करणों से मिलाएँ, और Claude की खास बाइनरी के प्रमाण का अलग आकलन करें। Bash का type -P executable पाथ खोजता है; शेल रैपर और कॉन्फ़िगरेशन में स्पष्ट रूप से चुने गए executable की अलग जाँच चाहिए।

टीम में अपडेट लागू करते समय:

1. रनटाइम वातावरण जाँचें। सामान्य PATH सेटअप के बाद, अंतिम कंटेनर या रनर वातावरण के अंदर सेवा चलाने वाले उपयोगकर्ता के रूप में यह ब्लॉक चलाएँ। MCP सर्वर, SDK चलाने वाली प्रक्रियाओं और एडिटर इंटीग्रेशन के executable पाथ अलग से जाँचें।
2. बिल्ड या डिप्लॉयमेंट की परिभाषा अपडेट करें। प्रभावित Node/Bun संस्करण और Claude इंस्टॉलेशन बदलें। इमेज दोबारा इस तरह बनाएँ कि कैश में मौजूद पुरानी इंस्टॉलेशन लेयर पिछले executable को बनाए न रख सके।
3. चल रहे वर्कलोड बदलें। कंटेनर फिर बनाएँ और पुराने इंस्टॉलेशन का इस्तेमाल कर रहे रनर या सेवाएँ दोबारा शुरू करें। नए वर्कलोड में सूची फिर निकालें और परिणामों के साथ इमेज का digest भी रखें।
4. एक सामान्य कार्यप्रवाह जाँचें। पुष्टि करें कि अपडेट किया गया वातावरण अब भी टीम की ज़रूरी टूल क्रिया पूरी करता है। इसे अनुकूलता की जाँच के रूप में दर्ज करें, डिकोडर के पैच के प्रमाण से अलग।

अगर अलग Bun इंस्टॉलेशन को Bun स्वयं प्रबंधित करता है, तो रिलीज़ में दिया गया अपडेट कमांड यह है। इसे Bash में चलाएँ:

bun upgrade
bun --version

इससे वही Bun इंस्टॉलेशन अपडेट होता है। अपने अंदर Bun शामिल करने वाले एप्लिकेशन के लिए उस एप्लिकेशन की नई बिल्ड चाहिए।

कस्टम API गेटवे के साथ भी क्लाइंट अपडेट करें

कस्टम ANTHROPIC_BASE_URL API का गंतव्य बदलता है; वह Claude Code का स्थानीय executable नहीं बदलता। गेटवे से अनुरोध सफल हो रहे हों, तब भी क्लाइंट अपडेट रखें।

आधिकारिक Claude Code चेंजलॉग में गेटवे अनुकूलता के दो अलग सुधार दर्ज हैं:

• 2.1.305: 2.1.304 की उस रिग्रेशन को ठीक करता है जिसमें Vertex, Bedrock या किसी दूसरे endpoint या गेटवे द्वारा टूल खोज अस्वीकार करने पर हर अनुरोध विफल हो सकता था। इसमें वे कॉन्फ़िगरेशन भी शामिल थे जहाँ ToolSearch की अनुमति नहीं थी या उसे --tools में नहीं रखा गया था। अब क्लाइंट उसके बिना अनुरोध दोबारा करता है।
• 2.1.307: कस्टम ANTHROPIC_BASE_URL गेटवे और Foundry पर prompt-caching-scope बीटा हेडर भेजना बंद करता है, जहाँ उसका कोई प्रभाव नहीं होता।

अपडेट के बाद गेटवे वाला वही छोटा कार्यप्रवाह दोहराएँ जो पहले विफल होता था। अगर वह अब भी विफल है, तो मौजूदा क्लाइंट के साथ endpoint का जवाब और कॉन्फ़िगरेशन जाँचें; Brotli अपडेट का दावा गेटवे की हर त्रुटि की वजह नहीं बताता। वहीं, सफल गेटवे अनुरोध उस कार्यप्रवाह की अनुकूलता की पुष्टि करता है; अंदर शामिल रनटाइम के पैच का आकलन अलग जाँच बना रहता है।