Node.js Security Release جولای 2026؛ 11 آسیب پذیری و نسخه هایی که باید نصب کنید

Node.js در 29 ژوئیه 2026 سه نسخه امنیتی 22.23.2، 24.18.1 و 26.5.1 را منتشر کرد. این Release مجموعاً 11 آسیب پذیری را پوشش می دهد؛ سه مورد High، پنج مورد Medium و سه مورد Low. در این راهنما فقط شماره CVEها را ردیف نمی کنیم: مشخص می کنیم هر دسته به چه workloadی مربوط است، چه نسخه ای باید نصب شود و Patch را چگونه بدون تبدیل کردن یک اصلاح امنیتی به Incident عملیاتی منتشر کنید.

دقیقاً چه چیزی در 29 ژوئیه منتشر شد؟

صفحه رسمی Node.js اعلام می کند Updateهای امنیتی برای شاخه های 26.x، 24.x و 22.x در دسترس اند. نسخه های دانلود مشخص شده در همان صفحه به ترتیب 26.5.1، 24.18.1 و 22.23.2 هستند. این نکته مهم است چون خبر اولیه چند بار به دلیل نیاز به تست و مشکلات زیرساختی به تعویق افتاد؛ بنابراین تاریخ رخداد نهایی را باید 29 ژوئیه و نه تاریخ برنامه ریزی اولیه در نظر گرفت.

در کنار CVEهای خود Runtime، وابستگی های داخلی undici و llhttp هم Patch شده اند. Node.js برای undici نسخه های 8.9.0، 7.29.0 و 6.28.0 را متناسب با خطوط Release و برای llhttp نسخه 9.4.3 را ذکر می کند. اگر اپلیکیشن شما undici را به صورت Dependency مستقیم نیز نصب کرده است، Runtime update و Package update را دو موضوع جدا در Inventory ببینید.

سه CVE با شدت High؛ کدام سرویس ها اولویت دارند؟

CVE-2026-56846 مربوط به HTTP/2 است: Header blockهای نگه داری شده می توانند محدودیت maxSessionMemory را دور بزنند و به مصرف حافظه از راه دور منجر شوند. منبع رسمی Impact را برای خطوط فعال 24.x و 22.x ذکر می کند. اگر API Gateway یا Reverse Proxy شما HTTP/2 را تا Node terminate می کند، این مسیر باید در اولویت تست قرار بگیرد؛ صرف حضور Nginx یا Load Balancer به معنی حذف Exposure نیست مگر دقیقاً بدانید پروتکل در کدام لایه terminate می شود.

CVE-2026-56848 نیز HTTP/2 است اما جنس آن متفاوت است: re-entrant send می تواند heap-use-after-free ایجاد کند و خطوط 26.x، 24.x و 22.x را درگیر می کند. CVE-2026-58043 به Permission Model مربوط است و path matching می تواند دسترسی filesystem را بیش از allowlist اعطاشده باز کند. پس یک سرویس ممکن است HTTP/2 نداشته باشد اما به خاطر اجرای Node با --permission همچنان Patch با اولویت بالا بخواهد.

• HTTP/2 عمومی یا اینترنتی: ابتدا CVE-2026-56846 و CVE-2026-56848 را با Topology واقعی شبکه تطبیق دهید.
• استفاده از --permission و allowlist فایل: CVE-2026-58043 را Security Boundary تلقی کنید.
• سرویس های داخلی نیز در صورت دریافت ورودی غیرقابل اعتماد یا داشتن دسترسی فایل حساس از اولویت خارج نمی شوند.

پنج مورد Medium؛ از mTLS تا SQLite و DNS

دو CVE به HTTPS Agent و reuse اتصال مربوط اند. CVE-2026-56850 می تواند هویت mTLS را میان PFXهای متفاوت اشتباه reuse کند و CVE-2026-58040 نقصی در hostname verification هنگام reuse نشست TLS را هدف می گیرد. اگر یک Process به چند مقصد با Client Certificate یا Policy هویتی متفاوت متصل می شود، تست Connection Pooling و Agent reuse باید بخش مستقلی از Regression Suite باشد.

