آسیب پذیری بحرانی PHP؛ خطر اجرای کد از راه دور روی سرورها

آسیب پذیری های امنیتی از نظر سطح بحرانی بودن و ضمنا میزان تاثیرگذاری بر بخش های مختلف یک سیستم اطلاعاتی انواع متخلفی دارند; گاهی اوقات یک آسیب پذیری در افزونه ای خاص پیدا می شود و فقط مدیرانی که همان افزونه را نصب کرده اند باید نگران باشند و اقداماتی را در راستای مقابله با آن انجام دهند. بعضی وقت ها نیز مشکل فقط به یک CMS یا Framework محدود است و با بروزرسانی همان نرم افزار می توان بخش اصلی ریسک را برطرف کرد. اما ماجرا زمانی جدی تر می شود که ضعف امنیتی در لایه ای قرار داشته باشد که بخش بزرگی از وب برای اجرای برنامه های خود به آن وابسته باشد!

در ۲۱ اکتبر ۲۰۲۶، دو آسیب پذیری بحرانی در هسته PHP با شناسه های CVE-2026-109618 و CVE-2026-109619 افشا شده اند که هر دو ضعف می توانند در شرایط مناسب به اجرای کد از راه دور بدون نیاز به احراز هویت منتهی شوند. در پاسخ به این رخداد امنیتی، پروژه PHP برای هر دو آسیب پذیری، بروزرسانی فوری را اطلاع رسانی و توصیه کرده است. Google Cloud نیز دامنه نسخه های آسیب پذیر را از PHP 5.4 تا PHP 8.5.11 اعلام کرده و نسخه های 8.5.12، 8.4.27، 8.3.36 و 8.2.35 را به عنوان نسخه های اصلاح شده معرفی می کند.

وسعت استفاده از PHP باعث می شود چنین رخدادی فقط مسئله توسعه دهندگان این زبان پر استفاده نباشد. طبق اطلاعات منتشر شده توسط W3Techs در ۲۳ اکتبر ۲۰۲۶، PHP در ۶۹.۳ درصد وب سایت هایی که زبان سمت سرور آنها توسط این سرویس قابل تشخیص است، مورد استفاده قرار گرفته است. این آمار با عبارت کلی «۷۰ درصد کل اینترنت» دقیقا یکسان نیست، اما همچنان نشان می دهد چرا یک آسیب پذیری در PHP Runtime می تواند دامنه بسیار وسیعی از سایت ها، فروشگاه ها، سامانه های اختصاصی و سرویس های آنلاین را تحت تاثیر قرار دهد.

موضوع برای هوش سپید زمانی جنبه عملی تری پیدا کرد که آقای نیما جعفری، متخصص ارشد سئو، طی ایمیلی این دو CVE را برای اطلاع رسانی ارسال کرده و نسبت به اثر احتمالی آنها بر سایت ها هشدار داده است. ایشان علاوه بر تاکید بر به روز نگه داشتن قالب ها و افزونه ها و تهیه نسخه پشتیبان خارج از سرور، اطلاعیه اضطراری WoodMart را نیز ارسال کرده اند؛ اطلاعیه ای که از مدیران فروشگاه های WordPress می خواهد WoodMart، PHP، WordPress و افزونه های خود را بررسی و به روز کنند.

بررسی دقیق این هشدار نکته مهمی را روشن می کند: توصیه های صورت گرفته برای به روز نگه داشتن کل Stack امنیتی کاملا منطقی است، اما دو CVE مورد بحث با آپدیت کردن Plugin یا Theme برطرف نمی شوند. مشکل اصلی در خود PHP Runtime قرار دارد و تا زمانی که PHP Patch نشود، آسیب پذیری اصلی همچنان باقی است. از طرف دیگر، WoodMart همزمان چند مشکل امنیتی مستقل در خود قالب پیدا کرده و آنها را در نسخه 8.6.5 اصلاح کرده است؛ بنابراین در یک سایت WordPress ممکن است همزمان چند لایه مختلف نیازمند Update باشند.

PHP Runtime دقیقا چیست و چرا آسیب پذیری در این لایه حساسیت بالایی دارد؟

