PHP آسیب‌پذیری پرخطر سطح اینترنت را آشکار می‌کند؛ چگونه نقطه ضعف «غیرزنجیره‌ای» وب۳ را برطرف کنیم؟

عنوان اصلی: «PHP آسیب‌پذیری بحرانی سطح اینترنت را آشکار می‌کند: چگونه نقطه ضعف غیرزنجیره‌ای وب۳ را رفع کنیم؟» نویسنده اصلی: تیم امنیتی SlowMist

اتفاق افتاده چه؟

در ۲۱ اکتبر، پروژه PHP به‌صورت اضطراری بروزرسانی امنیتی برای رفع دو آسیب‌پذیری بحرانی CVE-2026-109618 و CVE-2026-109619 منتشر کرد که می‌توانند منجر به اجرای رمز دور از طریق اینترنت بدون احراز هویت شوند (RCE)؛ هر دو با امتیاز CVSS نسخه ۴٫۰ برابر ۹٫۲ ارزیابی شده‌اند. PHP به‌طور رسمی اعلام کرد که پیش از رفع، تمام نصب‌های PHP که خدمات وب خارجی ارائه می‌دهند، قابلیت تحت تأثیر قرار گرفتن دارند.

در ۲۰ اکتبر، جزئیات آسیب‌پذیری پیش از افشای رسمی نشت کرد و هنوز هیچ وصله‌ای منتشر نشده بود. بنابراین تیم امنیتی PHP زمان انتشار اضطراری را از تاریخ اولیهٔ ۲۲ اکتبر به ۲۱ اکتبر ساعت ۱۴:۰۰ (UTC) تغییر داد.

نگران‌کننده‌تر این است که حملات احتمالاً پیش از افشا رخ داده‌اند. تیم اطلاعات تهدیدهای آمازون گزارش داد که در ۱۷ اکتبر، تلاش‌های بهره‌برداری از php2shell را در شبکه سرگرمی (honeypot) MadPot خود مشاهده کرده است — چهار روز پیش از افشا.

SlowMist نیز بلافاصله پس از اطلاعیه پیش‌اخطار رسمی PHP، یادآوری‌ها و توصیه‌های امنیتی صادر کرد.

دو آسیب‌پذیری چه هستند؟

CVE-2026-109618 (خرابی حافظه ناشی از خطای OOM): هنگامی که PHP از حافظه کمبود دارد، جریان پردازش متوقف می‌شود و داده‌های در دست اجرا تنها نیمه‌آماده هستند. در مرحله پاک‌سازی، PHP این داده‌های نیمه‌کامل را به‌عنوان داده‌های کامل تلقی می‌کند و منجر به خرابی حافظه می‌شود.

CVE-2026-109619 (وضعیت سراسری منسوخ‌شده): پس از پردازش یک درخواست، حافظه آزاد می‌شود اما وضعیت مرتبط «همچنان در جای خود باقی می‌ماند». وقتی همان فرآیند کارگر درخواست بعدی را پردازش می‌کند، ممکن است قبل از مقداردهی اولیهٔ عادی از این وضعیت منسوخ‌شده استفاده کند. مقامات تأیید کرده‌اند که این آسیب‌پذیری قابل استفاده برای حمله به PHP-FPM و دستیابی به اجرای رمز از راه دور است.

از منظر مسیر حمله، خطر این نوع آسیب‌پذیری در این است که مهاجمان نیازی به داشتن حساب سایت یا عبور از لایه کسب‌وکار (مانند ورود، دسترسی یا تأیید کلید API) ندارند. ارسال یک درخواست طراحی‌شده به یک برنامه PHP که در اینترنت عمومی قابل دسترسی است، ممکن است اجرای دلخواه کد را با مجوزهای فرآیند سرویس وب فراهم کند.

دامنه تأثیرگذاری: تمام نسخه‌های PHP از ۵٫۴ تا ۸٫۵٫۱۱ تحت تأثیر قرار گرفته‌اند. نسخه‌های اصلاح‌شده عبارتند از: ۸٫۵٫۱۲، ۸٫۴٫۲۷، ۸٫۳٫۳۶ و ۸٫۲٫۳۵. نسخه‌های PHP ۸٫۱ و قدیمی‌تر از آن از پشتیبانی عادی upstream خارج شده‌اند؛ بنابراین انتظار وصله از طریق کانال‌های عادی وجود ندارد و باید به نسخه‌های پشتیبانی‌شده مهاجرت کرد.