سه مورد Medium دیگر گستره متفاوتی دارند. CVE-2026-58041 روی node:sqlite و SQLTagStore iterator اثر دارد و طبق منبع رسمی خطوط 26.x و 24.x را درگیر می کند. CVE-2026-58042 می تواند dns.resolveAny() را با پاسخ دارای بیش از 256 رکورد A به abort برساند. CVE-2026-58045 نیز APIهای sync در node:zlib را در برابر TypedArray با طول جعلی به crash می رساند. معیار اولویت این موارد «Medium بودن» نیست؛ این است که آیا API موردنظر در مسیر ورودی قابل کنترل کاربر قرار دارد یا نه.

سه مورد Low را چرا نباید نادیده گرفت؟

دو مورد Low دوباره به Permission Model برمی گردند. CVE-2026-56847 اجازه می دهد trace events خارج از allowlist نوشتن فایل تولید کنند و CVE-2026-58039 برای process.report مسیر مشابهی ایجاد می کند. اگر --permission را بخشی از sandbox یا hardening جدی می دانید، چند نقص در یک Release پیام روشنی دارد: Permission Model باید لایه دفاعی باشد، نه تنها مرز اعتماد سیستم.

CVE-2026-58044 در HTTP parser می تواند در Proxyهایی که headerهای قابل مشاهده در userland را بازسازی می کنند اما Body اصلی را به connection reused می فرستند، شرایط request smuggling ایجاد کند. Low در CVSS به معنی «بی اثر برای معماری من» نیست. Proxyهای سفارشی، API gatewayهای Node-based و middlewareهای خاص باید این مسیر را جدا بررسی کنند.

کدام نسخه را نصب کنیم؟

اگر روی خط 22 هستید، مقصد Patch معرفی شده 22.23.2 است؛ برای 24، نسخه 24.18.1 و برای 26، نسخه 26.5.1. از جهش ناخواسته بین Majorها وسط Incident خودداری کنید مگر Branch فعلی شما EOL باشد. Security Patch و Major Migration دو دامنه ریسک متفاوت اند و بهتر است در Changeهای مستقل انجام شوند.

در Containerها به Tag ظاهری اکتفا نکنید. Image اجراشده را با digest شناسایی کنید و داخل همان Container خروجی process.version یا node --version را ثبت کنید. اگر Build Cache دارید، مطمئن شوید Rebuild واقعاً Base Image جدید را کشیده است. Tag شناور بدون ثبت Digest می تواند Audit را بعداً غیرقابل بازسازی کند.

Exposure را بدون حدس زدن چگونه تعیین کنیم؟

یک Sheet یا Query ساده بسازید که برای هر سرویس Version، Protocol، Permission Model، mTLS، sqlite، dns.resolveAny، zlib sync و نقش Proxy را ثبت کند. بعد CVEها را به capability واقعی وصل کنید. این کار سریع تر از این است که همه تیم ها 11 Advisory را جدا بخوانند و با برداشت شخصی اولویت بدهند.

سطح Exposure باید با مسیر داده کامل سنجیده شود. مثلاً HTTP/2 ممکن است در CDN terminate شود و Node فقط HTTP/1.1 ببیند؛ یا برعکس Proxy با h2c به Backend وصل شود. mTLS ممکن است فقط در Worker خاص باشد. Inventory قابلیت، Patch Queue را به چیزی قابل دفاع تبدیل می کند.

Test Plan قبل از Rollout

برای HTTP و TLS، Smoke Test معمولی کافی نیست. Handshake، keep-alive، connection reuse، HTTP/2 stream concurrency و endpointهای پرمصرف را با همان Proxy chain محیط اصلی آزمایش کنید. برای Permission Model نیز دسترسی مجاز و غیرمجاز به چند path مرزی را تست کنید تا علاوه بر رفع CVE، Regression در allowlist خودتان را ببینید.

برای sqlite، DNS و zlib مسیرهای واقعی برنامه را اجرا کنید. هدف exploit کردن نیست؛ هدف اطمینان از این است که Patch رفتار معتبر برنامه را نشکسته. Native Addon، APM Agent و instrumentationهایی که به Runtime internals نزدیک اند نیز باید در Canary زیر نظر باشند.

