آسیب پذیری PHP2Shell و Node.js: چه اتفاقی افتاد و سایت شما چه کند؟

روز چهارشنبه ۲۹ مهر ۱۴۰۵ (۲۱ اکتبر ۲۰۲۶) پروژه PHP چهار نسخه امنیتی تازه منتشر کرد: ۸.۵.۱۲، ۸.۴.۲۷، ۸.۳.۳۶ و ۸.۲.۳۵. این نسخه ها دو آسیب پذیری بحرانی را می بندند. رسانه ها مجموعه این دو را آسیب پذیری PHP2Shell نامیده اند. همان روز Node.js هم یک به روزرسانی امنیتی داد و ده آسیب پذیری را برطرف کرد.

پایین تر توضیح داده ایم هر آسیب پذیری دقیقا چیست و کدام نسخه ها وصله شده اند. بعد می بینید تا ۳۰ مهر چه حمله هایی گزارش شده و مدیر یک سایت ایرانی چه اقدامی باید انجام دهد. چند مورد را هم خودمان از یک سرور در تهران آزمایش کرده ایم.

چرا این خبر این قدر بزرگ شد

دلیلش سهم PHP از وب است. طبق W3Techs، PHP در ۳۰ مهر ۱۴۰۵ (۲۲ اکتبر ۲۰۲۶) در ۶۹٫۳ درصد از سایت هایی استفاده می شد که زبان برنامه نویسی سمت سرورشان مشخص است. وردپرس، Laravel، Drupal، Joomla و Magento همه روی PHP اجرا می شوند.

رسانه ها هم همین عدد را در تیتر آورده اند. PBS نوشته این آسیب پذیری «می تواند» روی ۷۰ درصد وب سایت های جهان اثر بگذارد. The Conversation از نقصی بحرانی نوشته که ۷۰ درصد وب سایت ها را تحت تاثیر قرار می دهد. تیتر TechCrunch هم در همان روز می گفت اینترنت روز بسیار بدی را از نظر امنیتی می گذراند و PHP و Node.js را کنار هم آورده بود.

این دو آسیب پذیری به هم ربطی ندارند. PHP و Node.js دو پروژه جدا هستند و هر کدام فقط سروری را تهدید می کنند که همان را اجرا می کند. Node.js محیطی است که برنامه های جاوااسکریپت را روی سرور اجرا می کند و برنامه هایی مثل Express و Next.js روی آن کار می کنند. عدد ۷۰ درصد فقط درباره PHP است.

آسیب پذیری PHP2Shell: دو مورد با امتیاز ۹٫۲

طبق اطلاعیه امنیتی PHP، این دو آسیب پذیری با شناسه های CVE-2026-109618 و CVE-2026-109619 ثبت شده اند. هر دو در مقیاس CVSS نسخه ۴ امتیاز ۹٫۲ از ۱۰ گرفته اند. PHP یک روز زودتر، در ۲۸ مهر، خبر انتشار این وصله ها را داده بود.

هر دو از نوع «اجرای کد از راه دور» هستند. یعنی مهاجم می تواند از بیرون و بدون داشتن حساب کاربری، دستور دلخواه خودش را روی سرور اجرا کند. به نوشته Tenable، PHP می گوید مهاجم برای هیچ کدام از این دو به احراز هویت نیاز ندارد.

اولین آسیب پذیری (CVE-2026-109618) به کمبود حافظه مربوط است. اگر حافظه سرور در لحظه ای تمام شود، PHP ممکن است وسط آماده سازی اطلاعات داخلی یک درخواست متوقف شود. بعد، هنگام پاک سازی، همان اطلاعات نیمه کاره را سالم فرض می کند و با آن ها مثل اطلاعات درست رفتار می کند.

دومی (CVE-2026-109619) مشکل حافظه آزادشده است. PHP روی سرور با چند فرایند آماده به کار اجرا می شود. هر کدام از این فرایندها که به آن ها worker می گویند، یکی پس از دیگری به چند درخواست جواب می دهند. در این آسیب پذیری، بخشی از اطلاعات یک درخواست بعد از آزاد شدن حافظه اش در worker باقی می ماند و درخواست بعدی ممکن است از آن استفاده کند. توصیه نامه رسمی در GitHub این حالت را use-after-free می نامد و می گوید درخواست اول و دوم باید به یک worker برسند.

