آسیبپذیری WP2Shell در وردپرس | راهنمای کامل رفع

اگر مدیر یک سایت وردپرسی هستید، احتمالاً این روزها نام WP2Shell را در گزارشهای امنیتی مختلف دیدهاید.
این نام (آسیبپذیری WP2Shell)، اشاره به یک زنجیره آسیبپذیری بحرانی در هسته وردپرس دارد که ترکیب دو نقص جداگانه، یک اشکال تزریق SQL و یک خطای مسیریابی در REST API به مهاجم امکان میدهد بدون داشتن حساب کاربری و بدون نیاز به هیچ افزونه یا قالب خاصی، کد دلخواه خود را روی سرور اجرا کند.
از آنجا که وردپرس درصد قابلتوجهی از وبسایتهای جهان از جمله بخش بزرگی از سایتهای فارسیزبان را تشکیل میدهد، این آسیبپذیری در مدت کوتاهی به یکی از پرمخاطبترین موضوعات امنیتی سال ۲۰۲۶ تبدیل شد. در این مقاله با جزئیات فنی، نسخههای درگیر، روش تشخیص و مراحل دقیق رفع این تهدید آشنا میشوید.
آنچه در این مقاله می خوانید :
WP2Shell دقیقاً چیست؟
آسیبپذیری WP2Shell در وردپرس، نام غیررسمی است که جامعه امنیتی برای توصیف زنجیرهای از دو آسیبپذیری در هسته وردپرس انتخاب کرده است:
- یک نقص تزریق SQL در پردازش پارامترهای مربوط به کوئریهای نویسنده در
WP_Query. - یک خطای منطقی در پردازشگر دستهای (Batch) REST API وردپرس، جایی که اعتبارسنجی مسیر درخواستهای فرعی و اجرای واقعی آنها در دو حلقه جداگانه انجام میشود؛ در نتیجه یک درخواست که در مرحله اعتبارسنجی با خطا مواجه شده، همچنان میتواند در مرحله اجرا پردازش شود.
وقتی این دو نقص بهصورت زنجیرهای ترکیب شوند، مهاجم میتواند بدون هیچ احراز هویتی، اطلاعات حساس پایگاه داده از جمله هش رمز عبور کاربران را استخراج کند و در ادامه، با دور زدن مکانیزمهای کنترل دسترسی، به سطح اجرای کد دلخواه (RCE) روی سرور برسد.

