‏چرا CVE-2026-48931 نباید CVE می‌شد

نویسندهٔ پست که خودش نگهدارندهٔ undici و استک HTTP نودجی‌اسه، می‌گه این ایراد رو خودش گزارش و وصله کرده و حالا فکر می‌کنه دو تا از تصمیم‌هاش اشتباه بوده. ماجرا اینه: HTTP/1.1 هیچ شناسه‌ای برای پاسخ نداره و کلاینت فقط بر اساس ترتیب، پاسخ N رو به درخواست N نسبت می‌ده. حالا اگه سروری روی یه سوکت keep-alive که بیکار تو استخر http.Agent نشسته یه پاسخ اضافهٔ ناخواسته بنویسه، دفعهٔ بعد همون بایت‌ها به‌جای پاسخ واقعی خونده می‌شن و از اون به بعد همه‌چیز یه واحد جابه‌جا می‌شه.

به گفتهٔ نویسنده سه دلیل نظرشو عوض کرده. اول اینکه این حمله فقط وقتی معنی داره که سرور مقابل خودش مخرب باشه، و سروری که بهش اعتماد نداری از راه‌های خیلی ساده‌تری هم می‌تونه بهت آسیب بزنه. دوم اینکه همهٔ کلاینت‌های HTTP/1.1، از curl و Go و urllib3 تا OkHttp و JDK و Jetty، دقیقاً همین مسابقه رو دارن؛ پس این خاصیت پروتکله نه باگ مخصوص نودجی‌اس. سوم اینکه این شکاف اصلاً قابل بستن نیست: تشخیصش نیازمند خوندن سوکته و خوندن نسبت به تصمیمِ استفادهٔ دوباره ناهمگامه.

با این حال می‌گه وصله رو نگه دارین، چون حالتی که قبلاً همیشه قابل‌سوءاستفاده بود رو می‌بنده. مشکل اصلی پیاده‌سازیش بود: نگهبان اولیه یه لیسنر عمومی data روی سوکت بیکار می‌ذاشت و node-fetch@2 که از تعداد لیسنرهای data وضعیت استریم رو حدس می‌زنه، خطای جعلی ERR_STREAM_PREMATURE_CLOSE می‌داد. چون وصله تو یه انتشار امنیتی هماهنگ همزمان روی ۲۲.x، ۲۴.x و ۲۶.x رفت، دامنه‌ش فوری و وسیع شد: APIهای گوگل، لاگین Firebase، Backstage و ایمیج‌های رسمی داکر.

نویسنده می‌گه CITGM، همون کاناری نودجی‌اس، دقیقاً برای گرفتن همین جور رگرسیون‌هاست، ولی node-fetch نسخهٔ ۲ چون تقریباً متروکه شده تو لیستش نبود. تهِ حرفش هم یه هشدار بزرگ‌تره: گزارش‌های امنیتی نودجی‌اس از تک‌رقمی در ماه به ۶۴ تا رسیده، ولی از ۲۶۴ گزارش فقط حدود ۱۲ درصد واقعی بوده. به گفتهٔ او هوش مصنوعی حالا گزارش‌هایی می‌نویسه که همهٔ بررسی‌های ارزون رو رد می‌کنن، و چیزی که کم میاد وقت و قضاوت انسانیه.

نکات کلیدی:

• CVE-2026-48931 یعنی مسمومیت صف پاسخ روی سوکت‌های keep-alive در http.Agent
• ریشه‌اش به نبودِ شناسهٔ پاسخ در HTTP/1.1 برمی‌گرده، پس همهٔ کلاینت‌ها همین مسابقه رو دارن
• وصلهٔ بعدی (PR #64004) به‌جای لیسنر عمومی از قلاب داخلی onread استفاده می‌کنه
• راه‌حل قطعی: استفادهٔ دوبارهٔ سوکت با سرور نامطمئن رو کنار بذار، یا برو سراغ HTTP/2 و HTTP/3