اوپن‌ای‌آی ابزار بررسی آسیب‌پذیری php2shell را منتشر کرد؛ اما این ابزار فقط نسخه PHP را بررسی می‌کند

اوپن‌ای‌آی در ۲۱ اکتبر ابزار php2shell-checker را در گیت‌هاب منتشر کرد؛ ابزاری رایگان با مجوز Apache-2.0 که بررسی می‌کند آیا یک وب‌سایت در معرض آسیب‌پذیری php2shell قرار دارد یا خیر. این ابزار نسخه PHP را از سرآیندهای HTTP دریافت می‌کند یا در صورت اجرا روی سیستم محلی، خروجی دستور php -v را می‌خواند. سپس نسخه به‌دست‌آمده را با جدولی از آستانه‌های تعیین‌شده برای شاخه‌های مختلف PHP، از نسخه ۵.۴ تا ۸.۵، مقایسه می‌کند و یکی از سه نتیجه OK، VULNERABLE یا UNKNOWN را نمایش می‌دهد.

نام php2shell به دو نقص امنیتی با شناسه‌های CVE-2026-109618 و CVE-2026-109619 اشاره دارد؛ دو آسیب‌پذیری اجرای کد از راه دور (RCE) در PHP، زبانی که بخش بزرگی از وب بر پایه آن اجرا می‌شود. جزئیات این دو نقص و اقدامات لازم برای مقابله با آن‌ها را در مطلب دو آسیب‌پذیری اجرای کد از راه دور در PHP و اقدامات ضروری بررسی کرده‌ایم. این ابزار همچنین به‌صورت یک مهارت (Skill) برای Codex، دستیار برنامه‌نویسی اوپن‌ای‌آی، ارائه شده است. مهارت در اینجا به پوشه‌ای شامل دستورالعمل‌ها و اسکریپت‌هایی گفته می‌شود که عامل هوش مصنوعی هنگام نیاز بارگذاری می‌کند. شرکت سازنده ChatGPT در پیامی در ایکس این ابزار را معرفی کرد و از کاربران خواست Codex را به مخزن آن هدایت کنند.

ابزار را همین حالا امتحان کنید

این ابزار رایگان است و برای استفاده از آن نیازی به ثبت‌نام نیست. اجرای آن از طریق ترمینال به نصب Node.js و وارد کردن یک دستور نیاز دارد؛ اما برای استفاده از دو مهارت ارائه‌شده باید Codex را در اختیار داشته باشید. بهتر است ابزار را فقط روی وب‌سایت‌های خودتان یا سایت‌هایی اجرا کنید که مسئولیت نگهداری آن‌ها را بر عهده گرفته‌اید.

مشاهده مخزن php2shell-checker | مطالعه راهنمای پروژه

php2shell-checker چه کاری انجام می‌دهد و چگونه باید از آن استفاده کرد؟

این مخزن در ۲۱ اکتبر ایجاد شد و تا روز ۲۲ اکتبر، ۵۵۶ ستاره و ۴۴ انشعاب (Fork) در گیت‌هاب دریافت کرده بود. محتوای آن شامل اسکریپت phpcheck.js است که با Node.js اجرا می‌شود و به وابستگی خارجی نیاز ندارد. همچنین دو مهارت برای Codex در آن قرار دارد: phpcheck-url برای افرادی که فقط نشانی وب‌سایت را در اختیار دارند و phpcheck-server برای کسانی که به سرور دسترسی دارند. طبق راهنمای پروژه، برای نصب این دو مهارت کافی است از Codex بخواهید هر دو را از نشانی مخزن نصب کند. افرادی که از Codex استفاده نمی‌کنند، می‌توانند اسکریپت را مستقیماً اجرا کنند.

# بررسی یک وب‌سایت با استفاده از نشانی آن
node phpcheck.js "https://example.com"

# بررسی نسخه PHP خط فرمان در سیستم فعلی
node phpcheck.js --local

# دریافت خروجی مناسب برای پردازش با اسکریپت
node phpcheck.js "https://example.com" --json

نتیجه بررسی از طریق کد خروجی برنامه نیز مشخص می‌شود؛ قابلیتی که برای استفاده در اسکریپت‌ها در نظر گرفته شده است. همان‌طور که در فایل SKILL.md مربوط به مهارت phpcheck-url توضیح داده شده، کدهای خروجی ۱ و ۳ به معنای خطای اجرای برنامه نیستند، بلکه نتیجه بررسی را مشخص می‌کنند.