نکته مهم این است که این مسیر حمله کاملاً در هسته وردپرس قرار دارد، نه در یک افزونه یا قالب؛ بنابراین غیرفعالکردن افزونهها یا تغییر قالب، هیچ تأثیری در کاهش ریسک ندارد.
چرا این آسیبپذیری اینقدر خطرناک تلقی میشود؟
سه ویژگی آسیبپذیری WP2Shell را از بسیاری از آسیبپذیریهای معمول وردپرسی متمایز میکند:
- عدم نیاز به احراز هویت: مهاجم نیازی به نام کاربری، رمز عبور یا هیچ نوع تعامل کاربر (مثل کلیک روی لینک) ندارد.
- قابلیت اکسپلویت روی نصب پیشفرض: این حمله حتی روی یک نصب استاندارد وردپرس بدون هیچ افزونه اضافهای قابل اجراست.
- زنجیره تا سطح Administrator و اجرای کد: در سناریوهای گزارششده، مهاجمان با استخراج اطلاعات از طریق تزریق SQL، به رمزهای عبور مدیر دست یافته یا حساب مدیر جدید ساخته و سپس با نصب یک افزونه مخرب یا قرار دادن وبشل، کنترل کامل سرور را در اختیار میگیرند.
طبق گزارش شرکتهای امنیتی مختلف از جمله Wiz، Qualys و CrowdSec، بهمحض انتشار عمومی جزئیات فنی و کدهای اثبات مفهوم (PoC)، حجم اسکنهای خودکار برای شناسایی سایتهای آسیبپذیر بهشدت افزایش یافت و این آسیبپذیری در فهرست CISA KEV (فهرست آسیبپذیریهای شناختهشده مورد بهرهبرداری) نیز قرار گرفت.
کدام نسخههای وردپرس آسیبپذیر هستند؟
نکته مهم این است که دو آسیبپذیری مرتبط با این زنجیره، دامنه نسخهای متفاوتی دارند. بخش تزریق SQL از نسخه ۶.۸ به بعد در هسته حضور داشته، اما زنجیره کامل که منجر به اجرای کد از راه دور میشود، فقط با وجود نقص REST API که از نسخه ۶.۹ معرفی شده، قابل تحقق است.
| بازه نسخه | وضعیت آسیبپذیری | نسخه اصلاحشده |
|---|---|---|
| ۶.۸.۰ تا ۶.۸.۵ | آسیبپذیر نسبت به نقص تزریق SQL (بدون زنجیره کامل RCE) | ۶.۸.۶ |
| ۶.۹.۰ تا ۶.۹.۴ | آسیبپذیر نسبت به زنجیره کامل (SQLi + RCE) | ۶.۹.۵ |
| ۷.۰.۰ و ۷.۰.۱ | آسیبپذیر نسبت به زنجیره کامل (SQLi + RCE) | 7.0.4 و بالاتر |
| قدیمیتر از ۶.۸ | مبتلا به این آسیبپذیری خاص نیستند | — |
نکته مهم: نسخههای قدیمیتر از ۶.۸ به این زنجیره خاص آلوده نیستند، اما این بهمعنای ایمن بودن آنها نیست.
نسخههای قدیمی معمولاً فاقد دهها وصله امنیتی دیگر هستند و نگهداشتن سایت روی چنین نسخههایی، ریسک قابلتوجهی از جنبههای دیگر ایجاد میکند.
توصیه فنی این است که در همه حالات، هسته وردپرس به آخرین نسخه پایدار (در حال حاضر 7.0.3 یا جدیدتر) ارتقا یابد.

چه کسانی در معرض خطر هستند؟
عملاً هر سایتی که یکی از شرایط زیر را داشته باشد، در معرض خطر مستقیم آسیبپذیری WP2Shell قرار دارد:
- سایتهایی که نسخه هسته وردپرس آنها در بازه ۶.۸.۰ تا ۷.۰.۱ قرار دارد و بهروزرسانی خودکار برای آنها فعال نشده است.
- سایتهای چندسایتی (Multisite) که مدیریت متمرکز آنها روی یک نسخه هسته قدیمی باقی مانده است.
- محیطهای Staging، سابدامینهای آزمایشی یا نسخههای دمو که معمولاً از چرخه پایش امنیتی خارج میمانند اما بهصورت عمومی در دسترس اینترنت هستند.
- سایتهای میزبانیشده روی هاستهای اشتراکی یا سرورهایی که کش شیء پایدار (Persistent Object Cache مانند Redis یا Memcached) روی آنها فعال نیست، چرا که مسیر آسیبپذیر REST API در این حالت راحتتر قابل دسترسی است.
- سایتهایی که به دلیل تنظیمات هاست، محدودیت مجوز فایل یا خطای دیسک، فرایند بهروزرسانی خودکار در آنها با شکست مواجه شده است؛ این حالت بسیار رایجتر از آن چیزی است که مدیران سایت تصور میکنند نیز در معرض آسیبپذیری WP2Shell قرار دارند.
اگر شما یا تیم توسعهتان چندین سایت وردپرسی را روی زیرساختهای cPanel/WHM یا سرورهای اختصاصی مدیریت میکنید، بررسی نسخه هسته باید در همان روز اول تشخیص، برای تمام دامنهها و سابدامینها انجام شود، نه فقط سایت اصلی.