اثر آسیب پذیری دوم فقط اجرای کد نیست. Tenable می نویسد افشای حافظه هم از اثرهای تاییدشده آن است و حافظه یک worker ممکن است رمز عبور یا کلید API داشته باشد. هیچ منبعی که بررسی کردیم نگفته است که چنین اطلاعاتی واقعا به سرقت رفته باشد.

نسخه وصله شده PHP و تکلیف نسخه های قدیمی

نسخه های وصله شده ۸.۵.۱۲، ۸.۴.۲۷، ۸.۳.۳۶ و ۸.۲.۳۵ هستند. PHP ۸.۱ و نسخه های قدیمی تر دیگر به روزرسانی رسمی نمی گیرند. با این حال تیم امنیتی PHP برای ۷.۴، ۸.۰ و ۸.۱ وصله های کوچکی روی کد منبع منتشر کرده است. این وصله ها بسته آماده نیستند و باید روی کد منبع اعمال و دوباره کامپایل شوند. به نوشته Tenable برای نسخه های ۵.۴ تا ۷.۳ هیچ اصلاحی از طرف پروژه PHP وجود ندارد و قدیمی ترین کد آسیب پذیر به PHP ۵.۴.۰ برمی گردد.

آمار W3Techs نشان می دهد این موضوع چقدر جدی است. بین سایت هایی که از PHP استفاده می کنند، ۶۵٫۳ درصد روی PHP ۸ هستند، ۲۶٫۹ درصد روی PHP ۷، ۷٫۷ درصد روی PHP ۵ و ۰٫۱ درصد روی PHP ۴. یعنی ۳۴٫۷ درصد سایت های PHP نسخه ۷ یا قدیمی تر دارند. چون PHP در حدود ۶۹٫۳ درصد سایت های شناخته شده استفاده می شود، این رقم تقریبا ۲۴ درصد همان سایت ها را شامل می شود. این محاسبه از خودمان است و W3Techs آن را به این شکل منتشر نکرده است.

این رقم تازه حداقل ماجراست. W3Techs فقط نسخه اصلی را نشان می دهد و PHP ۸.۰ و ۸.۱ که وصله رسمی ندارند، در همان ۶۵٫۳ درصد پنهان اند. از طرف دیگر، سایت هایی که روی ۸.۲ تا ۸.۵ هستند هم تا وقتی به نسخه وصله شده نرسیده اند آسیب پذیرند. هیچ منبعی نگفته است که تا امروز چند سایت وصله شده اند.

کدام نصب ها بیشتر در خطرند

اطلاعیه PHP هر نصبی را که درخواست وب را جواب می دهد آسیب پذیر می داند. این فهرست PHP-FPM، Apache با ماژول mod_php، php-cgi، FrankenPHP و LiteSpeed را شامل می شود.

بیشترین خطر از نظر PHP مربوط به mod_php است، چون برای آن اکسپلویت نمایشی وجود دارد. در این اکسپلویت یک درخواست بدون احراز هویت حمله را فعال می کند، آن هم پیش از آنکه هیچ کدی از خود برنامه اجرا شود. برای بقیه حالت ها، در صفحه هایی که بررسی کردیم اکسپلویت نمایشی ذکر نشده است. این یعنی خطرشان کمتر مستند شده، نه اینکه امن باشند.

اگر سرور شما Apache با mod_php دارد، آن را زودتر از بقیه وصله کنید.

تا ۳۰ مهر چه حمله ای گزارش شده است

طبق Tenable، بخش Amazon Threat Intelligence روز ۲۵ مهر (۱۷ اکتبر)، یعنی چهار روز قبل از اعلام عمومی، یک تلاش حمله را روی هانی پات های خودش ثبت کرد. هانی پات سیستمی است که عمدا آسیب پذیر نشان داده می شود تا حمله ها را شناسایی کند. روز ۲۹ مهر هم موارد بیشتری دیده شد و Amazon می گوید PHP2Shell همین حالا به طور گسترده مورد سوءاستفاده قرار می گیرد.

