آسیب‌پذیری WP2Shell در وردپرس چیست؟ تحلیل فنی، خطرات و راهکار رفع

WP2Shell به زنجیره‌ای از دو نقص امنیتی در هسته WordPress اشاره می‌کند که در نسخه‌های مشخصی می‌توانند در کنار هم، مسیر اجرای کد از راه دور را برای مهاجم ناشناس باز کنند؛ پس طرف ما، اصلاً یک افزونه ناشناخته یا یک قالب آسیب‌پذیر نیست!

پژوهشگران امنیت سایبری Searchlight Cyber عنوان کرده‌اند که زنجیره موردنظر روی یک نصب معمولی وردپرس، بدون افزونه و بدون نیاز به حساب کاربری، قابل بهره‌برداری بوده است. طبق گزارش Aviatrix، این آسیب‌پذیری از جولای 2026 به‌صورت فعال و در مقیاس گسترده روی سایت‌های وردپرسی مورد سوءاستفاده قرار گرفته است.

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

این یعنی دقیقاً باید چه‌کار کنیم؟ این مقاله را تا پایان بخوانید تا پاسخ این سوال را بگیرید.

آسیب‌پذیری WP2Shell دقیقاً چیست؟

WP2Shell نام رایج یک Exploit Chain است؛ یعنی مهاجم از دو نقص مستقل استفاده می‌کند و آن‌ها را به یک زنجیره حمله تبدیل می‌کند:

• CVE-2026-60137: یک نقص SQL Injection تسهیل‌شده در WP_Query و پارامتر author__not_in
• CVE-2026-63030: یک نقص منطقی از نوع REST API Batch-Route Confusion

اول بیایید ببینیم این دو نقص، هر کدام به چه معنا هستند و چطور عمل می‌کنند؟

CVE-2026-60137؛ نقص SQL Injection در WP_Query

WP_Query یکی از اجزای اصلی وردپرس برای ساخت query و دریافت نوشته‌هاست. پارامتر author__not_in هم برای مشخص‌کردن نویسندگانی استفاده می‌شود که نباید نوشته‌هایشان در نتیجه query قرار بگیرد.

در نسخه‌های آسیب‌پذیر، نحوه پردازش این ورودی می‌توانست در زنجیره WP2Shell برای ایجاد SQL Injection مورد سوءاستفاده قرار بگیرد.

⭐ نکته‌ مهم اینجاست: WordPress این مشکل را یک facilitated SQL injection معرفی کرده است. یعنی نباید آن را به‌صورت ساده معادل «هر سایت وردپرسی بدون هیچ شرطی مستقیماً SQL Injection دارد» در نظر گرفت.

توجه: این نقص در نسخه‌های 6.8.x (تا پیش از 6.8.6)، 6.9.x (تا پیش از 6.9.5) و 7.0.x (تا پیش از 7.0.2) وجود داشت. با این حال، نکتهٔ مهم این است که خودِ این نقص به‌تنهایی روی نسخهٔ 6.8.x فقط در صورتی قابل‌سوءاستفاده بود که یک افزونه یا قالب، ورودی کاربر را بدون بررسی به این پارامتر پاس می‌داد؛ چون مسیر دوم زنجیره (یعنی CVE-2026-63030) که امکان سوءاستفادهٔ بدون افزونه و بدون احراز هویت را فراهم می‌کرد، روی 6.8.x اصلاً وجود نداشت.

CVE-2026-63030؛ خطای Batch-Route Confusion در REST API

وردپرس در REST API خود قابلیتی برای پردازش چند درخواست در قالب یک درخواست Batch دارد. endpoint مربوط به این قابلیت به‌صورت پیش‌فرض در مسیر زیر قرار دارد:

/wp-json/batch/v1

در ساختار آسیب‌پذیر، مسیر درخواست‌های داخلی در دو مرحله متفاوت مدیریت می‌شد:

• ابتدا validation انجام می‌شد
• سپس درخواست‌ها وارد مرحله execution می‌شدند.

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