اما در صورتی که به هرعلتی سایت شما آلوده و ویروسی یا هک شده است، پیشنهاد می شود هرچه زودتر نسبت به پاکسازی آن اقدام نمایید تا از انتشار آلودگی در تمام سایت و تخریب سایت شما جلوگیری شود.
روش تشخیص نسخه وردپرس سایت
برای اطمینان از وضعیت سایت، سه روش زیر قابل استفاده است:
۱. از طریق پیشخوان مدیریت وردپرس
وارد پنل مدیریت شوید و به مسیر «پیشخوان > بهروزرسانیها» بروید. شماره نسخه فعلی هسته در بالای همین صفحه نمایش داده میشود.
۲. از طریق خط فرمان با WP-CLI
اگر به سرور دسترسی SSH دارید، این روش دقیقترین و سریعترین گزینه برای بررسی چند سایت بهصورت همزمان است:
cd /path/to/wordpress
wp core version
برای بررسی همزمان چند سایت روی یک سرور میتوانید یک اسکریپت ساده بنویسید که این دستور را در تمام دایرکتوریهای سایت اجرا کند و خروجی را در یک فایل لاگ ذخیره کند.
۳. از طریق کد منبع صفحه (در صورت نبود دسترسی مدیریتی)
در برخی نصبها، شماره نسخه در متادیتای HTML صفحه اصلی (تگ generator) قابل مشاهده است؛ هرچند بسیاری از سایتهای ایمن این تگ را به دلایل امنیتی حذف میکنند، بنابراین این روش قابلاتکا نیست و صرفاً یک بررسی مکمل محسوب میشود.
در صورتی که شما هم تمایل دارید نسخه یا ورژن وردپرس خود را مخفی نگهدارید، از آموزش مخفی کردن نسخه وردپرس با 3 روش استفاده نمایید.
اقدامات فوری برای رفع آسیبپذیری WP2Shell
گام ۱: تهیه نسخه پشتیبان کامل
پیش از هرگونه تغییر، از فایلها و پایگاه داده سایت یک بکاپ کامل و قابل بازیابی تهیه کنید. این بکاپ باید هم شامل فایلهای وردپرس (wp-content، wp-config.php و غیره) و هم دامپ کامل پایگاه داده باشد.
گام ۲: بهروزرسانی فوری هسته وردپرس
مطمئنترین و تنها راهحل قطعی، ارتقای هسته به نسخه اصلاحشده متناظر (۶.۸.۶، ۶.۹.۵، ۷.۰.۲ یا جدیدتر) است. در صورت امکان، بسته نصبی نسخه امن را مستقیماً از منبع رسمی وردپرس دریافت و بهصورت دستی جایگزین کنید:
cd /path/to/wordpress
wp core update --version=7.0.2 --force
wp core update-db
اگر به WP-CLI دسترسی ندارید، میتوانید آخرین نسخه امن را از آدرس رسمی زیر دانلود کرده و فایلهای هسته (بهاستثنای پوشه wp-content و فایل wp-config.php) را بهصورت دستی جایگزین فایلهای فعلی سرور کنید.
توجه داشته باشید که این کار باید ابتدا در یک محیط تست یا staging انجام و بررسی شود تا از سازگاری افزونهها و قالب فعال با نسخه جدید مطمئن شوید. (در صورت عدم اطلاع از staging، آموزش روش های آپدیت وردپرس را بررسی نمایید )
گام ۳: مسدودسازی موقت مسیر آسیبپذیر (در صورت عدم امکان آپدیت فوری)
اگر به هر دلیلی بهروزرسانی فوری ممکن نیست، بهعنوان یک اقدام موقت و نه جایگزین وصله رسمی، میتوانید دسترسی ناشناس به مسیرهای زیر را در سطح فایروال وب (WAF) یا در پیکربندی وبسرور مسدود کنید:
/wp-json/batch/v1
?rest_route=/batch/v1
نمونه قانون در Nginx:
location ~* ^/wp-json/batch/v1 {
return 403;
}
if ($arg_rest_route ~* "^/batch/v1") {
return 403;
}
این راهکار صرفاً یک لایه محافظتی موقت است و ممکن است عملکرد برخی افزونههای مجاز که از این مسیر استفاده میکنند را مختل کند؛ بهمحض امکانپذیر شدن آپدیت هسته، این محدودیت باید برداشته و جایگزین وصله رسمی شود.
گام ۴: بررسی نشانههای نفوذ احتمالی
توجه کنید که بهروزرسانی هسته فقط مسیر ورود جدید را میبندد و اگر مهاجم پیشتر از این آسیبپذیری بهرهبرداری کرده باشد، درهای پشتی احتمالی برطرف نخواهند شد.