Cloudflare از شروع حمله های اولیه خبر داده و شرکت امنیتی watchTowr می گوید هر دو آسیب پذیری را خودش بازتولید کرده است. Tenable می نویسد کدهای حمله ای هم به صورت عمومی دست به دست می شود، اما هنوز تایید نشده که واقعا کار کنند. تیم PHP هم هنگام انتشار گفته بود کد حمله کاملی ندیده است. به نوشته همان منبع، گروه Calif اجرای کد بدون احراز هویت را روی نسخه هایی از وردپرس، Drupal، Joomla و Magento نشان داده است.

یک بررسی ساده را هم خودمان انجام دادیم. در ۳۰ مهر فهرست آسیب پذیری های سوءاستفاده شده CISA را دانلود کردیم. CISA سازمان امنیت سایبری آمریکاست. نسخه این فهرست 2026.10.21 بود که ساعت ۱۴:۰۴ به وقت UTC در ۲۱ اکتبر منتشر شده بود و ۱۷۵۴ ردیف داشت. هیچ کدام از دو آسیب پذیری PHP و چهار آسیب پذیری با شدت بالای Node.js در آن نبودند. این فهرست فقط مواردی را دارد که سوءاستفاده از آن ها تایید شده است. پس نبودشان فقط یعنی تا آن لحظه هنوز ثبت نشده بودند.

خلاصه وضعیت تا ۳۰ مهر این است: تلاش برای حمله گزارش و در چند منبع تایید شده، اما شمار سایت های نفوذ شده را هیچ منبعی که بررسی کردیم اعلام نکرده است. نبودن عدد به معنای نبودن نفوذ نیست. فقط یعنی عددی که بتوان به آن استناد کرد هنوز منتشر نشده است.

PBS می نویسد دولت های بریتانیا، فنلاند و ژاپن بخشی از خدمات خود را موقتا از دسترس خارج کردند. دولت ژاپن هم گفته است گزارشی از خسارت دریافت نکرده است. در آن گزارش این قطعی ها نشانه نفوذ تاییدشده معرفی نشده اند.

آسیب پذیری Node.js: ده مورد در یک انتشار

اعلام امنیتی Node.js روز ۲۹ مهر سه نسخه وصله شده معرفی کرد: ۲۲.۲۳.۴، ۲۴.۲۲.۱ و ۲۶.۱۲.۱. در مجموع ده آسیب پذیری بسته شده است که چهار تای آن ها شدت بالا، سه تا شدت متوسط و سه تا شدت پایین دارند. چهار مورد مهم تر این ها هستند:

• CVE-2026-111497 در بخشی از Node.js است که فایل های فشرده به روش Brotli را باز می کند. این بخش ممکن است در حافظه جایی بنویسد که اجازه ندارد و طبق عنوان اعلام، همین به اجرای کد از راه دور می رسد. این مورد هر سه خط ۲۲، ۲۴ و ۲۶ را شامل می شود.
• CVE-2026-105483 یک ضعف در بررسی گواهی TLS است، یعنی همان چیزی که اتصال HTTPS را امن نگه می دارد. اگر نشانی IP با ارقام تمام عرض نوشته شود، بررسی اینکه نام سرور با گواهی می خواند دور زده می شود. فقط نسخه های ۲۶ و ۲۴ را درگیر می کند.
• CVE-2026-106069 همین ضعف را به شکل دیگری دارد: وقتی میزبان به صورت غیر دقیق به یک IP تعبیر شود، بررسی نام در گواهی دور زده می شود. این مورد هر سه خط را شامل می شود.
• CVE-2026-105482 مربوط به تابع dns.resolve است. این تابع نام هایی را که کاراکتر NUL دارند کوتاه می کند. هر سه خط را شامل می شود.

این سه مورد آخر به Brotli ربطی ندارند. برنامه ای که Brotli باز نمی کند هم از آن ها معاف نیست. صفحه اعلام برای هر مورد فقط یک خط توضیح می دهد، پس نمی توانیم بگوییم دقیقا چه نوع برنامه ای بیشتر در خطر است.