برای فهم شدت این دو CVE ابتدا باید به درستی جایگاه PHP Runtime را در معماری یک وب سایت درک کنیم. وقتی کاربر صفحه ای از یک سایت WordPress، سیستم فروشگاهی WooCommerce یا برنامه اختصاصی PHP را باز می کند، درخواست او ابتدا به زیرساخت وب، یعنی سرور میزبان می رسد و در بسیاری از معماری ها PHP مسئول اجرای کد سمت سرور، پردازش درخواست ها، مدیریت حافظه و تولید پاسخ مناسب است. WordPress، Magento و بسیاری از اپلیکیشن های دیگر روی این لایه اجرا می شوند، اما خود PHP یک کامپوننت مستقل از آنهاست.

به همین دلیل باید میان دو سناریو تفاوت قائل شویم. اگر آسیب پذیری در یک پلاگین وردپرس باشد، معمولا بروزرسانی همان پلاگین مشکل را برطرف می کند؛ اما اگر نقص در PHP Runtime باشد، حتی سایتی که WordPress Core، Theme و تمام پلاگین های آن کاملا به روز هستند نیز می تواند روی یک Runtime آسیب پذیر اجرا شود.

پروژه PHP اعلام کرده است Installationهایی که Web Request پردازش می کنند در محدوده این دو نقاط ضعف قرار می گیرند؛ از جمله محیط های مبتنی بر PHP-FPM، mod_php، php-cgi، FrankenPHP و LiteSpeed. برای mod_php حتی مسیر اکسپلویت بدون نیاز به اجرای Application Code نیز نشان داده شده است، موضوعی که اهمیت Patch کردن لایه Runtime را بیشتر می کند.

CVE-2026-109618؛ وقتی مدیریت کمبود حافظه خودش به نقطه ضعف تبدیل می شود

اولین آسیب پذیری به نحوه رفتار PHP هنگام بروز وضعیت Out-of-Memory مربوط است. PHP هنگام پردازش یک درخواست مجموعه ای از ساختارهای داخلی را ایجاد و فرآیند Initialization یا مقداردهی اولیه انجام می شود. در حالت عادی، این ساختارها به شکل مشخصی ساخته می شوند، درخواست پردازش می شود و در پایان نیز منابع مربوط به آن آزاد می شوند. اما اگر Runtime در لحظه نامناسب با کمبود حافظه مواجه شود، ممکن است این چرخه پیش از تکمیل Initialization بعضی ساختارهای داخلی، قطع شود.

CVE-2026-109618 دقیقا در همین نقطه شکل می گیرد. در شرایط خاص، PHP هنگام Cleanup ممکن است با داده ای که هنوز به درستی Initialize نشده است مانند یک ساختار معتبر رفتار کند. نتیجه می تواند Memory Corruption باشد و طبق Advisory رسمی، مسیر آسیب پذیری قابلیت رسیدن به Remote Code Execution را دارد .این نکته از نظر آموزشی مهم است، زیرا «Out of Memory» را معمولا فقط با Crash یا کاهش دسترسی پذیری مرتبط می دانیم. در این سناریو، مشکل صرفا تمام شدن حافظه نیست؛ نحوه مدیریت همان وضعیت خطا است که ممکن است باعث ایجاد زمینه حمله یا Attack Surface شود.

Cloudflare نیز توضیح داده است که ترافیک HTTP دستکاری شده می تواند برای Trigger کردن شرایط موردنیاز این خانواده، از آسیب پذیری ها مورد استفاده قرار گیرد. محدود کردن Request Size یا سایز آپلود در بعضی محیط ها ممکن است بخشی از مسیرهای اکسپلویت شناخته شده را سخت تر کند، اما این اقدامات جای Patch را نمی گیرند.

CVE-2026-109619؛ وقتی State قدیمی بعد از آزاد شدن حافظه باقی می ماند

دومین آسیب پذیری مسیر متفاوتی دارد. در CVE-2026-109619 ممکن است یک Fatal Error باعث شود بخشی از State داخلی Request باقی بماند، در حالی که حافظه ای که آن State به آن اشاره می کرد در پایان Request آزاد شده است. اگر همان Worker بعدا Request دیگری را پردازش کند، ممکن است پیش از Reset کامل State به Referenceهای قدیمی مراجعه شود.

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

Advisory رسمی این ضعف را در خانواده Use After Free و مدیریت نادرست State قرار می دهد و Google Cloud نیز توضیح می دهد که State متعلق به Request می تواند پس از آزاد شدن حافظه پشتیبان آن باقی بماند و Request بعدی از این وضعیت نامعتبر استفاده کند.