نتیجه	کد خروجی	معنا
OK	۰	نسخه PHP از آستانه تعیین‌شده برای شاخه شناخته‌شده بالاتر است.
VULNERABLE	۱	نسخه PHP برابر با آستانه تعیین‌شده برای شاخه مربوطه یا پایین‌تر از آن است.
UNKNOWN	۳	نسخه پیدا نشده، شاخه قابل‌شناسایی نیست یا نسخه آزمایشی جدیدتری در حال استفاده است.

ابزار چگونه هر شاخه PHP را ارزیابی می‌کند؟

هسته اصلی ابزار جدولی است که در فایل phpcheck.js قرار دارد و تاریخ آن ۲۰ اکتبر ۲۰۲۶ است. این جدول برای هر شاخه، آخرین نسخه‌ای را مشخص می‌کند که آسیب‌پذیر محسوب می‌شود. نسخه‌های بالاتر از این حد، در همان شاخه، نتیجه OK می‌گیرند.

شاخه PHP	آخرین نسخه آسیب‌پذیر در جدول
5.4	5.4.45
5.5	5.5.38
5.6	5.6.40
7.0	7.0.33
7.1	7.1.33
7.2	7.2.34
7.3	7.3.33
7.4	7.4.33
8.0	8.0.30
8.1	8.1.34
8.2	8.2.34
8.3	8.3.35
8.4	8.4.26
8.5	8.5.11

در شاخه‌های جدیدتر، مقادیر جدول با نسخه‌های منتشرشده برای رفع نقص مطابقت دارد: نسخه‌های 8.2.35، 8.3.36، 8.4.27 و 8.5.12. نسخه آخر در صفحه رسمی PHP.net به‌عنوان یک انتشار امنیتی معرفی شده است. جزئیات آن را در مطلب انتشار PHP 8.5.12 با ۹۰ اصلاح، از جمله در PDO، DOM و SOAP آورده‌ایم. نسخه‌های اصلاح‌شده شاخه‌های دیگر را می‌توان با افزودن یک شماره به آستانه درج‌شده در جدول به دست آورد، هرچند خود ابزار آن نسخه‌ها را فهرست نمی‌کند.

روش جمع‌آوری اطلاعات نسخه عمداً ساده نگه داشته شده است. ابزار ابتدا یک درخواست HEAD ارسال می‌کند و فقط در صورت دریافت پاسخ 405 یا 501 به درخواست GET روی می‌آورد. تغییرمسیرها را دنبال نمی‌کند، محتوای صفحه را نادیده می‌گیرد و برای یافتن نام و نسخه PHP فقط سرآیندهای Server و X-Powered-By را بررسی می‌کند. اگر چند نسخه پیدا شود، نسخه‌ای که وضعیت بدتری دارد ملاک قرار می‌گیرد. نسخه‌های توسعه‌ای مانند آلفا، بتا و نامزد انتشار (RC) برای وصله بعدی نیز نشانه قطعی رفع آسیب‌پذیری محسوب نمی‌شوند و نتیجه آن‌ها UNKNOWN خواهد بود.

چرا نتیجه UNKNOWN احتمالاً از همه رایج‌تر خواهد بود؟

من ابزار را روی همین وب‌سایت اجرا کردم. نتیجه UNKNOWN با کد خروجی ۳ و پیام «نسخه PHP پیدا نشد» بود. این نتیجه تعجب‌آور نیست؛ مدیران سرورهایی که به‌درستی پیکربندی شده‌اند، معمولاً نسخه PHP را پنهان می‌کنند تا اطلاعاتی در اختیار افرادی که به دنبال اهداف آسیب‌پذیر هستند قرار نگیرد. در چنین شرایطی، ابزار اطلاعات دیگری برای بررسی ندارد. در مقابل، اجرای آن روی PHP خط فرمان یک دستگاه توسعه با نسخه 8.5.6 نتیجه VULNERABLE و کد خروجی ۱ را برگرداند، زیرا آستانه تعیین‌شده برای این شاخه 8.5.11 است. هر ۳۹ آزمون همراه مخزن نیز که روی سرورهای HTTP محلی و یک فایل اجرایی ساختگی PHP اجرا می‌شوند، در حدود هفت ثانیه با موفقیت به پایان رسیدند.

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