در همین انتشار چند بخش وابسته هم به روز شده است: c-ares، OpenSSL، SQLite، Undici و فهرست گواهی های معتبر. فهرست گواهی ها برای این به روز شد که یکی از مراجع صدور گواهی میانی متعلق به eMudhra به خطر افتاده است.

صفحه اعلام درباره حمله فعال و راه حل موقت چیزی نمی گوید و فقط توصیه می کند از نسخه به روز استفاده کنید. یک قاعده هم در آن آمده است: نسخه هایی که پشتیبانی شان تمام شده، در هر انتشار امنیتی «همیشه آسیب پذیر» حساب می شوند.

آسیب پذیری Brotli: چه برنامه هایی واقعا در خطرند

همه برنامه های Node.js به یک اندازه در خطر نیستند. طبق توصیه نامه Vercel، برنامه ای در معرض خطر است که خودش یا کتابخانه ای که استفاده می کند، داده Brotli ای را باز کند که مهاجم آن را کنترل می کند. پاسخی که برنامه از یک سرور دیگر می گیرد هم همین حکم را دارد. اگر برنامه ای هیچ داده Brotli ای را باز نکند، این آسیب پذیری راهی به آن ندارد.

The Hacker News سه حالت را برای فعال شدن آن نام می برد. حالت اول استفاده مستقیم از ماژول node:zlib است. حالت دوم دریافت پاسخ فشرده با تابع fetch() است. حالت سوم پردازش بدنه درخواست های HTTP است که با Brotli فشرده شده اند.

درباره میزان خطر، دو منبع با هم هم نظر نیستند. Vercel می گوید پژوهشگران روی نسخه های وصله نشده ۲۲، ۲۴ و ۲۶ افشای حافظه و اجرای دستور را نشان داده اند. The Hacker News می گوید کد حمله عمومی که ۳۰ مهر منتشر شد فقط روی یک نسخه عمدا ضعیف شده به اجرای کد رسید. روی نسخه معمولی فقط از کار افتادن برنامه و خواندن محدودی از حافظه دیده شده و تا ۳۰ مهر هم حمله ای در دنیای واقعی گزارش نشده بود.

به نظر ما هر دو می توانند درست باشند، چون یکی درباره نمایش پژوهشگران است و دیگری درباره کدی که در دسترس عموم است. این برداشت از خودماست و هیچ کدام از دو منبع آن را نگفته اند.

راه حل موقتی هم در خود Node.js وجود ندارد. قاعده فایروال Vercel حمله های ورودی را مسدود می کند، اما پاسخ هایی را که برنامه از بیرون می گیرد بررسی نمی کند. خود Vercel هم می گوید این قاعده جای به روزرسانی را نمی گیرد.

نسخه های وصله شده PHP و Node.js در یک جدول

تاریخ پایان پشتیبانی PHP ۸.۲ از صفحه نسخه های پشتیبانی شده PHP گرفته شده است. صفحه نسخه های قبلی Node.js نسخه های ۱۸ و ۲۰ را پایان یافته نشان می دهد و Vercel هم می گوید Node.js ۲۰ این وصله را نمی گیرد.

سایت شما به کدام آسیب پذیری مربوط است

اگر سایت شما با وردپرس، Drupal، Joomla، Magento یا Laravel ساخته شده، روی PHP اجرا می شود و آسیب پذیری PHP2Shell به شما مربوط است. به روزرسانی وردپرس یا افزونه ها نسخه PHP را تغییر نمی دهد، چون PHP لایه ای پایین تر از آن هاست. حتی افزونه ای مثل Elementor Pro هم داخل وردپرس نصب می شود و روی همان PHP کار می کند. پس نصب Elementor Pro یا به روزرسانی اش این مشکل را حل نمی کند.

اگر سایت شما با React ساخته شده و فقط فایل های آماده آن از روی nginx ارائه می شود، روی سرور Node.js اجرا نمی شود. اما اگر از Next.js در حالت سرور، Express یا Nest.js استفاده می کنید، Node.js روی سرور شما کار می کند و آسیب پذیری های آن به شما مربوط است. مقایسه وردپرس و کد اختصاصی را در صفحه خدمات طراحی سایت و سئو می توانید ببینید. هر کدام به پروژه امنیتی دیگری وابسته است.

