آسیب پذیری بحرانی wp2shell در هسته WordPress

wp2shell چیست و چه اتفاقی افتاده است؟

پژوهشگران Searchlight Cyber در ۱۸ ژوئیه ۲۰۲۶ جزئیات یک آسیب پذیری خطرناک در هسته WordPress را منتشر کردند که wp2shell نام گرفته است. این نقص به مهاجم ناشناس اجازه می دهد بدون داشتن حساب کاربری، نصب افزونه مخرب یا دسترسی قبلی، یک درخواست HTTP را به اجرای کد از راه دور یا Remote Code Execution روی سرور تبدیل کند. اهمیت رخداد در این است که سطح حمله به افزونه یا قالب خاصی محدود نیست و نصب استاندارد WordPress نیز می تواند در معرض خطر باشد.

نسخه اولیه هشدار و به روز رسانی های امنیتی در ۱۷ ژوئیه منتشر شدند، اما جزئیات فنی، شناسه آسیب پذیری، دامنه نسخه های متاثر و وجود نمونه عملی بهره برداری در ۱۸ ژوئیه روشن تر شد. آسیب پذیری اصلی با شناسه CVE-2026-63030 ثبت شده است. ارزیابی GitHub آن را بحرانی توصیف کرده، هرچند امتیاز اولیه CVSS برابر با ۷.۵ گزارش شده است. تفاوت میان برچسب بحرانی و امتیاز عددی به این معنا نیست که خطر ناچیز است؛ امکان اجرای کد بدون احراز هویت روی یک نصب پیش فرض، از نظر عملی یک سناریوی نفوذ کامل محسوب می شود.

پژوهش اولیه Searchlight Cyber تایید می کند که حمله پیش شرط خاصی ندارد و یک کاربر ناشناس می تواند نصب استاندارد WordPress را هدف قرار دهد. تحلیل های مستقل Rapid7 و Aikido نیز وجود زنجیره آسیب پذیری و نسخه های اصلاح شده را تایید کرده اند.

سازوکار فنی حمله wp2shell

مرحله اول: سردرگمی مسیر در REST API

نقطه ورود حمله به مسیر دسته ای REST API با آدرس /wp-json/batch/v1 مربوط است. Batch Route به مشتری اجازه می دهد چند عملیات API را در قالب یک درخواست مدیریت کند. نقص موجود در پردازش این مسیر می تواند باعث شود WordPress وضعیت، زمینه یا محدودیت امنیتی درخواست را به شکل نادرست تفسیر کند.

این بخش از زنجیره با عنوان سردرگمی مسیر یا Route Confusion شناخته می شود. مهاجم از تفاوت میان مسیری که لایه مسیریابی بررسی می کند و عملیاتی که در نهایت اجرا می شود، بهره می برد. چنین اختلافی می تواند کنترل های احراز هویت و اعتبارسنجی را بی اثر کند.

مرحله دوم: تزریق SQL

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

نسخه های WordPress 6.8.0 تا 6.8.5 فقط در برابر بخش SQL Injection این نقص آسیب پذیر گزارش شده اند. این شاخه با WordPress 6.8.6 اصلاح شده است. وجود SQL Injection به تنهایی نیز می تواند محرمانگی و یکپارچگی داده ها را تهدید کند، اما تمام نسخه های این شاخه لزوما در برابر زنجیره کامل wp2shell و اجرای کد قرار ندارند.

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

در نسخه های جدیدتر، مهاجم می تواند Route Confusion و SQL Injection را زنجیره کند و از دستکاری داده یا وضعیت داخلی به اجرای کد PHP روی سرور برسد. اجرای کد در بستر فرایند وب می تواند به ایجاد حساب مدیر، نصب در پشتی، تغییر فایل ها، سرقت اطلاعات پایگاه داده یا حرکت به سمت دیگر منابع سرور منجر شود.

نسخه های متاثر از زنجیره کامل عبارتند از:

• WordPress 6.9.0 تا 6.9.4؛ اصلاح شده در نسخه 6.9.5
• WordPress 7.0.0 تا 7.0.1؛ اصلاح شده در نسخه 7.0.2
• WordPress 7.1 Beta؛ اصلاح شده در 7.1 Beta 2