درباره وب‌سایت‌هایی که از طریق پراکسی ارائه می‌شوند، شرکت Cloudflare نیز در پیامی در ایکس به توسعه‌دهندگان یادآوری کرد که سایت‌های استفاده‌کننده از PHP نسخه ۵.۴ یا بالاتر که به‌روزرسانی نشده‌اند، در معرض اجرای کد از راه دور، افشای اطلاعات و از کار افتادن سرویس قرار دارند. این شرکت اعلام کرد که پیش از افشای عمومی آسیب‌پذیری، تدابیر حفاظتی را فعال کرده است؛ بااین‌حال، تأکید کرد که حتی با وجود این محافظت‌ها، PHP باید هرچه سریع‌تر به‌روزرسانی شود. قواعدی که در فاصله پیش از نصب وصله می‌توان روی سرورهای Nginx و Apache اعمال کرد، در مطلب قواعد Nginx و Apache برای مسدودکردن حملات php2shell آمده است.

⚠️ هشدار آسیب‌پذیری: php2shell. سایت‌هایی که از PHP نسخه ۵.۴ یا بالاتر استفاده می‌کنند و هنوز وصله نشده‌اند، در معرض اجرای کد از راه دور، افشای اطلاعات و از کار افتادن سرویس قرار دارند. اگر ترافیک وب‌سایت شما از طریق Cloudflare عبور می‌کند، ما پیش از افشای رسمی و عمومی آسیب‌پذیری، محافظت‌های لازم را مستقر کردیم. برای اطلاع از اینکه کدام اقدامات کاهشی به‌طور پیش‌فرض فعال‌اند، مطلب وبلاگ را ببینید. حتی با وجود این تدابیر حفاظتی، برای رفع آسیب‌پذیری‌های اصلی، PHP را در اسرع وقت به‌روزرسانی کنید.

— توسعه‌دهندگان Cloudflare (@CloudflareDev)، ۲۱ اکتبر ۲۰۲۶

محدودیت‌هایی که باید در نظر گرفت

• ابزار فقط اطلاعاتی را می‌بیند که سرور آشکار می‌کند. اگر در سرآیندهای Server و X-Powered-By نام PHP وجود نداشته باشد، نتیجه UNKNOWN خواهد بود. بنابراین، کسانی که از روی احتیاط این سرآیندها را پنهان کرده‌اند، اطلاعاتی از ابزار به دست نمی‌آورند؛ همان اتفاقی که در این وب‌سایت رخ داد.
• نتیجه OK فقط حاصل مقایسه شماره نسخه‌هاست و ثابت نمی‌کند که نقص امنیتی واقعاً برطرف شده است. راهنمای پروژه فرض می‌کند هر نسخه پایدار پس از آستانه تعیین‌شده، اصلاحیه را در بر دارد، بی‌آنکه این موضوع را مستقلاً بررسی کند. به همین دلیل، راهنما به اطلاعیه امنیتی رسمی PHP نیز ارجاع می‌دهد.
• وصله‌های بازگردانده‌شده به نسخه‌های قدیمی بسته‌های توزیع‌های لینوکس (Backport) از این مقایسه جا می‌مانند. ممکن است بسته‌ای با شماره نسخه قدیمی که نگه‌دارنده آن، برای مثال در Debian، Ubuntu یا Red Hat، آسیب‌پذیری را برطرف کرده است، همچنان VULNERABLE گزارش شود؛ زیرا ابزار فقط شماره نسخه را می‌سنجد و سابقه تغییرات بسته توزیع را بررسی نمی‌کند.

امروز چه باید کرد؟ چهار اقدام ضروری

این ابزار برای غربالگری اولیه مناسب است، نه صدور حکم نهایی؛ اقدام اصلی همچنان باید روی خود سرور انجام شود. در عمل، مراحل کار به این ترتیب است:

1. روی سرور، نسخه PHP را با دستور php -v بررسی کنید. اگر سایت روی سرویس میزبانی اشتراکی قرار دارد، می‌توانید نسخه را از پنل میزبانی نیز ببینید. سپس آن را با نسخه‌های دارای اصلاحیه مقایسه کنید.
2. PHP را از طریق مخزن توزیع لینوکس یا کانال به‌روزرسانی ارائه‌دهنده میزبانی ارتقا دهید و با بررسی گزارش تغییرات بسته مطمئن شوید که اصلاحیه امنیتی در آن گنجانده شده است.
3. پس از به‌روزرسانی، ابزار را دوباره از بیرون سرور اجرا کنید. دریافت نتیجه OK یا UNKNOWN برای سروری که به‌روزرسانی آن تأیید شده است، دست‌کم می‌تواند به بررسی وضعیت آن کمک کند.
4. تا پیش از نصب به‌روزرسانی، قواعد مسدودسازی مربوط به درخواست‌های چندبخشی (Multipart) را اعمال کنید و گزارش‌های سرور را زیر نظر داشته باشید.

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