چطور نسخه سرور خود را بفهمید

پیش از آپدیت PHP باید بدانید سرور شما دقیقا چه نسخه ای دارد. اگر به سرور دسترسی دارید، دستور php -v نسخه PHP را نشان می دهد. این همان PHP خط فرمان است و لزوما همان نسخه ای نیست که به درخواست های وب جواب می دهد. برای فهمیدن اینکه Apache با mod_php کار می کند یا نه، دستور apachectl -M فهرست ماژول های بارگذاری شده را نشان می دهد. اگر ماژول php در آن باشد، یعنی mod_php فعال است. در Debian و Ubuntu سرویس PHP-FPM معمولا شماره نسخه را در اسمش دارد. مثلا برای نسخه ۸.۳ اسمش php8.3-fpm است.

بعد از به روزرسانی، Apache، PHP-FPM و هر برنامه دیگری را که مدام در حال اجراست ری استارت کنید. چون worker های در حال اجرا هنوز کد قدیمی را در حافظه دارند. خود اطلاعیه PHP هم برای تنظیم های موقت، ری استارت همه worker ها را لازم می داند. اگر بعد از ری استارت صفحه های Elementor Pro خطای ۵۰۴ دادند، علت های رایج آن در ایران در مطلب رفع خطای ۵۰۴ المنتور پرو توضیح داده شده است.

درباره بسته های لینوکس هم یک نکته هست. اطلاعیه PHP می گوید توزیع ها و فروشندگان LTS وصله ها را از قبل دریافت کرده اند. برای همین ممکن است شماره نسخه سرور شما قدیمی به نظر برسد، در حالی که وصله شده است. به جای شماره نسخه، یادداشت تغییرات (changelog) بسته را برای شماره CVE بررسی کنید.

برای Node.js دستور node -v را بزنید و نتیجه را با ۲۲.۲۳.۴، ۲۴.۲۲.۱ یا ۲۶.۱۲.۱ مقایسه کنید. دستور which -a node را هم اجرا کنید، چون ممکن است چند نسخه روی یک سرور نصب باشد. مثلا یکی با apt، یکی با nvm و یکی هم همان که ابزار مدیریت فرایند استفاده می کند. نسخه جدید تا وقتی برنامه را ری استارت نکنید اثری ندارد. اگر برنامه شما در Docker اجرا می شود، به گفته Vercel باید image را دوباره بسازید.

اگر از هاست اشتراکی استفاده می کنید، خودتان نمی توانید PHP را وصله کنید و باید از پشتیبانی هاست بپرسید. سه سوال کافی است: آیا CVE-2026-109618 و CVE-2026-109619 روی سرور من وصله شده اند؟ سایت من با چه نسخه ای از PHP کار می کند؟ و PHP روی این سرور با LiteSpeed، PHP-FPM یا mod_php اجرا می شود؟ اگر فقط بگویند «نسخه ما ۸.۳ است» و شماره CVE را نگویند، جواب کافی نیست.

اگر همین امروز نمی توانید به روزرسانی کنید

اطلاعیه PHP چند تنظیم موقت پیشنهاد می کند و تاکید دارد که با آن ها نصب شما امن نمی شود. برای CVE-2026-109618 باید memory_limit=-1 را طوری تنظیم کنید که برنامه نتواند آن را تغییر دهد. این کار با php_admin_value در تنظیمات FPM یا Apache انجام می شود. مقدار post_max_size را هم کم نگه دارید، یعنی ۸ مگابایت یا اگر آپلود فایل لازم دارید ۳۲ مگابایت، و upload_max_filesize را از آن کمتر بگذارید.

برای CVE-2026-109619 باید session.upload_progress.enabled=0 را تنظیم کنید. روی PHP ۸.۵ تنظیم fatal_error_backtraces=0 را هم بگذارید. بعد از هر تغییر همه worker ها را ری استارت کنید. به این نکته توجه کنید که تنظیم session.upload_progress با ini_set یا فایل user.ini کار نمی کند.