از نظر پیامد، این شرایط می تواند به Crash، افشای داده و در وضعیت مناسب به Remote Code Execution منجر شود. بنابراین هرچند مکانیزم دو CVE متفاوت است، هر دو یک نقطه مشترک دارند: خطا در مدیریت حافظه و State داخل خود Runtime می تواند مرز میان یک Bug داخلی و یک آسیب پذیری بحرانی اینترنتی باشد.

شدت آسیب پذیری چقدر است و آیا حمله واقعی هم دیده شده است؟

برای هر دو CVE امتیاز CVSS v4.0 برابر 9.2 و سطح Critical اعلام شده است. Google Cloud نیز هشدار داده که پیامدهای Exploit موفق می تواند شامل Crash، Hijack شدن سیستم و سرقت، تغییر یا حذف اطلاعات باشد.با این حال، CVSS را نباید به این معنا تفسیر کرد که هر سرور PHP بدون هیچ پیش شرطی قابل نفوذ است. معماری Web Server، نحوه اجرای PHP، Configuration، Memory Limitها، Worker Model و کنترل های دفاعی همگی می توانند روی امکان اکسپلویت شدن اثر بگذارند.

چیزی که سطح فوریت را از یک Advisory معمولی بالاتر می برد، گزارش Cloudflare است. این شرکت می گوید اطلاعات آسیب پذیری پیش از اطلاع رسانی رسمی افشا شده و ترافیک حملات واقعی علیه مشتریان خود را مشاهده کرده است. Cloudflare همچنین گزارش کرده مهاجمان Payloadها را تغییر می داده اند تا بتوانند Ruleهای دفاعی را دور بزنند.از این اطلاعات یک نتیجه می توان گرفت و آن هم این است که ما با یک سناریوی صرفا تئوریک مواجه نیستیم. تلاش برای Exploitation در اینترنت دیده شده، هرچند این موضوع به معنی موفق بودن همه حملات یا Compromise شدن همه سایت های PHP نیست.

آیا واقعا 70 درصد اینترنت تحت تاثیر این اتفاق قرار می گیرد؟

در هشدارهای اولیه ای که توسط منابع مختلف صادر شده ، به گستردگی PHP و تاثیر بالقوه رخداد بر حدود ۷۰ درصد وب اشاره شده است. اصل نگرانی کاملا قابل درک است، اما برای انتشار فنی بهتر است این عدد با تعریف دقیق خود منبع بیان شود.

W3Techs در ۲۳ اکتبر ۲۰۲۶ گزارش کرده که از بین وب سایت هایی که زبان سمت سرور آنها توسط W3Techs قابل تشخیص است، در ۶۹.۳ درصد آنها از PHP استفاده می شود. در میان یک میلیون سایت برتر این مجموعه نیز سهم PHP حدود ۶۴.۴ درصد گزارش شده است.

بنابراین جمله دقیق تر این نیست که «۷۰ درصد تمام اینترنت قطعا آسیب پذیر است». اولا لزوما همه سایت های PHP روی نسخه آسیب پذیر قرار ندارند و در ثانی W3Techs ادعا نکرده است که زبان سمت سرور صد درصد وب سایت های جهان را می شناسد. اما حتی با در نظر گرفتن این ملاحظات، نتیجه همچنان قابل توجه است. PHP یکی از گسترده ترین Runtimeهای سمت سرور وب است و یک آسیب پذیری در Core آن می تواند سطح Exposure بسیار بزرگی ایجاد کند. همین دقت در بیان اعداد شاید جزئی به نظر برسد، اما تفاوت میان یک محتوای هشداردهنده قابل اعتماد و یک تیتر اغراق آمیز دقیقا در ارائه همین جزئیات است.

چه نسخه هایی آسیب پذیرند و باید به کدام نسخه ارتقا داد؟

طبق Google Cloud، نسخه های PHP از 5.4 تا 8.5.11 در دامنه آسیب پذیری قرار می گیرند. نسخه های اصلاح شده اصلی عبارت اند از:

پروژه PHP به کاربرانی که در حال حاضر از نسخه های پشتیبانی شده استفاده می کنند، توصیه کرده است فورا به نسخه اصلاح شده ارتقا دهند. PHP 8.1 و نسخه های قدیمی تر دیگر از طرف پروژه اصلی Patch عادی دریافت نمی کنند، هرچند بعضی Distributionها و LTS Vendorها ممکن است Fix را به Package خود Backport کنند. در چنین محیطی باید وضعیت Package را از Vendor همان سیستم عامل یا ارائه دهنده سرویس میزبانی بررسی کرد.