چرا کل جهان نگران شده است؟

زیرا PHP بسیار فراگیر است. بر اساس آمار W3Techs، در میان وب‌سایت‌هایی که زبان سمت سرور آن‌ها قابل شناسایی است، ۶۹٫۳٪ از آن‌ها از PHP استفاده می‌کنند. سیستم‌های آشنا مانند وردپرس، ووکامرس و مگنتو همگی در پس‌زمینه روی آن اجرا می‌شوند.

واکنش کشورهای مختلف نیز این مسئله را نشان می‌دهد — مرکز امنیت سایبری ملی هلند به‌صورت پیشگیرانه وب‌سایت‌ها را خاموش کرد؛ دفتر ریاست جمهوری کره جنوبی جلسه اضطراری امنیت سایبری تشکیل داد و دولت سطح هشدار امنیت سایبری را افزایش داد.

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

تأثیر بر وب۳

این مسئله‌ای نیست که صرفاً عملیات و نگهداری وب‌سایت‌های سنتی را در بر گیرد. در Web3، حتی اگر قراردادهای زنجیره‌ای (on-chain) آسیب‌پذیری نداشته باشند، تعداد زیادی «مؤلفه غیرزنجیره‌ای» (off-chain) اطراف اجرای قراردادها — از جمله صفحات پیش‌رو، APIها، کیف‌پول‌های سپرده‌دار، سرویس‌های امضا، صفحات ادعای ایردراپ، بک‌اند عملیاتی و سرویس‌های داده — اغلب با PHP (مثل وردپرس، ووکامرس، مگنتو و غیره) ساخته می‌شوند. عدم وجود آسیب‌پذیری در خود قراردادها به معنای امن بودن این مؤلفه‌ها نیست.

بر اساس آمار سیستم اطلاعات تهدید MistEye تحت پوشش SlowMist، از میان ۱۴۸۸ دامنه مرتبط با صنعت رمزارز که اسکن شدند، ۷۹۳ دامنه حاوی امضای مستقیم PHP بودند که حدود ۵۳٫۳٪ را تشکیل می‌دهد. باید تأکید شود که این تنها نشان‌دهنده استفاده از PHP است و لزوماً به معنای وجود آسیب‌پذیری یا هک شدن این وب‌سایت‌ها نیست.

۱. سوی پلتفرم: چند مسیر ریسک متداول

دستکاری صفحه پیش‌رو برای فریب کاربران جهت امضای مخرب.

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

نشت کلیدها و اعتبارنامه‌ها.

پس از هک شدن سرور، مهاجمان ممکن است فایل‌های پیکربندی، رمزهای دسترسی پایگاه داده، توکن‌های API و متغیرهای محیطی را بخوانند. اگر بک‌اند از PHP برای اتصال به سرویس‌های RPC گره یا کیف‌پول گرم استفاده کند، نشت توکن‌های API یا توکن‌های جلسه می‌تواند منجر به انتقال دارایی‌های کیف‌پول گرم یا سوءاستفاده از مجوزهای امضا شود.

تسلط بر بک‌اند و API.

پلتفرم‌های معاملاتی، بازارهای NFT، پل‌های بین‌زنجیره‌ای، دروازه‌های پرداخت و ارائه‌دهندگان سرویس‌های گره معمولاً بک‌اند عملیاتی دارند، همچنین رابط‌های احراز هویت (KYC)، کنترل ریسک، تخصیص آدرس‌های سپرده‌گذاری، بررسی برداشت‌ها و سیستم‌های تیکت‌زنی. پس از کسب دسترسی، مهاجمان ممکن است پیکربندی‌ها را دستکاری کنند، داده‌های کاربران را بدزدند، حساب‌های با دسترسی بالا ایجاد کنند یا فرآیندهای کسب‌وکار را دور بزنند.

حرکت جانبی از طریق زنجیره تأمین.

سطح دسترسی فرآیند PHP معمولاً برابر با بالاترین سطح دسترسی روی سرور نیست، اما اگر بتواند کلیدهای CI/CD، سوکت‌های اجرای کانتینر، اعتبارنامه‌های پایگاه داده یا توکن‌های دسترسی به ابر را بخواند، دامنه حمله ممکن است از یک گره وب منفرد به پایگاه‌های داده، سیستم‌های ساخت یا حتی کل حساب تولیدی گسترش یابد.

افزونه‌های پرداخت و سرویس‌های شخص ثالث.