Patch را چگونه بدون Big Bang منتشر کنیم؟

Artifact جدید را با نسخه مشخص و SBOM تولید کنید. ابتدا Staging یا Replica کم ریسک، بعد Canary کوچک Production و سپس Rollout مرحله ای. Error Rate، p95/p99 Latency، RSS، Heap، Event Loop Delay، Restart Count و TLS/HTTP errorها را کنار Baseline قبل از Patch قرار دهید. افزایش یک Metric بدون مقایسه تاریخی اطلاعات کافی نمی دهد.

Rollback باید Artifact قبلی و immutable باشد، نه Build دوباره نسخه قدیمی. Database Migration یا Feature rollout را هم زمان با Security Patch انجام ندهید. جداسازی Change باعث می شود اگر Regression رخ داد، سریع بدانید Runtime مقصر است یا تغییر دیگری.

Container، CI و Runtime پنهان را فراموش نکنید

ممکن است Production روی Node 24 باشد اما Runner ساخت، test container یا utility image هنوز Node 22 یا حتی EOL اجرا کند. Inventory را فقط به Web API محدود نکنید. ابزارهای migration، cron job، server-side rendering worker و CLI داخلی نیز Runtime واقعی دارند و می توانند ورودی غیرقابل اعتماد پردازش کنند.

همچنین Action یا Toolی که JavaScript است لزوماً از Node نصب شده کنار اپلیکیشن استفاده نمی کند. Scope را دقیق تشخیص دهید تا Patch effort روی چیزهای نامرتبط پخش نشود. آنچه باید Patch شود Runtime درگیر با Advisory است، نه هر چیزی که در نامش JavaScript دارد.

چک لیست تصمیم برای امروز

برای هر سرویس شش پاسخ ثبت کنید: نسخه واقعی چیست؛ آیا در 22/24/26 یا EOL است؛ کدام قابلیت از CVEها را استفاده می کند؛ Artifact جایگزین چیست؛ تست Tier-1 چیست؛ Rollback دقیقاً چگونه انجام می شود. اگر یکی از این پاسخ ها خالی است، همان مورد باید قبل از Rollout Owner داشته باشد.

بعد از Patch، نسخه Runtime را از محیط اجرا دوباره تأیید کنید. بسته شدن Ticket صرفاً با Merge شدن Pull Request کافی نیست. Security remediation زمانی تمام می شود که Artifact Patch شده واقعاً Deploy شده و سلامت آن با Telemetry تأیید شده باشد.

اگر Change Freeze دارید، Patch امنیتی را چگونه مدیریت کنید؟

Change Freeze برای کاهش ریسک تغییر ساخته شده است، نه برای اینکه یک آسیب پذیری شناخته شده بدون تصمیم باقی بماند. اگر سازمان شما Freeze دارد، به جای دورزدن فرآیند، Exception امنیتی تعریف کنید: Advisory رسمی، سرویس های تحت تاثیر، نسخه مقصد، نتیجه تست، Owner و زمان Rollback را در Change Record ثبت کنید. این مستند کوتاه به مدیر تغییر نشان می دهد که ریسک «نکردن تغییر» نیز اندازه گیری شده است.

اگر Patch فوری روی همه سرویس ها ممکن نیست، اول Exposure را کاهش دهید: سرویس های اینترنتی و HTTP/2، Processهای دارای Permission Model و اتصال های حساس mTLS جلوتر قرار می گیرند. کنترل موقت فقط زمانی قابل دفاع است که تاریخ انقضا داشته باشد. محدودیت شبکه یا غیرفعال کردن قابلیت غیرضروری نباید به یک workaround دائمی تبدیل شود.

پنج اشتباه رایج در Patch کردن Runtime