این تفاوت اهمیت دارد، چون فقط نگاه کردن به شماره نسخه همیشه کافی نیست. ممکن است Distribution یک Fix امنیتی را Backport کرده باشد اما Major Version را تغییر نداده باشد. برای همین در سرورهای Enterprise باید علاوه بر PHP Version، Security Advisory خود Vendor نیز بررسی شود.

WordPress و WooCommerce چه ارتباطی با این مشکل دارند؟

WordPress منشأ CVE-2026-109618 یا CVE-2026-109619 نیست و درست نیست این رخداد را «آسیب پذیری WordPress» بنامیم. مشکل در PHP Runtime قرار دارد. اما WordPress برای اجرا به PHP وابسته است. بنابراین اگر WordPress، WooCommerce یا یک سایت فروشگاهی روی Runtime آسیب پذیر اجرا شود، زیرساخت آن در محدوده خطر قرار می گیرد.

اینجا همان نکته ای مطرح می شود که در ایمیل آقای نیما جعفری هم روی آن تاکید شده بود: در روزهایی که چند رخداد امنیتی همزمان اتفاق می افتند، فقط یک Component را بررسی نکنید. Core، Theme، Pluginها، PHP Runtime و خود Hosting Environment هر کدام چرخه Patch مستقل خود را دارند. اما ترتیب منطقی را باید حفظ کرد. Update کردن افزونه ها و قالب ها PHP CVE را Patch نمی کند؛ همان طور که Patch کردن PHP نیز آسیب پذیری جداگانه یک Plugin یا Theme را برطرف نمی کند. این تفکیک در اطلاعیه جدید WoodMart به خوبی دیده می شود.

چرا هشدار WoodMart مهم است و چه ارتباطی با این CVEها دارد؟

یک روز پس از انتشار آسیب پذیری های PHP، تیم WoodMart اطلاعیه ای با سطح فوریت بسیار بالا برای کاربران خود منتشر کرد. در این اطلاعیه از مدیران فروشگاه ها خواسته شده WoodMart را به نسخه 8.6.5 یا جدیدتر ارتقا دهند، WordPress و تمام Pluginها را به روز کنند و در صورت استفاده از سرویس میزبانی اشتراکی، از سرویس دهنده بخواهند PHP را نیز به نسخه اصلاح شده منتقل کند. اما علت انتشار WoodMart 8.6.5 خود دو CVE PHP نیست.

تیم WoodMart می گوید در جریان یک Security Review داخلی، چند مشکل امنیتی مستقل در خود WoodMart پیدا کرده که جزئیات عمومی آنها منتشر نشده و Fixها در نسخه 8.6.5 قرار گرفته اند. WoodMart می گوید شواهدی در اختیار ندارد که نشان دهد دیگران از این مشکلات اطلاع داشته یا از آنها سوءاستفاده کرده اند. این تفاوت باید کاملا روشن باشد:

WoodMart 8.6.5 مشکلات WoodMart را اصلاح می کند؛ PHP 8.5.12، 8.4.27، 8.3.36 یا 8.2.35 دو CVE هسته PHP را اصلاح می کنند.

اتفاقا همزمانی این دو رخداد دلیل خوبی است که مدیر سایت فقط به یک صفحه Update نگاه نکند و کل Software Stack خود را بشناسد. Woodmart به مدیران سایت پیشنهاد کرده علاوه بر Update، حساب های Administrator، Database، فایل های سایت و خود Server را نیز بررسی کنند. این تیم به طور مشخص mu-plugins، پوشه Upload، فایل .htaccess، Cron Jobها، System Userها و SSH Keyهای ناشناس را از نقاطی می داند که در بررسی پس از یک رخداد امنیتی ارزش توجه دارند.

توصیه تهیه Backup چقدر مهم است؟

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

اینکه می گوییم مستقل از سرور به این دلیل است که اگر مهاجم به سرور دسترسی گسترده پیدا کند، Backup هایی که در همان سرور ذخیره شده اند نیز ممکن است حذف، رمزگذاری یا دستکاری شوند. به همین دلیل نسخه های Backup ای که به صورت Off-server یا آفلاین هستند یا به عبارت دیگر، در محل دیگری به غیر از آن سرور ذخیره و نگهداری می شوند می توانند در شرایط بحرانی ارزش و کارایی بسیار بیشتری داشته باشند.