نسخه های پیش از 6.8 در برابر این دو نقص مشخص آسیب پذیر گزارش نشده اند، اما قدیمی ماندن روی آنها راهکار امنیتی قابل قبولی نیست؛ زیرا ممکن است آسیب پذیری های شناخته شده دیگری داشته باشند.

دامنه خطر و پیامدهای واقعی

یک سایت آسیب پذیر صرفا با خطر تغییر صفحه اصلی مواجه نیست. WordPress معمولا به پایگاه داده حاوی حساب ها، ایمیل کاربران، داده های فروشگاه، توکن ها و تنظیمات حساس متصل است. فایل wp-config.php نیز اطلاعات اتصال به پایگاه داده و کلیدهای رمزنگاری را در اختیار برنامه قرار می دهد. در نتیجه، اجرای کد می تواند دامنه نفوذ را از یک برنامه وب به حساب میزبانی و منابع مجاور گسترش دهد.

در محیط Shared Hosting، تنظیمات جداسازی ضعیف ممکن است ریسک دسترسی جانبی به سایت های دیگر همان حساب را افزایش دهد. در سرور اختصاصی یا VPS نیز اجرای WordPress با مجوزهای بیش از حد می تواند مهاجم را به فایل های پشتیبان، وظایف زمان بندی شده و اسرار برنامه های دیگر نزدیک کند.

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

اقدامات فوری برای مدیران WordPress

نخست نسخه فعال را از پیشخوان، ابزار WP-CLI یا سامانه مدیریت مرکزی بررسی کنید. به فعال بودن Auto Update اعتماد مطلق نداشته باشید؛ نسخه نصب شده باید به صورت مستقیم تایید شود.

شاخه 7.0 باید حداقل به 7.0.2، شاخه 6.9 به 6.9.5 و شاخه 6.8 به 6.8.6 ارتقا پیدا کند. برای سامانه های عملیاتی، ابتدا یک نسخه پشتیبان قابل بازیابی تهیه کنید، سپس به روز رسانی را اجرا و عملکرد قالب، افزونه ها، REST API و فرایندهای پرداخت را آزمایش کنید.

اگر نصب فوری Patch ممکن نیست، دسترسی ناشناس به مسیرهای /wp-json/batch/v1 و ?rest_route=/batch/v1 را موقتا در WAF یا Reverse Proxy محدود کنید. این اقدام ممکن است برخی یکپارچه سازی های قانونی REST API را مختل کند و جایگزین Patch نیست.

تیم دفاعی باید گزارش های وب مربوط به درخواست های غیرعادی این مسیر، خطاهای SQL، ایجاد حساب مدیر، تغییر فایل های PHP، افزونه های ناشناس و فرایندهای جدید سرور را بررسی کند. مقایسه Hash فایل های هسته با بسته رسمی WordPress و بررسی پوشه های wp-content/uploads و wp-content/mu-plugins نیز ضروری است.

در صورت مشاهده نشانه نفوذ، صرفا به روز رسانی کافی نیست. سایت باید از شبکه عمومی جدا شود، Snapshot و شواهد ثبت شوند، رمزهای پایگاه داده و پنل میزبانی تغییر کنند، کلیدهای امنیتی WordPress بازتولید شوند و نشست های فعال کاربران خاتمه پیدا کنند.

بهترین روش های کاهش ریسک

کمینه سازی مجوزهای کاربر پایگاه داده، جلوگیری از اجرای PHP در پوشه Upload، محدود کردن دسترسی مدیریتی، استفاده از File Integrity Monitoring و نگهداری نسخه پشتیبان خارج از سرور، دامنه خسارت را کاهش می دهد. WAF یک لایه دفاعی مفید است، اما نباید به عنوان جایگزین اصلاح هسته در نظر گرفته شود.

موجودی دقیق سایت ها نیز اهمیت دارد. سازمانی که نمی داند چند نصب WordPress، چه نسخه هایی و تحت مالکیت چه تیم هایی دارد، نمی تواند Patch Management موثری اجرا کند. در محیط های بزرگ، نسخه WordPress باید در Asset Inventory و سامانه Vulnerability Management ثبت شود.