مسیر مشابه دیگری نیز می‌تواند از طریق rest_route مورد استفاده قرار بگیرد:

?rest_route=/batch/v1

Searchlight Cyber همین دو مسیر را در توصیه موقت خود برای محدودسازی دسترسی ناشناس به Batch API ذکر کرده است.

نتیجه ترکیب این دو نقص چیست؟

نقطه حساس WP2Shell همین‌جاست. دو نقص جداگانه، وقتی در یک زنجیره قرار می‌گیرند، می‌توانند مهاجم را از یک درخواست بدون احراز هویت به مرحله Remote Code Execution برسانند. در این حالت، مهاجم برای شروع حمله به username یا password وردپرس نیاز ندارد.

🧩 در نتیجه، برخلاف بسیاری از رخنه‌های وردپرس که نقطه ورود آن‌ها plugin یا theme است، در اینجا بخش مهمی از زنجیره در WordPress Core قرار دارد.

وب‌شل چیست و چه ارتباطی با WP2Shell دارد؟

RCE معمولاً پایان حمله نیست؛ مهاجم پس از اجرای کد روی سرور ممکن است سعی کند یک دسترسی ماندگار برای خودش ایجاد کند. یکی از روش‌های شناخته‌شده برای این کار، استفاده از Web Shell است.

وب‌شل معمولاً یک فایل مخرب PHP است که مهاجم می‌تواند از طریق درخواست HTTP آن را فراخوانی کند و دستورات یا عملیات موردنظرش را روی سرور اجرا کند.

برای درک ساده مفهوم، این کد را ببینید:

if (isset($_GET['cmd'])) {
    system($_GET['cmd']);
}

در این مثال، مقدار cmd مستقیماً به system() داده می‌شود و PHP آن را به‌عنوان یک دستور سیستم اجرا می‌کند.

⭐ البته وب‌شل‌های واقعی معمولاً بسیار پیچیده‌تر هستند و برای اینکه توسط اسکنرهای ساده شناسایی نشوند، از تکنیک‌های Obfuscation استفاده می‌کنند. در این روش، کد واقعی مخفی یا رمزگذاری‌شده به شکلی نوشته می‌شود که بررسی دستی و اسکن خودکار دشوارتر شود.

برای مثال، ممکن است با توابعی مانند eval، base64_decode، gzinflate و str_rot13 روبه‌رو شویم:

eval(base64_decode('c3lzdGVtKCRfR0VUWydjbWQnXSk7'));

هرچند دیدن یکی از این توابع به‌تنهایی به معنی وجود malware نیست؛ باید محتوای فایل، محل قرارگیری آن، زمان ایجاد یا تغییر و ارتباط آن با رفتارهای مشکوک سیستم را هم بررسی کرد.

آیا WP2Shell تنها راه ورود به وب‌شل است؟

خیر. وب‌شل می‌تواند نتیجه انواع مختلفی از نفوذ باشد. در یک بررسی امنیتی باید مسیرهای دیگری مثل موارد زیر را هم در کنار آسیب‌پذیری افزونه‌ها و قالب‌ها در نظر گرفت:

• Arbitrary File Upload
• LFI
• RFI
• brute force

به همین دلیل مشاهده یک وب‌شل الزاماً ثابت نمی‌کند که سایت از طریق WP2Shell هک شده است؛ برای مشخص‌کردن مسیر نفوذ، باید فایل‌ها، لاگ‌ها، زمان‌بندی رویدادها و فعالیت‌های کاربر و سرور کنار یکدیگر بررسی شوند.

از کجا بفهمیم سایت وردپرسی هک شده است؟

هیچ نشانه‌ای به‌تنهایی قطعی نیست، اما اگر ترکیبی از چند علامت زیر را دیدید، باید گوش به زنگ باشید:

ایجاد فایل‌های ناشناس

وجود فایل‌های PHP ناشناخته با نام‌های عجیب، غلط املایی عمدی یا فایل‌هایی که بدون دلیل در ریشه سایت یا wp-content ظاهر شده‌اند، نیازمند بررسی است.