البته باید توجه داشت که Backup به تنهایی کافی نیست و نمی تواند جای کارهایی مانند Patch یا Incident Response را بگیرد. به عبارت دیگر داشتن Backup به این معنی نیست که می توان سیستم آسیب پذیر را بدون نگرانی در اینترنت نگه داشت؛ Backup ابزار بازیابی اطلاعات پاک شده است و در مواردی مانند پیشگیری از حمله کاربرد خاصی ندارد.

نکته مهم تر این است که Backup باید قابل بازیابی باشد. Backup ای که هیچ وقت تست نشده و مطمئن نیستیم که در صورت نیاز، قابل بازیابی است، در لحظه بحران صرفا هنوز یک فرض قابل امتحان است، نه یک راهکار تاییدشده.

چرا WAF مهم است، اما جای Patch را نمی گیرد؟

انتشار php2shell نمونه بسیار خوبی برای فهم تفاوت Mitigation و Remediation است. در واقع Web Application Firewall یا WAF قبل از رسیدن درخواست به سرور، ترافیک HTTP را بررسی می کند و اگر الگوی حمله را تشخیص دهد می تواند درخواست را Block کند. در شرایطی که Patch هنوز روی تمام سرورها نشده باشد این اقدام خیلی موثر است و همین چند ساعت یا چند روز کاهش Exposure می تواند بسیار ارزشمند باشد.

Cloudflare اعلام کرده است مکانیزم های امنتیتی مربوط به php2shell را حدود ۹ ساعت پیش از افشای عمومی فعال کرده و کاربران Free و Paid دارای WAF را به صورت خودکار تحت پوشش Ruleهای جدید قرار داده است. نکته فنی جالب این است که Cloudflare برای تشخیص این حملات فقط Request را بررسی نکرده است. این شرکت قابلیت Full Transaction Detection را برای همین موضوع به کار گرفته که Signals موجود در Request و Response را کنار هم قرار می دهد. دلیل این کار این است که یک Request به تنهایی همیشه برای تشخیص Exploit از Traffic قانونی کافی نیست؛ رفتار Response Origin می تواند Context بیشتری درباره موفق شدن مسیر حمله بدهد. اما خود Cloudflare تاکید می کند که این Ruleها یک لایه دفاع در عمق هستند و مشتریان باید PHP را Patch کنند.

این تفاوت بسیار مهم است:

WAF تلاش می کند Exploit را متوقف کند؛ Patch علت اصلی آسیب پذیری را از Runtime حذف می کند.

اگر از Cloudflare، Cloud Armor یا WAF دیگری استفاده می کنید، فعال بودن آن دلیل خوبی برای به تاخیر انداختن PHP Update نیست.

در مقاله هوش سپید درباره حمله ClickFix و CAPTCHA جعلی نیز از زاویه دیگری همین مفهوم دفاع در عمق را می بینیم؛ جایی که نه Awareness به تنهایی کافی است و نه Endpoint Protection به تنهایی تمام زنجیره های حمله را پوشش می دهد.

اگر مدیر یک سایت WordPress هستیم، امروز چه کار کنیم؟

در این مرحله بهتر است به جای چند توصیه پراکنده، یک ترتیب عملی داشته باشیم:

1. نسخه واقعی PHP سایت را بررسی کنید. در WordPress می توانید از Tools → Site Health → Info → Server شروع کنید، اما در VPS یا سرور اختصاصی وضعیت PHP-FPM، Web Server و Containerهای فعال را نیز بررسی کنید.
2. PHP را به نسخه Patch شده منتقل کنید. اگر مدیریت PHP در دست سرویس دهنده است، از او درباره Patch مشخص این دو CVE سوال کنید.
3. WordPress Core، Theme و Pluginها را جداگانه بروز کنید. این کار دو CVE PHP را رفع نمی کند، اما آسیب پذیری های مستقل در لایه Application را کاهش می دهد.
4. اگر WoodMart دارید، حداقل نسخه 8.6.5 یا جدیدتر را نصب کنید. این Update مشکلات امنیتی مستقل WoodMart را اصلاح می کند.
5. قبل و بعد از هر تغییر کلیدی، Backup خارج از سرور تهیه کنید و امکان بازیابی آن را بررسی کنید.
6. WAF را فعال نگه دارید، اما آن را جای Patch در نظر نگیرید.
7. Logها را فقط از زمان Patch به بعد نبینید. Cloudflare ترافیک حمله واقعی را گزارش کرده است؛ بنابراین Web Server Log، WAF Event و سایر Telemetry مربوط به ساعات یا روزهای قبل از Patch نیز ارزش بررسی دارند.
8. اگر نشانه ای از Compromise پیدا شد، استراتژی باید از مدیریت آسیب پذیری به پاسخ به حادثه تغییر کند. در این وضعیت تغییر پسوورد و بروزرسانی نرم افزار به تنهایی کافی نیست و باید Persistence،اکانت ها، فایل ها، دیتابیس و سرور به دقت بررسی شوند.