مشخص است که راهکارهای پرداخت رمزارزی مانند Binance Pay، Crypto.com Pay، BitPay، CoinGate و CoinPayments همگی افزونه‌هایی برای ووکامرس دارند و سرورهای بدون پچ، ریسک قابل توجهی ایجاد می‌کنند. سرویس‌های شخص ثالث مانند سرویس‌های RPC، مرورگرهای بلاک و پلتفرم‌های تحلیل داده نیز در صورت اجرای بک‌اند یا سیستم‌های عملیاتی خود بر روی محیط‌های آسیب‌پذیر PHP می‌توانند نقطه ورود حمله شوند. البته گره‌های RPC، قراردادهای هوشمند، مرورگرهای بلاک و خود کیف‌پول‌ها به‌طور ذاتی وابسته به PHP نیستند؛ این وابستگی به پشته فناوری خاص هر محصول بستگی دارد.

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

۲. کاربران عادی: آیا باید سکه‌های خود را برداشت کنید؟

نیازی نیست.

دلیل ساده است:

این آسیب‌پذیری فقط بر محیط‌های سروری که شرایط خاصی را داشته باشند تأثیر می‌گذارد؛ نه اینکه به معنای ریسک قرار گرفتن کیف‌پول‌های تمام کاربران باشد.

مرور یک وب‌سایت و اتصال کیف‌پول، برابر با نشت کلید خصوصی نیست. این آسیب‌پذیری به‌خودی‌خود نمی‌تواند کیف‌پول‌ها یا امضاهای کاربران را بشکند.

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

اگر یک پروژه به‌صورت رسمی تأیید کند که وب‌سایت یا بک‌اند آن مورد نفوذ قرار گرفته است، کاربران باید بر اساس تأثیر واقعی اعلام‌شده تصمیم بگیرند که آیا تعاملات خود را موقتاً متوقف کنند، تراکنش‌های غیرعادی را بررسی کنند و مجوزهای مشکوک را لغو نمایند. در صورت تأیید نشت کلیدهای خصوصی امضا یا عبارات اولیه (seed phrases)، این حادثه باید به‌عنوان نشت کلید مورد رسیدگی جدی قرار گیرد — تغییر رمزهای عبور یا قطع اتصال از وب‌سایت کافی نیست. کاربران ربات‌های معاملاتی، ابزارهای اجرای خودکار یا سرویس‌های ارائه‌شده در ابر نیز باید توجه کنند که آیا سرویس‌های مربوطه نسخه‌های تحت تأثیر یا اعلان‌های تغییر اعتبارها را منتشر کرده‌اند.

روش پاسخ‌دهی

۱. پلتفرم‌ها و تیم‌های پروژه:

مرحله اول: موجودی دارایی‌ها را بررسی کنید و در اسرع وقت به‌روزرسانی انجام دهید

تمام دارایی‌های PHP در شبکه‌های عمومی و داخلی را شمارش کنید: سرورها، تصاویر کانتینری، بارهای کاری Kubernetes، سیستم‌های مدیریت محتوا (CMS) قدیمی، بک‌اند‌های مدیریتی، محیط‌های میزبانی‌شده توسط شرکا، افزونه‌های شخص ثالث و سرویس‌های مدیریت‌شده. امضاهای فنی تنها می‌توانند به‌عنوان نشانه‌ای عمل کنند و نمی‌توانند مستقیماً به‌عنوان نتیجه‌گیری «آسیب‌پذیری تأییدشده» در نظر گرفته شوند.

به نسخه‌های ۸.۲.۳۵ / ۸.۳.۳۶ / ۸.۴.۲۷ / ۸.۵.۱۲ ارتقا دهید یا از رفع‌آسیب‌پذیری‌های معادل ارائه‌شده توسط توزیع‌کنندگان، ارائه‌دهندگان ابری یا سرویس‌دهندگان مدیریت‌شده استفاده کنید. برای کسانی که از نسخه‌های ۸.۱ و قدیمی‌تر استفاده می‌کنند، درخواست نسخه بازگردانی‌شده (backport) از تأمین‌کننده یا مهاجرت فوری ضروری است. هیچ‌یک از دلایل «محیط قدیمی پایدار است» یا «برنامه به‌ندرت به‌روزرسانی می‌شود» نمی‌توانند خطر این آسیب‌پذیری را کاهش دهند.

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

مرحله دوم: اگر در حال حاضر نمی‌توانید ارتقا دهید، چه کاری انجام دهید

ابتدا سطح مواجهه را کاهش دهید تا زمان بخرید، اما این کار جایگزین رفع آسیب‌پذیری نمی‌شود:

برنامه‌های PHP قابل دسترسی از اینترنت عمومی را جدا کنید یا در لایه ورودی (ingress) احراز هویت شبکه‌ای و کنترل دسترسی اعمال نمایید.

بارگذاری فایل‌های غیرضروری را غیرفعال کنید و درخواست‌های multipart/form-data غیرضروری را در لایه WAF یا سرور وب رد کنید.

برخی توصیه‌های امنیتی نیز شامل موارد زیر می‌شود: تنظیم memory_limit=-1، غیرفعال کردن session.upload_progress.enabled و در PHP 8.5، غیرفعال کردن اضافی fatal_error_backtraces. این تنظیمات ممکن است تأثیرات جانبی بر کسب‌وکار و در دسترس‌بودن داشته باشند؛ بنابراین ابتدا آن‌ها را تست کنید و پس از هر تغییر تمام فرآیندهای کارگر PHP را راه‌اندازی مجدد نمایید.

مرحله سوم: بررسی نفوذ و تغییر اعتبارها

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

بدترین سناریو را در نظر بگیرید: برای سرورهایی که به‌موقع رفع نشده‌اند، تغییر کلیدهای API، کلیدهای جلسه، گواهی‌های TLS، رمزهای عبور پایگاه داده، توکن‌های دسترسی ابری، اعتبارهای CI/CD، کلیدهای RPC/API، رازهای webhook و توکن‌های شخص ثالث ضروری است و باید از سابقه استفاده غیرعادی نیز بررسی شود.

اگر نسخه نرم‌افزاری تأییدشده نفوذی در محیط نصب یا اجرا شده باشد، صرفاً ارتقا یا نصب مجدد کافی نیست تا از رفع خطر اطمینان حاصل شود؛ بلکه باید نشت اعتبارها و دروازه‌های پایدار نفوذ (persistence backdoors) نیز بررسی شوند و در صورت لزوم محیطی تمیز از نو ساخته شود.

مرحله چهارم: امن‌سازی صفحه کنترل دارایی‌ها

رفع آسیب‌پذیری PHP نباید تنها اقدام باشد. مهم‌تر اینکه اطمینان حاصل شود «یک ماشین وب نفوذی نمی‌تواند سیستم صندوق را به‌هم بریزد»:

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

سرویس‌های وب، سرویس‌های امضا، گره‌های بلاکچین، پایگاه‌های داده و سیستم‌های ساخت را در بخش‌های شبکه‌ای و مرزهای هویتی مجزا قرار دهید.

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

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

منابع ثابت وب‌سایت، بسته‌های جاوااسکریپت، پیکربندی‌های پروکسی معکوس، قوانین DNS/CDN و سرویس‌های ساخت تراکنش را بررسی کنید تا اطمینان حاصل شود هیچ اسکریپت مخربی درج یا جایگزین نشده است.

۲. کاربران عادی:

از مسیرهای رسمی وارد شوید: اخیراً سعی کنید به پلتفرم‌ها از طریق علاقه‌مندی‌ها یا کانال‌های رسمی دسترسی پیدا کنید و از هرگونه پیوندی که با عنوان «حادثه امنیتی» ارسال می‌شود، احتیاط نمایید.

تنها به دامنه و ظاهر صفحه تکیه نکنید: حتی برای دامنه‌های dApp آشنا، اسکریپت‌های صفحه، پارامترهای تراکنش و پیکربندی‌های RPC ممکن است از سوی مهاجمان در سمت سرور جایگزین شده باشند.

قبل از امضای هر تراکنش، همه موارد را به‌طور جداگانه تأیید کنید: آدرس گیرنده، زنجیره، مقدار تأیید، قرارداد فراخوانی‌شده و نتایج شبیه‌سازی تراکنش. به‌ویژه در مورد توابع approve و setApprovalForAll مراقب باشید و در مورد تأییدهای نامحدود احتیاط بیشتری داشته باشید.

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

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

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

نتیجه‌گیری نهایی

آسیب‌پذیری‌های اجرای رمز دور از طریق وب (مانند PHP2Shell) که لایه وب را نقض می‌کنند، می‌توانند نفوذ سنتی به سرورها را به سم‌افزایی رابط کاربری، جعل هویت، سوءاستفاده از مجوزهای امضا، ریسک کیف پول گرم و حتی حرکت جانبی در سطح زنجیره تأمین تبدیل کنند.

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

پیوند اصلی