امنیت آبان ۱۴۰۵

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

بنا بر گزارش The Hacker News، مهاجمان پس از سوءاستفاده از دو آسیب‌پذیری با شناسه‌های CVE-2026-109618 و CVE-2026-109619 در مرحله‌ی بعد از نفوذ از پلتفرم‌های عامل‌محور (Agentic) هوش مصنوعی استفاده کرده‌اند. در موردی که این گزارش شرح می‌دهد، هدف یک نهاد دولتی در اروپا بوده است. طبق همین گزارش، مهاجمان ظرف دو ساعت از نفوذ اولیه به هش گذرواژه‌ها و اطلاعات مرتبط با احراز هویت چندعاملی دست یافته‌اند. نکته‌ی عملی این است که فاصله‌ی «نفوذ» تا «خسارت جدی» ممکن است از چند روز به چند ساعت برسد.

ماجرا به همین دو ضعف ختم نمی‌شود. The Register و BleepingComputer گزارش داده‌اند که ضعف سومی هم وجود دارد: یک آسیب‌پذیری اجرای کد از راه دور که سامانه‌هایی با تنظیمات غیرپیش‌فرض را تحت تأثیر قرار می‌دهد. برای این ضعف وصله‌ی اضطراری منتشر نمی‌شود و تیم امنیتی PHP فقط راهکارهای کاهش ریسک را اعلام کرده است. پس این بار جمله‌ی «سرور را به‌روز کنید» به‌تنهایی پاسخ کافی نیست.

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

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

دو پرسش بعدی درباره‌ی اقدام و پایش است. چهارم، برای سامانه‌هایی که ممکن است تحت تأثیر باشند، چه راهکار موقتی برای کاهش ریسک پیاده‌سازی شده، چه کسی آن را تأیید کرده و تا چه تاریخی بازبینی می‌شود؟ پنجم، چه کسی لاگ‌ها را زیر نظر دارد؟ لاگ‌ها باید جایی خارج از همان سرور هم نگهداری شوند و برای رفتارهای غیرعادی، مثل ورود در ساعت‌های نامعمول یا اجرای فرمان‌های ناآشنا، هشدار تعریف شده باشد. اگر این کار با شریک MSP است، قرارداد خدمات را هم بررسی کنید که این پایش را صریحاً پوشش می‌دهد.

لازم نیست این هفته دچار وحشت شوید، اما بهتر است از تیم فنی یا شریک MSP خود یک پاسخ مکتوب و کوتاه بخواهید: فهرست سامانه‌ها، نسخه‌ها، وضعیت تنظیمات و اقدام‌های موقت. در کنار آن بپرسید اگر نشانه‌ای از نفوذ دیده شود، تغییر گذرواژه‌ها و کلیدها، بازیابی از پشتیبان سالم و اطلاع‌رسانی داخلی به چه ترتیبی انجام می‌شود. وجود همین پاسخ‌ها، پیش از هر حادثه‌ای، بیشترین تفاوت را در سرعت واکنش ایجاد می‌کند.

شروع همکاری