موارد زیر را بررسی کنید:
- فهرست کاربران با نقش Administrator در مسیر «کاربران > همه کاربران» و شناسایی هرگونه حساب ناشناس یا رمز عبور تغییر یافته بدون اطلاع شما.
- فهرست افزونههای فعال و شناسایی افزونههای نصبشدهای که خودتان آنها را نصب نکردهاید.
- فایلهای جدید یا ویرایششده اخیر، بهخصوص در مسیرهای
wp-content/uploads،wp-content/mu-pluginsو ریشه سایت. - Cron Jobهای زمانبندیشده غیرمعمول در پایگاه داده یا در کرونتب سرور.
- لاگ دسترسی وبسرور برای درخواستهای مربوط به
/wp-json/batch/v1در بازه زمانی پیش از بهروزرسانی.
در صورت مشاهده هرگونه نشانه مشکوک، توصیه میشود رمز عبور دیتابیس، هاست و تمام کاربران مدیر تغییر کند، کلیدهای امنیتی (Salts) در فایل wp-config.php بازتولید شوند تا تمام نشستهای فعال باطل شوند، و در صورت شک جدی به نفوذ، سایت از یک بکاپ سالم و مربوط به قبل از تاریخ افشای آسیبپذیری بازیابی شود.
سؤالات متداول
آیا فقط سایتهای دارای افزونه یا قالب خاص در معرض خطر هستند؟
خیر. این آسیبپذیری در هسته وردپرس قرار دارد و حتی یک نصب استاندارد و پیشفرض بدون هیچ افزونه یا قالب اضافهای میتواند مورد سوءاستفاده قرار گیرد.
آیا فعالبودن Redis یا Memcached سایت را کاملاً ایمن میکند؟
خیر. استفاده از کش شیء پایدار میتواند مسیر خاصی از زنجیره حمله را دشوارتر کند، اما این موضوع جایگزین وصله رسمی نیست و نباید بهعنوان یک راهکار قطعی امنیتی در نظر گرفته شود.
آیا فعالبودن بهروزرسانی خودکار وردپرس کافی است؟
در بسیاری موارد بله، اما بهروزرسانی خودکار میتواند به دلیل محدودیت مجوز فایل، کمبود فضای دیسک یا تنظیمات خاص هاست با شکست مواجه شود. بنابراین بررسی دستی نسخه پس از انتشار وصله امنیتی، ضروری است.
اگر سایت من روی نسخه قدیمیتر از ۶.۸ است، نیازی به اقدام ندارم؟
اگرچه نسخههای قدیمیتر از ۶.۸ مشمول این زنجیره خاص نیستند، اما به دلیل نبود وصلههای امنیتی دیگر، بهروزرسانی به آخرین نسخه پایدار همچنان ضروری است.
آیا بعد از آپدیت هسته، خطری من را تهدید نمیکند؟
بهروزرسانی هسته فقط جلوی سوءاستفاده جدید را میگیرد. اگر پیش از آپدیت، سایت مورد نفوذ قرار گرفته باشد، وجود درهای پشتی احتمالی باید جداگانه بررسی و پاکسازی شود.
نتیجهگیری
آسیبپذیری WP2Shell یکی از جدیترین تهدیدات امنیتی سالهای اخیر برای اکوسیستم وردپرس محسوب میشود، چرا که بدون نیاز به احراز هویت یا وجود افزونه آسیبپذیر، مسیر مستقیمی به سمت اجرای کد از راه دور و در دستگیری کامل سایت باز میکند.
مهمترین اقدام، بررسی فوری نسخه هسته وردپرس تمام سایتهای تحت مدیریت شما و ارتقای بدون تأخیر به نسخههای اصلاحشده (۶.۸.۶، ۶.۹.۵ یا ۷.۰.۲ و جدیدتر) است. در کنار این اقدام، بررسی نشانههای نفوذ احتمالی، پایش لاگهای دسترسی و استفاده از یک لایه فایروال وب معتبر، ریسک باقیمانده را به حداقل میرساند.
امنیت وردپرس یک اقدام یکباره نیست؛ پایش مستمر نسخه هسته، افزونهها و قالبها باید بخشی دائمی از فرایند نگهداری هر سایت وردپرسی باشد.