مسیرهای حساس عبارت‌اند از:

/
wp-content/
wp-content/plugins/
wp-content/uploads/

فایل‌هایی مثل wp-check.php یا cache_old.php صرفاً نمونه‌اند و نباید به‌عنوان IOC قطعی در نظر گرفته شوند. حتی نامی مثل index.php کاملاً عادی است و فقط وقتی مشکوک می‌شود که محتوای آن با نسخه سالم WordPress تفاوت داشته باشد.

ایجاد کاربر Administrator

اگر Administrator جدیدی بدون اطلاع شما ایجاد شده،احتمال هک شدن یا دسترسی غیرمجاز به سایت را جدی بگیرید. Application Passwordهای ناشناس را نیز باید بررسی کرد؛ چون تغییر password مدیر سایت به‌تنهایی لزوماً همه مسیرهای دسترسی ایجادشده توسط مهاجم را نمی‌بندد.

تغییر فایل‌های اصلی

تغییر غیرمنتظره در فایل‌هایی مثل:

index.php
wp-config.php
.htaccess
wp-admin/
wp-includes/

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

برای بررسی integrity فایل‌های Core می‌توان از WP-CLI استفاده کرد:

wp core verify-checksums

مصرف غیرعادی منابع سرور

افزایش ناگهانی CPU و RAM، ایجاد فرایندهای غیرعادی یا کندی شدید سایت می‌تواند یکی از نشانه‌های فعالیت مخرب باشد.

هرچند این علائم به‌تنهایی اثبات‌کننده هک نیستند و ممکن است علت‌هایی مثل ترافیک بالا یا افزونه‌های معیوب هم داشته باشند.

ارسال ایمیل‌های انبوه

اگر سایت ناگهان شروع به ارسال حجم زیادی از ایمیل‌های اسپم کند، احتمال سوءاستفاده از منابع سرور وجود دارد.

نتایج عجیب در Google

نمایش صفحات ناشناس به زبان‌های ژاپنی یا چینی، تبلیغات نامرتبط، محتوای دارویی و redirectهای غیرعادی در سایت یا نتایج جست‌وجوی گوگل، می‌تواند نشانه هک شدن سایت باشد و نیاز به بررسی دارد.

افزونه یا Cron ناشناس

افزونه ناشناخته، mu-plugin غیرمنتظره، Cron Job جدید یا زمان‌بندی‌ای که مدیر سایت آن را ایجاد نکرده است، ارزش بررسی دارد.

Logهای وب‌سرور

اگر سایت در دوره آسیب‌پذیری روی نسخه درگیر بوده، لاگ‌های دسترسی و WAF را پیش از پاکسازی بررسی کنید.

در مورد WP2Shell، درخواست‌های مشکوک به:

/wp-json/batch/v1

یا شکل rest_route آن می‌توانند سرنخ باشند. اما نباید نبودن این URL را معادل «قطعاً حمله‌ای رخ نداده» دانست. Elastic علاوه بر لاگ، به رفتارهایی مثل ایجاد فایل و اجرای shell توسط سرویس وب به‌عنوان نشانه‌های مهم اشاره کرده است.

چگونه نسخه وردپرس را بررسی کنیم؟

اگر به پیشخوان وردپرس دسترسی دارید، از منوی پیشخوان به بخش به‌روزرسانی‌ها بروید؛ در این بخش می‌توانید نسخه فعلی WordPress و وضعیت به‌روزرسانی آن را ببینید.

اگر به سرور از طریق SSH دسترسی دارید و ابزار WP-CLI روی آن نصب شده است، می‌توانید این بررسی‌ها را از خط فرمان انجام دهید:

wp core version

این دستور نسخه فعلی WordPress نصب‌شده روی سایت را نمایش می‌دهد.

برای اینکه ببینید نسخه جدیدتری برای WordPress منتشر شده است یا نه، از این دستور استفاده کنید:

wp core check-update

این دستور به‌روزرسانی‌های در دسترس WordPress را بررسی می‌کند.