فایروال راه دیگری است، اما آن هم فقط موقت است. Tenable می نویسد قاعده های Cloudflare فقط یک راه حل موقت اند و تنها ترافیکی را پوشش می دهند که از Cloudflare عبور می کند. طبق PBS، FBI توصیه کرده سایتی که نمی تواند فورا به روزرسانی شود، موقتا آفلاین شود و نخست وزیر ژاپن هم تعلیق موقت را یک گزینه دانسته است. اگر سایت شما پرداخت آنلاین یا اطلاعات شخصی دارد، این گزینه را جدی بگیرید.

برای Node.js هیچ راه حل موقتی وجود ندارد و تنها راه، ارتقاست.

ایران: آنچه از یک سرور در تهران دیدیم

اولین سوال برای مدیر ایرانی این است که آیا اصلا می تواند به منابع وصله برسد. در ۳۰ مهر ۱۴۰۵، حدود ساعت ۱۸ به وقت تهران، از یک سرور در تهران (ParsPack، شبکه AS60631) با درخواست GET و مشخصات یک مرورگر، چند نشانی را باز کردیم. نتیجه این بود:

• صفحه اعلام امنیتی Node.js در nodejs.org در ۰٫۴۷ ثانیه باز شد. یک مگابایت اول فایل node-v24.22.1-linux-x64.tar.xz هم در ۰٫۶۵ ثانیه دانلود شد.
• مخزن npm و مخزن NodeSource (registry.npmjs.org و deb.nodesource.com) هر دو در کمتر از نیم ثانیه جواب دادند، به ترتیب در ۰٫۳۷ و ۰٫۳۸ ثانیه.
• صفحه توصیه نامه PHP در GitHub در ۰٫۴۹ ثانیه باز شد.
• سایت php.net کند بود. صفحه اطلاعیه امنیتی (۹۹ کیلوبایت) و صفحه نسخه ها (۶۸۵ کیلوبایت) هر دو حدود ۷٫۵ ثانیه طول کشیدند. در اجرای اول، سقف ۱۵ ثانیه ای ما برای صفحه نسخه ها کافی نبود. نشانی downloads.php.net هم در ۰٫۶۶ ثانیه ما را به نشانی دیگری هدایت کرد و ما فایلی دانلود نکردیم.
• مخزن Remi (rpms.remirepo.net) در حدود ۷ ثانیه باز شد.
• رجیستری Docker پاسخ ۴۰۱ داد، آن هم در ۰٫۵۳ ثانیه. این پاسخ عادی آن نشانی بدون ورود به حساب است و یعنی رجیستری در دسترس است. ما تصویری دانلود نکردیم.
• صفحه HTML فهرست CISA خطای ۴۰۳ داد، اما فایل JSON همان فهرست (۱٫۸ مگابایت) در ۳٫۹ ثانیه دانلود شد.

این آزمایش فقط یک سرور و یک عصر را نشان می دهد و نباید آن را به همه شبکه های ایران تعمیم داد. اما در همین یک اندازه گیری، منابع Node.js سریع بودند و منابع PHP کند ولی در دسترس. یعنی دست کم از این سرور، شبکه دلیل تاخیر در وصله کردن نیست. یک نکته کاربردی هم دارد: اگر می خواهید فهرست CISA را خودکار بررسی کنید، فایل JSON را بخوانید، نه صفحه HTML را.

نکته دوم درباره فایروال های خارجی است. قاعده های Cloudflare و Vercel فقط ترافیکی را پوشش می دهند که از شبکه خودشان عبور می کند. سایتی که پشت CDN ایرانی است یا CDN ندارد، از آن ها سودی نمی برد. ما در ۳۰ مهر به فارسی و انگلیسی دنبال اطلاعیه میزبان ها و CDN های ایرانی درباره این دو آسیب پذیری گشتیم و چیزی پیدا نکردیم. این به معنای بی عملی آن ها نیست، فقط نشانی عمومی قابل استنادی پیدا نکردیم. اگر سایت شما روی میزبان ایرانی است، همان سه سوال بخش قبل را مستقیم از پشتیبانی بپرسید. درباره انتخاب بین سرور ایران و CDN، مطلب سرور ایران یا CDN ایرانی نکات دسترسی را توضیح داده است.