این ترتیب یک تفاوت مهم ایجاد می کند: به جای انجام چند آپدیت و فرض اینکه «کار تمام شده»، ابتدا Exposure را می شناسید، سپس آسیب پذیری را اصلاح می کنید و در پایان بررسی می کنید آیا پیش از Patch اتفاقی افتاده است یا نه.

اگر از سرویس میزبانی اشتراکی استفاده می کنیم چه کنیم؟

در سرویس های میزبانی اشتراکی، معمولا کاربر به پکیج های سیستم عامل یا تنظیمات اصلی PHP دسترسی مستقیم ندارد، اما این به معنی سلب مسئولیت از کاربر نیست. اولین قدم این است که ورژن فعال PHP را از Control Panel یا Site Health بررسی کنید و سپس از سرویس دهنده درباره وضعیت CVE-2026-109618 و CVE-2026-109619 سوال مشخص بپرسید.

به جای سوال کلی «سرورها آپدیت هستند؟» بهتر است بپرسید:

«PHP Runtime مربوط به سرویس من برای CVE-2026-109618 و CVE-2026-109619 Patch شده یا Vendor Fix مربوط به آن Backport شده است؟»

این سوال سرویس دهنده را مجبور می کند درباره خود آسیب پذیری و اقدامات احتمالی که در راستای مدیریت آن انجام داده است پاسخ دهد، نه وضعیت کلی Maintenance.

اگر Hosting امکان انتخاب PHP Version دارد، پس از اطمینان از سازگاری سایت، به یکی از نسخه های قابل پشتیبانی و Patch شده منتقل شوید.

Container و Cloud Environmentها را فراموش نکنید

یکی از خطاهای رایج این است که مدیر سرور یا هاست سیستم عامل را Patch می کند و تصور می کند Containerها نیز خودکار اصلاح شده اند.

اگر PHP داخل Container Image شما قرار دارد، Runtime آسیب پذیر ممکن است همچنان داخل Image قدیمی باقی مانده باشد. در این شرایط Image باید با نسخه جدید PHP Rebuild و Workload دوباره Deploy شود.

Google Cloud همین مسئله را برای Cloud Run، GKE و Custom Runtimeها مطرح کرده و تاکید کرده است Environmentهایی که Automatic Base Image Update ندارند باید Rebuild و Redeploy شوند.

این موضوع یکی از درس های مهم Asset Inventory مدرن است: فقط نباید بدانید «چند سرور داریم». باید بدانید چه Runtime، Container، Image و Dependencyهایی روی آنها در حال اجرا هستند.

برای مخاطبانی که می خواهند جای Asset Management، Vulnerability Management و سایر لایه های امنیت را در مسیر یادگیری خود بهتر ببینند، مقاله نقشه راه جامع یادگیری امنیت سایبری هوش سپید ادامه طبیعی این بحث است.

آیا صرفا با Patch کردن کار تمام می شود؟

نه لزوما. Patch کردن، آسیب پذیری را از نقطه اصلی برطرف می کند، اما اگر Exploit قبل از بروزرسانی موفق شده باشد، Patch کردن PHP مهاجم را از سیستمی که قبلا Compromise شده بیرون نمی کند.

به همین دلیل بعد از یک آسب پذیری بحرانی که فرآیند اکسپلویت آن در اینترنت مشاهده شده، باید میان دو سوال تفاوت قائل شویم:

1. آیا سرور هنوز آسیب پذیر است؟
2. آیا سرور قبل اکسپلویت شده است؟