همچنین برای اینکه مطمئن شوید فایل‌های اصلی WordPress تغییر نکرده یا با نسخه رسمی تفاوت ندارند، می‌توانید اجرا کنید:

wp core verify-checksums

این دستور فایل‌های هسته WordPress را با checksumهای رسمی WordPress.org مقایسه می‌کند و در صورت مشاهده فایل تغییرکرده یا فایل اضافی، نتیجه را گزارش می‌دهد.

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

راهکارهای پیشگیری، رفع و پاکسازی WP2Shell

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

۱. قبل از هر کاری Backup بگیرید

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

۲. WordPress را فوراً به‌روز کنید

مهم‌ترین اقدام، نصب یک نسخه امن WordPress است.

طبق بررسی Searchlight Cyber نسخه‎‌های آسیب‌پذیر عبارتند از:

• 6.9.0 تا 6.9.4
• 7.0.0 تا 7.0.1

توجه: طبق بررسی NVD، زنجیرهٔ کامل WP2Shell (یعنی حملهٔ بدون احراز هویت) فقط نسخه‌های 6.9.0 تا 6.9.4 و 7.0.0 تا 7.0.1 را درگیر می‌کند. با این حال، اگر روی نسخهٔ 6.8.x هستید و از افزونه یا قالبی استفاده می‌کنید که ورودی کاربر را بدون بررسی به query ارسال می‌کند، همچنان در معرض یکی از دو نقص (SQL Injection) هستید و باید وردپرستان به‌روزرسانی کنید.

۳. اگر فعلاً امکان آپدیت ندارید، Batch API را موقتاً مسدود کنید

در صورت وجود محدودیت عملی برای به‌روزرسانی فوری، می‌توانید در سطح WAF یا وب‌سرور، دسترسی ناشناس به این مسیرها را محدود کنید:

/wp-json/batch/v1

و:

?rest_route=/batch/v1

⭐ این راهکار را باید موقتی در نظر گرفت؛ چون ممکن است بعضی قابلیت‌های سایت یا اتصال‌هایی که از REST Batch استفاده می‌کنند، مختل شوند.

۴. فایل‌های آلوده را پاکسازی کنید

اگر شواهدی از نفوذ وجود دارد، فقط WordPress را به‌روز نکنید. فایل‌های PHP ناشناس، افزونه‌های مشکوک، mu-pluginها، قالب‌ها و تغییرات غیرمنتظره در فایل‌های هسته را هم مو‌به‌مو بررسی کنید.

برای اسکن می‌توان از ابزارهایی مانند Wordfence، ClamAV و Linux Malware Detect یا Maldet کمک گرفت. اما اسکنر نباید تنها منبع تشخیص باشد؛ چون گاهی مهاجم می‌تواند فایل‌های موقت را حذف کند و بنابراین بررسی داده‌های پایش و گزارش‌های ثبت‌شده هم اهمیت دارد.

۵. اجرای PHP در uploads را محدود کنید

پوشه wp-content/uploads معمولاً محل نگهداری فایل‌های آپلودی است و در حالت عادی نباید قابل اجرای PHP باشد. جلوگیری از اجرای PHP در این مسیر یک لایه دفاعی مفید است و می‌تواند بعضی روش‌های ایجاد دسترسی ماندگار را دشوارتر کند.

۶. دسترسی فایل‌ها و پوشه‌ها را محدود کنید

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

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

در بسیاری از نصب‌های وردپرس، برای فایل‌ها از مجوز 644 و برای پوشه‌ها از 755 استفاده می‌شود. با این حال، مقدار مناسب به تنظیمات سرور و نحوه اجرای PHP بستگی دارد و نباید این اعداد را بدون بررسی، برای همه سایت‌ها یکسان در نظر گرفت.

🧩 نکته اصلی: هر فایل و پوشه باید فقط به اندازه‌ای دسترسی داشته باشد که برای اجرای درست سایت لازم است.

۷. ویرایشگر فایل وردپرس را غیرفعال کنید

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

برای غیرفعال کردن این امکان، در فایل wp-config.php کد زیر را اضافه کنید:

define( 'DISALLOW_FILE_EDIT', true );

با این کار، گزینه ویرایش فایل افزونه‌ها و قالب‌ها از پیشخوان وردپرس حذف می‌شود. توجه داشته باشید که این تنظیم به‌تنهایی جلوی WP2Shell را نمی‌گیرد و فقط یکی از راه‌های احتمالی سوءاستفاده را محدود می‌کند.

۸. توابع حساس PHP را در صورت امکان محدود کنید

بعضی از توابع PHP می‌توانند در اجرای دستورات روی سرور مورد سوءاستفاده قرار بگیرند. اگر شرایط سرور اجازه بدهد، می‌توان دسترسی به تعدادی از این توابع را محدود کرد.

البته این کار باید با احتیاط انجام شود؛ چون ممکن است بعضی افزونه‌ها یا بخش‌های سایت به همین توابع نیاز داشته باشند و بعد از محدود شدن آن‌ها، درست کار نکنند.

Redis و Memcached چه نقشی دارند؟

Redis و Memcached ابزارهایی هستند که معمولاً برای نگهداری موقت داده‌ها و سریع‌تر شدن سایت استفاده می‌شوند؛ یکی از رایج‌ترین کاربردهای آن‌ها در وردپرس، عمل‌کردن به‌عنوان Object Cache است.

در برخی روش‌های سوءاستفاده از زنجیرۀ WP2Shell، مهاجم برای ساختن یک حساب Administrator جعلی، به‌جای دست‌کاری مستقیم دیتابیس، سراغ «مسموم‌کردن Object Cache» می‌رود؛ یعنی مقادیری را در لایهٔ کش تزریق می‌کند تا وردپرس هنگام خواندن اطلاعات کاربر، دادۀ دست‌کاری‌شده دریافت کند.

حالا وقتی Object Cache سایت با Redis یا Memcached پیاده‌سازی شده باشد، ساختار داده و رفتار کش با حالت پیش‌فرض وردپرس -که از دیتابیس یا Transient API استفاده می‌کند- متفاوت است. همین تفاوت می‌تواند مسیر سوءاستفاده را سخت‌تر کند.

⭐ با این حال، این موضوع تنها یکی از چند روش شناخته‌شده برای بهره‌برداری از WP2Shell را تحت‌تأثیر قرار می‌دهد؛ نه کل زنجیرۀ حمله را. بنابراین نباید تصور کرد استفاده از Redis یا Memcached سایت را در برابر WP2Shell ایمن می‌کند؛ این ابزارها جایگزین به‌روزرسانی امنیتی WordPress نیستند.

پس اگر نسخهٔ وردپرس شما آسیب‌پذیر است، حتی در صورت استفاده از Redis یا Memcached، باید آن را در اولین فرصت به‌روز کنید.

چرا زیرساخت هاست هم مهم است؟

فرض کنید یک مهاجم به سایت شما نفوذ کرده است. حالا یک سؤال مهم مطرح می‌شود: آیا دسترسی او فقط به همان سایت محدود می‌شود یا می‌تواند به سایت‌ها و سرویس‌های دیگری که روی همان سرور هستند هم دسترسی پیدا کند؟

اینجاست که زیرساخت هاست اهمیت پیدا می‌کند.

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

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

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

حرف آخر

WP2Shell زنجیره‌ای از دو آسیب‌پذیری در هسته WordPress است که می‌تواند به اجرای کد از راه دور منجر شود. اگر سایتتان در دوره آسیب‌پذیری روی نسخه‌های درگیر بوده، فقط به آپدیت اکتفا نکنید و نشانه‌های نفوذ را هم بررسی کنید.

برای پیشگیری هم WordPress را به‌روز نگه دارید و در کنار آن از لایه‌هایی مثل WAF، پشتیبان‌گیری، کنترل دسترسی و ایزوله‌سازی هاست استفاده کنید.

اگر درباره آسیب‌پذیری WP2Shell یا امنیت سایت وردپرسی‌تان سؤالی دارید، در بخش نظرات برایمان بنویسید.