اشتباه اول اعتماد به نسخه نوشته شده در Repository است؛ نسخه واقعی باید از محیط اجرا خوانده شود. اشتباه دوم Rebuild با Tag شناور بدون تأیید Digest است. اشتباه سوم Merge کردن Security Patch با Upgrade کتابخانه ها و Featureهای نامرتبط است. اشتباه چهارم اعلام پایان کار قبل از Deploy واقعی و اشتباه پنجم نداشتن Baseline برای تشخیص Regression است.

یک اشتباه ظریف دیگر، یکسان دیدن Severity و Priority است. CVE با شدت Medium که دقیقاً روی endpoint اینترنتی شما قرار گرفته می تواند برای کسب وکار فوری تر از CVE High باشد که قابلیت مربوط به آن اصلاً فعال نیست. Severity داده ورودی تصمیم است؛ معماری و Exposure ترتیب اجرا را کامل می کنند.

بعد از Patch، چه Evidenceای نگه داریم؟

برای Audit و Incident بعدی، نسخه قبل و بعد، Image Digest، زمان Deploy، نتیجه Test، نمودار Metricهای کلیدی و لینک Advisory رسمی را نگه دارید. اگر چند Region یا Cluster دارید، تأیید کنید همه Replicaها به Artifact جدید رسیده اند. Mixed-version deployment می تواند باعث شود Scanner بخشی از ناوگان را امن و بخشی را آسیب پذیر گزارش کند.

همچنین یک Task جدا برای پیشگیری بسازید: Runtime lifecycle را وارد Renovation یا Dependency Management دوره ای کنید، Owner نسخه را مشخص کنید و هشدار EOL داشته باشید. بهترین خروجی این Security Release فقط بسته شدن 11 CVE نیست؛ کاهش زمانی است که تیم در Security Release بعدی برای پیدا کردن نسخه واقعی و صاحب هر سرویس مصرف می کند.

نمونه یا الگوی عملی

node --version
node -p "process.versions"
# در Container، image digest و نسخه واقعی runtime را نیز ثبت کنید.
# سپس Artifact جدید را با نسخه Patch شده بسازید و Canary کنید.

این چند خط برای کشف نسخه واقعی Runtime است، نه اسکن آسیب پذیری. نسخه را از همان محیطی بگیرید که Process اجرا می شود؛ فایل .nvmrc یا Dockerfile به تنهایی اثبات نمی کند Production همان نسخه را دارد.

پرسش های متداول

نسخه های امن اعلام شده برای این Release کدام اند؟

در صفحه رسمی Node.js، نسخه های 22.23.2، 24.18.1 و 26.5.1 به عنوان Releaseهای مربوط به این بسته امنیتی لینک شده اند.

آیا Node.js 26 هم از CVE-2026-56846 متاثر است؟

در Impact رسمی همین CVE، خطوط 24.x و 22.x ذکر شده اند. سایر CVEها دامنه متفاوتی دارند؛ برای همین نباید یک حکم واحد برای هر 11 مورد ساخت.

اگر HTTP/2 نداریم می توانیم Patch را عقب بیندازیم؟

خیر. Release شامل Permission Model، TLS/mTLS، SQLite، DNS، zlib و HTTP parser نیز هست. Exposure باید بر اساس قابلیت های واقعی شما تعیین شود.

آیا فقط npm update کافی است؟

نه. CVEهای اصلی مربوط به Runtime هستند و باید نسخه Node.js اجراشده Patch شود. Dependency مستقیم اپلیکیشن مسئله جداگانه ای است.

برای نسخه EOL چه کنیم؟

توصیه رسمی Node.js استفاده از نسخه به روز و پشتیبانی شده است؛ نسخه EOL را به شاخه Supported مهاجرت دهید.

بعد از Deploy چه چیزی را مانیتور کنیم؟

Error Rate، Latency tail، memory، event loop، restart، TLS/HTTP error و شاخص های حیاتی کسب وکار را با Baseline مقایسه کنید.

منابع رسمی

• اعلامیه رسمی Security Release جولای 2026 Node.js — فهرست 11 CVE، Severity، Impact و نسخه های 22.23.2 / 24.18.1 / 26.5.1
• برنامه رسمی Releaseهای Node.js — تشخیص شاخه های Current/LTS/Maintenance و وضعیت EOL