به‌روزرسانی امنیتی PHP: ابتدا وصله، سپس بررسی اسرار و دسترسی‌ها

PHP در ۲۱ اکتبر ۲۰۲۶ نسخه‌های 8.5.12، 8.4.27، 8.3.36 و 8.2.35 را برای رفع CVE-2026-109618 و CVE-2026-109619 منتشر کرد؛ آسیب‌پذیری‌های بحرانی که می‌توانند اجرای کد از راه دور بدون احراز هویت را ممکن کنند. اعلامیهٔ رسمی نصب‌های پردازش‌کنندهٔ درخواست وب، از جمله PHP-FPM و Apache mod_php را در معرض خطر می‌داند. رفع کامل با به‌روزرسانی است؛ کاهش خطر موقت هم‌ارز آن نیست.

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

مشخص کنید چه چیزی واقعاً درخواست‌ها را پردازش می‌کند

وب‌سایت‌های عمومی، سرویس‌های داخلی، کانتینرها و حساب‌های میزبانی دارای PHP را فهرست کنید. نسخه و وضعیت وصلهٔ محیط پاسخ‌گوی وب را تأیید کنید؛ نسخهٔ خط فرمان ممکن است به نصب دیگری تعلق داشته باشد.

در میزبانی مدیریت‌شده، تأیید بستهٔ اعمال‌شده، سرویس مربوط و راه‌اندازی مجدد یا انتشار را بخواهید. توزیع‌ها ممکن است اصلاح را به نسخهٔ قدیمی بازگردانند؛ تأیید وصله بگیرید و فقط شمارهٔ نسخهٔ اصلی را ملاک ندانید. با بهره‌بردار بر اساس هشدارهای تیم PHP دامنه را بررسی کنید. صفحهٔ تشخیصی افشاکنندهٔ تنظیمات سرور منتشر نکنید.

مواجهه را محدود و محیط مورداعتماد را بازیابی کنید

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

بازهٔ مواجهه، لاگ وب و سیستم، فایل‌ها و فرایندهای غیرمنتظره و رخدادهای ممیزی ارائه‌دهندگان مرتبط را بررسی کنید. نبود هشدار یا لاگ ظاهراً عادی ثابت نمی‌کند میزبان دست‌نخورده است.

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

پیش از چرخش، اطلاعات ورود را ارزیابی کنید

اطلاعات قابل‌دسترسی فرایند آسیب‌دیده را فهرست کنید: تنظیم برنامه، متغیرهای محیطی، توکن استقرار، اطلاعات پایگاه داده و کلیدهای API. مجوز، دامنه و احتمال افشا را تعیین کنید. اعلامیه به‌تنهایی نشان نمی‌دهد همهٔ اطلاعات سازمان لو رفته‌اند.

برای موارد احتمالاً افشاشده، از دستگاه مدیریتی مطمئن، تعویض و ابطال را نزد صادرکننده هماهنگ کنید. جایگزین‌ها را در محیط بازسازی‌شده و مورداعتماد نصب و اتصال‌های قانونی را بررسی کنید. ترتیب را بر اساس سوءاستفادهٔ فعال، امکانات ارائه‌دهنده و وابستگی خدمات انتخاب کنید. وعدهٔ کار بی‌وقفه ندهید و کلید افشاشده را برای راحتی بی‌نهایت فعال نگذارید.

در صورت نیاز نشست‌ها و دسترسی بازیابی را بررسی و مسئول هر تغییر را ثبت کنید. خود اسرار را در تیکت یا لاگ رخداد نگذارید. OWASP

دسترسی اضطراری را پس از کار پایان دهید

به پاسخ‌دهندگان حساب جداگانه با حداقل مجوز و زمان پایان توافقی بدهید. پس از بازیابی، نقش‌های موقت، نشست‌ها، دسترسی استقرار و پیوندهای تحویل را بررسی کنید. دسترسی باقیماندهٔ غیرضروری را حذف و نتیجه را در سرویس مربوط تأیید کنید، نه صرفاً با اتکا به یادآور تقویم.

سه کنترل متفاوت را جدا نگه دارید

فقط پس از بازیابی اعتماد، موقت تحویل دهید

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

LOCK.PUB ابزار تحویل محدودی است: PHP را وصله نمی‌کند، دستگاه آلوده را تعمیر نمی‌کند، کلید ارائه‌دهنده را باطل نمی‌کند و کپی‌ها را پس نمی‌گیرد. جای مدیر اسرار، کنترل هویت یا پاسخ به رخداد را نمی‌گیرد.

پرسش‌های رایج

آیا نصب به‌روزرسانی PHP بررسی را تمام می‌کند؟

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

آیا انقضای یادداشت، کلید API داخلش را غیرفعال می‌کند؟

خیر. کلید را نزد ارائه‌دهنده باطل یا جایگزین کنید. اطلاعات کپی‌شده از پیوند تحویل‌دهندهٔ آن جداست.

مرتبط: اشتراک کلید API با مرزهای روشن.