نمای کلی اجرایی و اهمیت معماری

در ۲۰ اکتبر ۲۰۲۶، داکر ردیابی دو آسیب‌پذیری بحران‌ی را که به طور جمعی «PHP2Shell» نامیده می‌شوند — به‌ویژه تحت شناسه‌های CVE-2026-109618 و CVE-2026-109619 — آغاز کرد. این آسیب‌پذیری‌های با شدت بالا مستقیماً در هسته PHP قرار دارند و طیف وسیعی از بسته‌های PHP را از نسخه ۵.۴ به بعد تحت تأثیر قرار می‌دهند، از جمله شاخه‌های پشتیبانی‌نشده و پایان‌یافته (EOL) (نسخه‌های 5.x، 7.x، 8.0، 8.1) و همچنین شاخه‌های حال حاضر پشتیبانی‌شده (۸.۲ تا ۸.۵). در حالی که بردار آسیب‌پذیری در پیاده‌سازی زمان اجرای بالادستی PHP وجود دارد تا موتور ارکستراسیون هسته یا صفحه کنترل داکر، پیامدهای معماری برای محیط‌های کانتینری عمیق است. اکوسیستم‌های داکری که بر روی ریزخدمات مبتنی بر PHP، برنامه‌های یکپارچه (Monolithic)، یا بیلدهای سفارشی کانتینر متکی هستند، در صورت عدم اعمال اصلاحیه، اساساً در معرض بردارهای احتمالی اجرای کد از راه دور (RCE) قرار دارند.

در واکنش به پچ‌های بالادستی منتشر شده توسط بنیاد PHP، داکر به سرعت برای محافظت از پایگاه کاربری خود اقدام کرد. هم تصاویر رسمی داکر و هم تصاویر سخت‌سازی‌شده داکر (DHI) میزبانی‌شده در Docker Hub و کپی‌شده در Amazon ECR، به‌طور کامل در یک بازه زمانی سریع ۲۴ ساعته بازکامپایل، تست و به محیط پروداکشن ارسال شدند. این تحلیل انتشار، ضرورت حیاتی این به‌روزرسانی‌ها را برجسته می‌کند و ضمن بررسی نقص‌های زیربنایی مدیریت حافظه، تغییرات دقیق تگ‌های ایمیج را تشریح کرده و یک طرح مهاجرت معتبر برای تیم‌های مهندسی سازمانی که بارهای کاری ابری PHP را در مقیاس وسیع اداره می‌کنند، ایجاد می‌کند.

بهبودهای کلیدی و ارگونومی توسعه‌دهنده

پچ‌های امنیتی بالادستی — که به نسخه‌های PHP 8.5.12، 8.4.27، 8.3.36 و 8.2.35 ختم می‌شوند — نقص‌های عمیق مدیریت حافظه را در مفسر PHP مستقیماً حل می‌کنند. به‌طور خاص، CVE-2026-109618 به سناریوی مرگبار اتمام حافظه می‌پردازد که در آن محدودیت‌های حافظه در وسط درخواست نقض شده و رشته اجرا متوقف می‌شود. مشخص شد که برخی مسیرهای کدهای اجرایی، بافرهای حافظه تخصیص‌یافته را قبل از توالی پاکسازی داخلی موتور، مقداردهی اولیه نشده باقی می‌گذارند و به عملیات خواندن بعدی اجازه می‌دهند تا داده‌های حساس زمان اجرا را برداشت کنند یا جریان اجرا را دستکاری کنند. همزمان، CVE-2026-109619 یک آسیب‌پذیری استفاده پس از آزاد شدن (Use-After-Free) را هدف قرار می‌دهد که در آن متغیرهای حالت مفسر داخلی، اشاره‌گرهای آویزان (Dangling Pointers) را به بلوک‌های حافظه‌ای که قبلاً توسط مدیر حافظه پس‌گرفته شده‌اند، حفظ می‌کنند و یک مسیر قطعی برای محول‌های مخرب ایجاد می‌کنند تا اجرای کد از راه دور را فعال کنند.

از منظر ارگونومی توسعه‌دهنده و امنیت زنجیره تأمین، ادغام سریع این پچ‌ها توسط داکر، اصطکاک عملیاتی را به حداقل می‌رساند. توسعه‌دهندگان نیازی به بازنویسی منطق تجاری برنامه یا بازسازی معماری کد منبع ندارند؛ بلکه کاهش خطر صرفاً بر پایه تغییرناپذیری ایمیج پایه و ترویج سریع تگ استوار است. با اطمینان از اینکه تصاویر رسمی داکر و تصاویر سخت‌سازی‌شده داکر رانتایم‌های سخت‌سازی‌شده PHP را به‌طور بومی در خود جای داده‌اند، تیم‌های توسعه می‌توانند به سادگی با به‌روزرسانی اعلامیه‌های مانیفست خود و راه‌اندازی خطوط لوله بازسازی ادغام پیوسته/استقرار پیوسته (CI/CD)، به‌روزرسانی‌های امنیتی را یکپارچه دریافت کنند.

ماتریس مقایسه معماری

تغییرات مخرب و نکات هشداردهنده مهاجرت

این به‌روزرسانی امنیتی با کدهای برنامه قبلی که روی شاخه‌های پشتیبانی‌شده PHP (۸.۲، ۸.۳، ۸.۴ و ۸.۵) اجرا می‌شوند، کاملاً سازگار با نسخه‌های قبلی است. هیچ تغییر نحوی مخرب، منسوخ‌سازی توابع کتابخانه استاندارد، یا تغییری در دستورالعمل‌های پیکربندی افزونه (php.ini) توسط این پچ‌های بالادستی ایجاد نشده است. با این حال، تیم‌های مهندسی که برنامه‌ها را روی شاخه‌های پایان‌عمر (EOL) PHP (5.x، 7.x، 8.0، 8.1) نگهداری می‌کنند، با یک هشدار شدید معماری روبرو هستند: نگه‌دارندگان بالادستی هیچ پچی برای این نسخه‌های قدیمی صادر نکرده‌اند. در نتیجه، داکر نمی‌تواند تصاویر کانتینر امنی را برای شاخه‌های EOL ارائه دهد. سازمان‌هایی که نمی‌توانند کدهای برنامه خود را به یک نسخه پشتیبانی‌شده و پچ‌شده PHP ارتقا دهند، باید سیستم‌های خود را کاملاً ایزوله کنند یا با خطر بحران‌زا و کنترل‌نشده اجرای کد از راه دور روبرو شوند.

راهنمای گام‌به‌گام ارتقا

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

1. بازرسی تصویر پایه Dockerfile: فایل Dockerfile برنامه خود را پیدا کرده و دستور FROM فعلی را که به تگ‌های آسیب‌پذیر PHP اشاره دارد، شناسایی کنید.
2. به‌روزرسانی تگ‌های ایمیج: تگ را طوری تغییر دهید که مستقیماً به نسخه‌های تازه پچ‌شده اشاره کند (مثلاً انتقال از php:8.4.26-fpm به php:8.4.27-fpm یا معادل تصویر سخت‌سازی‌شده داکر شما).
3. بیلد مجدد و استقرار: دستور بیلد کانتینر خود را اجرا کرده و یک استقرار غلتان (Rolling Deployment) را در سراسر پلتفرم ارکستراسیون کانتینر خود پیاده‌سازی کنید.

# مثال پیکرب