نکته سوم مخزن Remi است. اطلاعیه PHP به کسانی که PHP را از مخزن rpms.remirepo.net نصب کرده اند، صریحا توصیه می کند به بسته های خود توزیع لینوکس یا ساخت از کد منبع روی بیاورند. اگر PHP سرور شما از آن مخزن آمده، اول مطمئن شوید بسته وصله شده از منبع دیگری می رسد.

سوالات متداول

با به روزرسانی وردپرس سایتم امن می شود؟

نه. آسیب پذیری در خود PHP است و وردپرس فقط روی آن اجرا می شود. نسخه PHP را میزبان یا مدیر سرور تعیین می کند و جداگانه باید به روز شود. به روزرسانی وردپرس و افزونه ها کار درستی است، اما این آسیب پذیری را نمی بندد.

PHP ۸.۲ دارم و به ۸.۲.۳۵ رسیده ام. دیگر کاری لازم نیست؟

برای این دو آسیب پذیری، درست است. اما پشتیبانی امنیتی شاخه ۸.۲ تا ۱۰ دی ۱۴۰۵ ادامه دارد. طبق صفحه نسخه های پشتیبانی شده PHP، شاخه ۸.۳ تا ۱۰ دی ۱۴۰۶ (۳۱ دسامبر ۲۰۲۷) پشتیبانی امنیتی می گیرد. پشتیبانی امنیتی شاخه ۸.۴ تا ۱۱ دی ۱۴۰۷ (۳۱ دسامبر ۲۰۲۸) و شاخه ۸.۵ تا ۱۱ دی ۱۴۰۸ (۳۱ دسامبر ۲۰۲۹) ادامه دارد. اگر قرار است همین هفته ارتقا بدهید، مقصد را ۸.۳ یا بالاتر بگذارید تا چند ماه دیگر مجبور نشوید دوباره همین کار را تکرار کنید.

PHP ۷.۴ یا ۸.۱ دارم. چه کنم؟

سه راه دارید. می توانید بررسی کنید که بسته لینوکس شما وصله را گرفته است یا نه. می توانید وصله کوچک کد منبع را خودتان اعمال و PHP را دوباره کامپایل کنید. یا می توانید به شاخه ای بروید که هنوز پشتیبانی می شود. راه سوم ماندگارتر است. پیش از ارتقا، افزونه ها و قالب ها را روی یک نسخه آزمایشی سایت امتحان کنید.

بعد از وصله باید رمزها را عوض کنم؟

Tenable می نویسد افشای حافظه از اثرهای تاییدشده آسیب پذیری دوم است و حافظه worker ممکن است رمز عبور یا کلید API داشته باشد. هیچ منبعی نگفته است که رمزی واقعا دزدیده شده باشد. عوض کردن رمز پایگاه داده و کلیدهای API بعد از وصله یک احتیاط است و توصیه رسمی هیچ شرکتی نیست. اگر سایت شما اطلاعات کاربران را نگه می دارد، این چند دقیقه ارزشش را دارد.

چطور بفهمم این آسیب پذیری ها وارد فهرست CISA شده اند؟

لازم نیست مرورگر باز کنید. دستور curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json | grep -c CVE-2026-109618 را اجرا کنید. عدد صفر یعنی آن شناسه هنوز در فهرست نیست. همین کار را برای CVE-2026-109619 و CVE-2026-111497 تکرار کنید. ما این فایل را از یک سرور در تهران هم دانلود کردیم و مشکلی نداشت.

Node.js ۲۰ دارم و برنامه ام Brotli باز نمی کند. باز هم باید ارتقا بدهم؟

بله. طبق اعلام Node.js، نسخه های بدون پشتیبانی در هر انتشار امنیتی آسیب پذیر حساب می شوند و Node.js ۲۰ هیچ وصله ای نمی گیرد. سه آسیب پذیری مهم دیگر این انتشار، یعنی دو مورد TLS و یک مورد DNS، هم به Brotli ربطی ندارند. هر آسیب پذیری بعدی هم برای نسخه ۲۰ بی جواب می ماند.