پیش از نصب یک مهارت

مهارت Codex شامل کد و دستورالعمل‌هایی است که عامل هوش مصنوعی روی رایانه فرد نصب‌کننده اجرا می‌کند. مهارت‌های موجود در این مخزن کوتاه و خوانا هستند؛ برای نمونه، فایل SKILL.md مربوط به phpcheck-url تصریح می‌کند که نباید اکسپلویت اجرا شود و در صورت پنهان‌بودن نسخه، باید نتیجه UNKNOWN گزارش شود. بااین‌حال، همین احتیاط باید درباره هر مهارت دیگری نیز رعایت شود: پیش از آنکه از یک عامل بخواهید مهارتی را نصب کند، فایل‌های آن را بخوانید. ابزارهای برنامه‌نویسی مبتنی بر هوش مصنوعی پیش‌تر نیز با مشکلات امنیتی مربوط به افزونه‌ها روبه‌رو شده‌اند؛ از جمله آسیب‌پذیری Plugin4Shell که Claude Code، Codex، Copilot و Gemini CLI را تحت تأثیر قرار داد.

پرسش‌های متداول

۱. آیا برای استفاده از php2shell-checker به Codex نیاز دارم؟

خیر. اسکریپت phpcheck.js به‌تنهایی با Node.js اجرا می‌شود و فقط از ماژول‌های استاندارد استفاده می‌کند. PHP روی رایانه شخصی تنها زمانی لازم است که بخواهید حالت --local را اجرا کنید. Codex فقط برای استفاده از دو مهارت ضروری است؛ این مهارت‌ها نیز همان اسکریپت را فراخوانی می‌کنند.

۲. آیا این ابزار اکسپلویت را روی وب‌سایت من اجرا می‌کند؟

خیر. ابزار یک درخواست HEAD ارسال می‌کند و فقط در صورت دریافت پاسخ 405 یا 501 از GET استفاده می‌کند. تغییرمسیرها را دنبال نمی‌کند و محتوای صفحه را نمی‌خواند. فایل SKILL.md نیز تصریح می‌کند که نباید هیچ اکسپلویتی اجرا شود. بااین‌حال، این ابزار همچنان به سرور موردنظر درخواست می‌فرستد؛ بنابراین بهتر است آن را فقط روی وب‌سایت‌های خودتان یا با موافقت مسئول آن سرورها به کار ببرید.

۳. اگر نتیجه UNKNOWN بود، چه کار کنم؟

وضعیت را از داخل سرور بررسی کنید. اگر به سرور دسترسی دارید، از دستور php -v یا مدیر بسته استفاده کنید. در میزبانی اشتراکی معمولاً نسخه PHP در پنل مدیریت نمایش داده می‌شود؛ در غیر این صورت، از ارائه‌دهنده خدمات بپرسید. مهارت phpcheck-server دقیقاً برای چنین شرایطی طراحی شده است.

۴. چرا ممکن است سرور به‌روزرسانی‌شده VULNERABLE گزارش شود؟

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

جمع‌بندی

باید این ابزار را همان‌طور که هست ارزیابی کرد: یک فیلتر اولیه سریع که در نهایت، کاری جز مقایسه شماره نسخه‌ها انجام نمی‌دهد. برای بررسی سریع ده‌ها نشانی مفید است، اما نمی‌توان امنیت یک وب‌سایت را صرفاً بر اساس نتیجه OK آن تأیید کرد. مدیرانی که چندین دامنه را اداره می‌کنند، می‌توانند اسکریپتی بنویسند که phpcheck.js را برای هر دامنه با گزینه --json اجرا و کدهای خروجی ۱ و ۳ را جمع‌آوری کند. این دو نتیجه مشخص می‌کنند کدام سایت‌ها به بررسی از داخل سرور نیاز دارند؛ جایی که نسخه واقعی PHP را می‌توان مستقیماً مشاهده کرد.