مقدمه؛ وقتی یک هشدار امنیتی به تهدیدی واقعی تبدیل میشود
دو آسیبپذیری بحرانی در PHP که با نام PHP2Shell شناخته میشوند، وارد مرحله تازهای از تهدیدات امنیتی شدهاند. آژانس امنیت سایبری و امنیت زیرساخت ایالات متحده (CISA) در تاریخ ۲۶ اکتبر ۲۰۲۶، بهرهبرداری فعال از این دو آسیبپذیری را تأیید و شناسههای مربوط به آنها را به فهرست رسمی آسیبپذیریهای مورد سوءاستفاده واقعی، موسوم به Known Exploited Vulnerabilities یا KEV، اضافه کرد.
اهمیت این خبر در آن است که موضوع دیگر صرفاً شناسایی یک نقص امنیتی یا انتشار کد آزمایشی برای بررسی آن نیست. پژوهشگران امنیتی شواهدی از اجرای موفق کد از راه دور در سامانههای تلهمتری امنیتی ثبت کردهاند و اکنون CISA نیز وضعیت بهرهبرداری فعال را تأیید کرده است.
این دو آسیبپذیری با شناسههای CVE-2026-109618 و CVE-2026-109619 شناخته میشوند و هر دو امتیاز ۹٫۲ از ۱۰ را در سیستم امتیازدهی CVSS دارند.
برای مدیران سرور، شرکتهای میزبانی وب، توسعهدهندگان PHP و مسئولان امنیت زیرساخت، پیام روشن است: بررسی نسخههای نصبشده و اطمینان از اعمال اصلاحیهها باید در اولویت قرار گیرد.
PHP2Shell چیست و چرا باید آن را جدی گرفت؟
PHP یکی از زبانهای برنامهنویسی پرکاربرد در توسعه وب است و در بسیاری از وبسایتها، سامانههای مدیریت محتوا، فروشگاههای اینترنتی و برنامههای سازمانی مورد استفاده قرار میگیرد.
با وجود تفاوت میان محیطهای اجرایی و پیکربندیهای مختلف، آسیبپذیریهای سطح زبان یا مؤلفههای وابسته به آن میتوانند طیف گستردهای از برنامهها را در معرض خطر قرار دهند.
اصطلاح PHP2Shell در گزارشهای مربوط به دو آسیبپذیری مورد بحث استفاده شده است. بخش مهمی از خطر این نقصها، امکان اجرای کد از راه دور (Remote Code Execution یا RCE) بدون نیاز به احراز هویت در شرایط آسیبپذیر است.
اجرای کد از راه دور یکی از جدیترین انواع آسیبپذیریهای نرمافزاری محسوب میشود. در چنین شرایطی، مهاجم ممکن است بتواند دستورات یا کد دلخواه خود را در محیط اجرای برنامه آسیبپذیر اجرا کند.
پیامد نهایی به سطح دسترسی فرایند، محدودیتهای محیط اجرا، تنظیمات سیستمعامل و سایر کنترلهای امنیتی بستگی دارد. به همین دلیل، نباید هر آسیبپذیری RCE را معادل دسترسی خودکار به حساب مدیر سیستم یا کاربر ریشه دانست؛ اما چنین نقصی میتواند نقطه شروع یک نفوذ جدی باشد.
جزئیات دو آسیبپذیری بحرانی PHP2Shell
۱. آسیبپذیری CVE-2026-109618
این آسیبپذیری به نوعی فساد حافظه ناشی از وضعیت Out-of-Memory مربوط است؛ شرایطی که در آن مدیریت حافظه در برنامه میتواند به وضعیت ناامن منجر شود.
در صورت فراهم بودن شرایط بهرهبرداری، این نقص امکان اجرای کد از راه دور بدون احراز هویت را ایجاد میکند.
شناسه این آسیبپذیری:
CVE-2026-109618
امتیاز گزارششده:
CVSS 9.2 / 10
فساد حافظه از دسته ضعفهایی است که ممکن است آثار متفاوتی داشته باشد؛ از اختلال در اجرای برنامه گرفته تا امکان کنترل جریان اجرا و اجرای کد مخرب. نتیجه نهایی به جزئیات پیادهسازی و شرایط محیط بستگی دارد.
۲. آسیبپذیری CVE-2026-109619
دومین آسیبپذیری به باقی ماندن وضعیت داخلی درخواست (Stale Internal Request-State) مربوط است.
مدیریت نادرست یا باقی ماندن وضعیت داخلی درخواست میتواند در شرایط مشخص باعث رفتار ناامن در برنامه شود. در این مورد، آسیبپذیری گزارششده قابلیت اجرای کد از راه دور بدون احراز هویت را دارد.
شناسه این آسیبپذیری:
CVE-2026-109619
امتیاز گزارششده:
CVSS 9.2 / 10
این دو نقص از نظر ماهیت فنی یکسان نیستند؛ بنابراین، شناسایی و اصلاح هر دو باید بر اساس اطلاعیههای رسمی و وضعیت نسخه نرمافزار انجام شود.
چه چیزی در خبر جدید است؟
پیش از انتشار این خبر، درباره آسیبپذیریهای PHP2Shell، اصلاحیههای امنیتی و تلاشهای احتمالی برای بهرهبرداری گزارشهایی منتشر شده بود. اتفاق جدید، تأیید بهرهبرداری فعال توسط CISA و اضافه شدن هر دو شناسه به فهرست KEV است.
بر اساس گزارش The Hacker News، پژوهشگر امنیتی Adel Karimi در تاریخ ۲۴ اکتبر ۲۰۲۶، اجرای موفق کد از راه دور را در سامانههای Honeypot تأیید کرد.
در این بررسی، شواهدی از افشای اطلاعات حافظه و استفاده از یک نشانی تابع بهدستآمده از این اطلاعات در مرحله اجرای بعدی مشاهده شد. این شواهد فراتر از مشاهده صرف یک توقف برنامه یا اجرای یک فرایند مشکوک بود.
بااینحال، پژوهشگر تصریح کرده است که زنجیره بهرهبرداری در یک پیکربندی مشخص و مساعد، شامل اجرای تککارگره mod_php، مشاهده شده است. بنابراین، این نتیجه را نباید بهعنوان اثبات قابلیت بهرهبرداری یکسان در تمام نسخهها، برنامهها و پیکربندیهای PHP تفسیر کرد.
نکته مهم دیگر اینکه تأیید بهرهبرداری در Honeypot به معنای اثبات نفوذ به تمام سامانههای آسیبپذیر نیست. مدیران سرور همچنان باید وضعیت محیط خود را بررسی کنند و در صورت وجود نشانههای مشکوک، فرایند پاسخ به رخداد را آغاز کنند.
چند سرویس در معرض خطر قرار دارند؟
طبق گزارش The Hacker News، برآوردهای منتشرشده از سوی Censys نشان میدهد بیش از ۳۲٫۵۱ میلیون سرویس PHP ممکن است همچنان نسخههای تحت تأثیر را اجرا کنند.
این رقم نشاندهنده گستردگی احتمالی سطح مواجهه است؛ نه تعداد سامانههایی که نفوذ به آنها اثبات شده باشد.
همچنین، وجود یک سرویس PHP در معرض اینترنت بهتنهایی اثبات نمیکند که آن سرویس از نسخه آسیبپذیر استفاده میکند یا شرایط لازم برای بهرهبرداری از آن فراهم است.
برای تعیین میزان ریسک واقعی، باید نسخه دقیق PHP، نوع بسته نصبشده، قابلیتهای فعال، شرایط دسترسی و اصلاحیههای اعمالشده بررسی شوند.
بااینحال، گستردگی استفاده از PHP باعث میشود چنین هشدارهایی برای شرکتهای میزبانی وب، مدیران سامانههای سازمانی و توسعهدهندگان اهمیت ویژهای داشته باشند.
کدام نسخههای PHP اصلاح شدهاند؟
بر اساس اطلاعیههای منتشرشده، آسیبپذیریهای PHP2Shell در نسخههای زیر اصلاح شدهاند:
| شاخه PHP | نسخه اصلاحشده |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
این نسخهها در تاریخ ۲۱ اکتبر ۲۰۲۶ منتشر شدهاند.
توجه: جدول بالا مربوط به اصلاحیههای PHP2Shell است. بستههای رسمی PHP برای ویندوز در تاریخ ۲۶ اکتبر نیز با شمارههای ساخت جدیدتر، شامل پسوند -1، برای رفع آسیبپذیری جداگانه Brotli با شناسه CVE-2026-111497 منتشر شدهاند. این اصلاحیه دوم را نباید با دو نقص PHP2Shell اشتباه گرفت.
مدیران سیستم باید اطلاعیه رسمی PHP و روش توزیع بسته مورد استفاده خود را بررسی کنند؛ زیرا نسخههای موجود در مخازن توزیعهای لینوکسی، بستههای سفارشی و نسخههای ارائهشده توسط شرکتهای میزبانی ممکن است از فرایند انتشار متفاوتی پیروی کنند.
منبع رسمی دریافت PHP:
https://www.php.net/downloads.php
اطلاعیهها و بستههای رسمی ویندوز:
https://windows.php.net/download/
چرا قرار گرفتن در فهرست KEV اهمیت دارد؟
فهرست Known Exploited Vulnerabilities توسط CISA نگهداری میشود و آسیبپذیریهایی را ثبت میکند که شواهدی از بهرهبرداری واقعی از آنها وجود دارد.
قرار گرفتن یک آسیبپذیری در این فهرست، علامت مهمی برای تیمهای امنیتی است؛ زیرا نشان میدهد نقص موردنظر باید با توجه به شرایط محیط و احتمال بهرهبرداری، جدیتر از یک هشدار نظری ارزیابی شود.
CISA برای نهادهای دولتی فدرال آمریکا مهلت ۲۹ اکتبر ۲۰۲۶ را جهت اعمال اصلاحیههای این دو آسیبپذیری اعلام کرده است.
این مهلت یک الزام مشخص برای نهادهای مشمول دستورالعملهای مربوطه است و به این معنا نیست که سایر سازمانها میتوانند تا آن تاریخ بدون بررسی یا اقدام امنیتی صبر کنند.
فهرست رسمی KEV:
https://www.cisa.gov/known-exploited-vulnerabilities-catalog
راهکارهای پیشنهادی برای مدیران سرور
با توجه به تأیید بهرهبرداری فعال، توصیه میشود اقدامات زیر با اولویت بالا انجام شوند.
۱. نسخه PHP را در تمام محیطها بررسی کنید
بررسی را به یک وبسرور یا یک وبسایت محدود نکنید. محیطهای تولید، آزمایش، سرورهای داخلی و سرویسهایی را که از PHP استفاده میکنند نیز در فهرست ارزیابی قرار دهید.
در لینوکس، دستور زیر نسخه PHP مربوط به CLI را نمایش میدهد:
php -v
اما توجه داشته باشید که نسخه CLI لزوماً با نسخه مورد استفاده وبسرور یکسان نیست. اگر چند نسخه PHP نصب شده باشد یا PHP از طریق PHP-FPM، کانتینر یا سرویس دیگری اجرا شود، باید نسخه فعال همان محیط نیز بررسی شود.
۲. اصلاحیه رسمی را نصب کنید
در صورت استفاده از نسخه آسیبپذیر، نسخه اصلاحشده متناسب با شاخه نرمافزار و روش نصب خود را دریافت کنید.
در محیطهای عملیاتی، قبل از ارتقا از تنظیمات و اطلاعات ضروری نسخه پشتیبان تهیه کنید و سازگاری برنامهها و افزونهها را بسنجید. پس از بهروزرسانی نیز مطمئن شوید فرایندهای فعال از نسخه اصلاحشده استفاده میکنند.
۳. اگر بهروزرسانی فوری ممکن نیست، سطح دسترسی را محدود کنید
راهکارهای موقت باید بر اساس معماری برنامه انتخاب شوند. محدود کردن دسترسی شبکه به سرویسهای غیرضروری، کاهش سطح دسترسی حساب اجرای PHP و جداسازی برنامه از سایر سرویسهای حساس میتواند پیامد احتمالی یک بهرهبرداری موفق را کاهش دهد.
این اقدامات جایگزین نصب اصلاحیه نیستند. همچنین، محدود کردن دسترسی شبکه بهتنهایی لزوماً آسیبپذیری را برطرف نمیکند؛ بهویژه اگر برنامه همچنان از مسیر دیگری قابل دسترسی باشد.
۴. لاگها و فرایندهای مشکوک را بررسی کنید
در صورت وجود احتمال بهرهبرداری، لاگهای وبسرور، PHP-FPM، سیستمعامل و ابزارهای تشخیص نفوذ را بررسی کنید.
مواردی مانند اجرای غیرمنتظره فرایندهای فرزند توسط سرویس وب، درخواستهای غیرعادی، تغییر فایلهای برنامه، ایجاد حسابهای ناشناس یا ارتباطات خروجی مشکوک باید با توجه به زمینه عملیاتی بررسی شوند.
وجود یک نشانه بهتنهایی اثبات نفوذ نیست؛ اما در کنار شواهد دیگر میتواند برای شروع بررسی رخداد کافی باشد.
اگر شواهد معتبر از اجرای کد غیرمجاز مشاهده شد، صرفاً به نصب وصله اکتفا نکنید. لازم است دامنه رخداد، دسترسیهای احتمالی مهاجم و احتمال سرقت اطلاعات یا ماندگاری در سیستم نیز بررسی شود.
۵. وضعیت امنیتی را دوباره ارزیابی کنید
پس از اعمال اصلاحیه، نسخه فعال PHP را تأیید کنید، سرویسهای لازم را مطابق معماری محیط راهاندازی مجدد کنید و در صورت امکان از اسکن مجدد آسیبپذیری استفاده کنید.
همچنین، اگر از چندین وبسایت یا محیط میزبانی استفاده میکنید، بهتر است وضعیت اصلاحیه برای هر دارایی بهصورت جداگانه ثبت شود تا سرور یا برنامهای از قلم نیفتد.
جمعبندی؛ زمان بررسی سرورهای PHP فرا رسیده است
تأیید بهرهبرداری فعال از دو آسیبپذیری PHP2Shell توسط CISA، اهمیت این نقصها را افزایش داده است. دو شناسه CVE-2026-109618 و CVE-2026-109619 با امتیاز CVSS برابر ۹٫۲، قابلیت اجرای کد از راه دور بدون احراز هویت را در شرایط آسیبپذیر فراهم میکنند.
شواهد گزارششده از سامانههای Honeypot نشان میدهد که دستکم یک زنجیره بهرهبرداری موفق در پیکربندی مشخصی مشاهده شده است؛ بااینحال، این موضوع به معنای نفوذ اثباتشده به تمام سرورهای آسیبپذیر نیست.
برای مدیران سرور و توسعهدهندگان، بهترین اقدام، شناسایی نسخههای تحت تأثیر، نصب اصلاحیههای رسمی، محدود کردن سطح دسترسی و بررسی نشانههای احتمالی بهرهبرداری است.
در امنیت سایبری، فاصله میان انتشار یک اصلاحیه و اعمال آن روی تمام سامانهها میتواند فرصت مهمی برای مهاجمان ایجاد کند. مدیریت منظم آسیبپذیریها و پیگیری هشدارهای معتبر، از مهمترین اقدامات برای کاهش این فاصله است.
منابع
۱. The Hacker News — CISA Confirms Active Exploitation of Two PHP2Shell Flaws Enabling Remote Code Execution
https://thehackernews.com/2026/10/cisa-confirms-active-exploitation-of.html
۲. CISA — Known Exploited Vulnerabilities Catalog
https://www.cisa.gov/known-exploited-vulnerabilities-catalog
۳. PHP — وبسایت رسمی و اطلاعات انتشار نسخهها
۴. PHP for Windows — دریافت بستههای رسمی ویندوز
https://windows.php.net/download/
این مقاله بر اساس گزارش The Hacker News و منابع رسمی مرتبط بازنویسی شده است. وضعیت نسخههای نصبشده و اصلاحیهها را پیش از تصمیمگیری عملیاتی از منبع رسمی همان بسته بررسی کنید.
دیدگاهتان را بنویسید
برای نوشتن دیدگاه باید وارد بشوید.