سوال اول با تست ورژن اپلیکیشن آسیب پذیر و وضعیت آپدیت آن پاسخ داده می شود. سوال دوم به لاگ ها، Telemetry، تست یکپارچگی و در صورت وجود شواهد، اجرای پروتکل پاسخ به حادثه نیاز دارد.

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

اگر مهاجم بتواند Remote Code Execution به دست بیاورد، باید فرض کرد دارایی هایی که Process PHP به آنها دسترسی داشته نیز بالقوه در معرض خطر بوده اند. Environment Variableها، Database Credentialها، Secretها، Configuration Fileها و Session Data نمونه هایی هستند که بسته به Architecture می توانند اهمیت پیدا کنند.

در تحلیل قبلی هوش سپید درباره JSCeal و سرقت Session Cookie نیز از زاویه دیگری توضیح دادیم که پس از Compromise شدن Endpoint یا Runtime، فقط Password مهم نیست و Token و Session نیز می توانند برای مهاجم ارزشمند باشند.

چرا این رخداد فقط یک خبر PHP نیست؟

دو CVE جدید PHP در ظاهر یک موضوع تخصصی برای توسعه دهنده یا Server Administrator هستند، اما اگر کمی عقب تر بایستیم، چند مفهوم بنیادی امنیت را همزمان در آنها می بینیم.

Asset Inventory به ما می گوید باید بدانیم PHP کجا اجرا می شود. Vulnerability Management مشخص می کند کدام Versionها در معرض خطرند. Patch Management مسئول حذف ضعف از Runtime است. WAF نقش Compensating Control را بازی می کند. Logging و Monitoring به ما کمک می کنند بفهمیم آیا Exploit Attempt رخ داده است، و اگر شواهدی از نفوذ پیدا شود، Incident Response وارد ماجرا می شود.

در کنار همه اینها Backup و Recovery نیز معنا پیدا می کنند، اما نه به عنوان جایگزین امنیت؛ بلکه به عنوان آخرین لایه برای بازگرداندن سرویس و داده در شرایطی که کنترل های پیشگیرانه کافی نبوده اند.

این دقیقا همان نوع ارتباطی است که در یادگیری امنیت اهمیت دارد. حفظ کردن اینکه CVE-2026-109618 چه امتیازی دارد مفید است، اما مهم تر این است که بتوانیم بفهمیم یک سازمان از لحظه Disclosure تا Patch و سپس Investigation باید چگونه تصمیم بگیرد.

در دوره جامع و عملی Security Plus هوش سپید نیز مفاهیمی مانند Threat و Vulnerability، انتخاب Control مناسب، مدیریت ریسک، Incident Response، Monitoring و Defense in Depth به صورت مرتبط با هم آموزش داده می شوند، نه مجموعه ای از تعریف های جداگانه. صفحه دوره نیز بر تحلیل سناریوهای واقعی و تبدیل دانش نظری به مهارت عملی تاکید دارد.

جمع بندی؛ مهم ترین کار امروز چیست؟

CVE-2026-109618 و CVE-2026-109619 دو آسیب پذیری Critical در خود PHP Runtime هستند و مسئله اصلی آنها با Update کردن WordPress، Plugin یا Theme برطرف نمی شود. Runtime باید به نسخه Patch شده یا Packageای منتقل شود که Vendor آن Fixهای لازم را Backport کرده است.

اگر سایت WordPress یا WooCommerce دارید، این رخداد در عین حال فرصت خوبی برای بازبینی کل Stack است. هشدار آقای نیما جعفری درباره به روز نگه داشتن اجزای سایت و تهیه Backup خارج از Server، با توصیه هایی که WoodMart نیز در اطلاعیه اضطراری خود مطرح کرده هم جهت است؛ با این تفاوت که باید بدانیم هر Update دقیقا کدام لایه از ریسک را برطرف می کند. WoodMart 8.6.5 مشکلات WoodMart را Patch می کند، PHP Update این دو CVE را رفع می کند و Backup نیز برای Recovery است، نه Prevention.

از طرف دیگر، گزارش Cloudflare از Attack Traffic واقعی نشان می دهد بررسی این آسیب پذیری ها را نباید به Change Window نامعلوم آینده موکول کرد. WAF می تواند زمان بخرد، اما آسیب پذیری را از Runtime حذف نمی کند.

پاسخ درست به همین سه سوال، از ده ها Update کورکورانه ارزش بیشتری دارد.