آموزش آسیب‌ پذیری WP2Shell در وردپرس چیست و چگونه از آن پیشگیری کنیم؟

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

فهرست مطالب

• WP2Shell چیست و چگونه کار می‌کند؟
• کدام نسخه‌های وردپرس آسیب‌پذیر هستند؟
• خطرات WP2Shell برای سایت چیست؟
• چگونه وضعیت سایت را بررسی کنیم؟
• روش پیشگیری از آسیب‌پذیری WP2Shell
• نشانه‌های احتمالی نفوذ
• اقدامات لازم پس از مشاهده آلودگی
• چک‌لیست امنیتی مدیر سایت
• جمع‌ بندی
• سؤالات متداول

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

WP2Shell نام یک افزونه یا فایل مشخص در وردپرس نیست. این عبارت به زنجیره‌ای از دو نقص امنیتی در هسته وردپرس اشاره دارد که با شناسه‌های CVE-2026-60137 و CVE-2026-63030 ثبت شده‌اند.

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

تیم وردپرس در انتشار امنیتی 7.0.2 تأیید کرده است که این به‌روزرسانی یک مشکل با شدت بحرانی و یک مشکل با شدت بالا را برطرف می‌کند. به دلیل اهمیت موضوع، به‌روزرسانی اجباری برای برخی سایت‌های دارای نسخه آسیب‌ پذیر نیز فعال شد. اطلاعیه رسمی انتشار WordPress 7.0.2

WP2Shell چگونه به تصرف سایت منجر می‌شود؟

برای درک خطر، نیازی به بررسی کد یا جزئیات قابل سوءاستفاده حمله نیست. مسیر کلی حمله را می‌توان در چهار مرحله خلاصه کرد:

1. مهاجم درخواست دست‌کاری‌شده‌ای به REST API سایت ارسال می‌کند.
2. نقص مسیریابی درخواست‌های گروهی باعث می‌شود بخشی از درخواست برخلاف محدودیت مورد انتظار پردازش شود.
3. مهاجم از ضعف تزریق SQL برای تأثیرگذاری بر داده‌ها یا ایجاد زمینه دسترسی مدیریتی استفاده می‌کند.
4. پس از دستیابی به نقش مدیر، امکان نصب افزونه مخرب، ایجاد در پشتی، تغییر محتوا یا اجرای کد روی هاست فراهم می‌شود.

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

راهنمای افزایش امنیت وردپرس» ← مقاله آموزش امنیت وردپرس

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

کدام نسخه‌های ورد پرس در برابر WP2Shell آسیب‌ پذیرهستند؟

براساس اطلاعیه رسمی وردپرس، نسخه‌های شاخه 6.9 تحت تأثیر هر دو نقص قرار گرفته‌اند و نسخه 6.9.5 اصلاحات مربوط به هر دو را دریافت کرده است. نسخه‌های شاخه 7.0 تا قبل از 7.0.2 نیز باید به نسخه اصلاح‌شده ارتقا پیدا کنند.

شاخه 6.8 فقط در برابر نقص تزریق SQL مرتبط با CVE-2026-60137 آسیب‌پذیر بود و اصلاح آن در نسخه 6.8.6 منتشر شد. وردپرس همچنین اعلام کرده است نسخه‌های پیش از 6.8 تحت تأثیر این دو مورد مشخص نیستند؛ بااین‌حال، قدیمی بودن یک نسخه به معنای امن‌بودن آن در برابر سایر آسیب‌پذیری‌ها نیست.

این اطلاعات بر مبنای اعلام رسمی تیم وردپرس در زمان نگارش مقاله است. برای تصمیم‌گیری نهایی باید نسخه فعلی سایت و جدیدترین اطلاعیه امنیتی WordPress.org بررسی شود.

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

مشاهده سرویس‌های هاست وردپرس» ← صفحه خدمات هاست وردپرس

WP2Shell چه خطراتی برای سایت ایجاد می‌کند؟

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

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

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

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

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

مرحله اول: تهیه نسخه پشتیبان

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

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

آموزش بکاپ‌گیری از سایت وردپرسی» ← مقاله تهیه نسخه پشتیبان از وردپرس]

مرحله دوم: مشاهده نسخه وردپرس

پس از ورود به پیشخوان، به مسیر «پیشخوان ← به‌روزرسانی‌ها» بروید. نسخه نصب‌شده در این صفحه نمایش داده می‌شود و در صورت وجود نسخه جدید، گزینه به‌روزرسانی در دسترس خواهد بود.

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

مرحله سوم: بررسی کامل‌شدن به‌ روزرسانی

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

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

چگونه از آسیب‌پذیری WP2Shell پیشگیری کنیم؟

۱. هسته وردپرس را فوراً به‌ روزرسانی کنید

مؤثرترین اقدام، ارتقای هسته به نسخه اصلاح‌ شده یا نسخه پایدار جدیدتر است. سایت‌های شاخه 7.0 باید حداقل نسخه 7.0.2، سایت‌های شاخه 6.9 حداقل نسخه 6.9.5 و سایت‌های شاخه 6.8 حداقل نسخه 6.8.6 را داشته باشند.

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

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

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

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

۳. از WAF به‌ عنوان لایه مکمل استفاده کنید

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

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

فایروال وب چیست و چگونه کار می‌کند؟» ← مقاله معرفی WAF]

۴. حساب‌های مدیر را محدود کنید

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

فعال‌کردن احراز هویت دومرحله‌ای برای مدیران همچنان ضروری است. البته 2FA مانع سوءاستفاده اولیه از WP2Shell نمی‌شود، اما از ورود مهاجم با رمز سرقت‌شده و برخی مسیرهای بعدی نفوذ جلوگیری می‌کند.

۵. نصب و ویرایش فایل را محدود کنید

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

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

۶. گزارش‌ها و تغییرات فایل را نگهداری کنید

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

سامانه پایش تغییر فایل می‌تواند ایجاد یا تغییر غیرمنتظره فایل‌های PHP را گزارش کند. البته هر تغییر به معنای آلودگی نیست؛ به‌روزرسانی افزونه، قالب و هسته نیز فایل‌ها را تغییر می‌دهد.

۷. از بکاپ قابل بازیابی استفاده کنید

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

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

نشانه‌های احتمالی آلودگی به WP2Shell

وجود هرکدام از نشانه‌های زیر اثبات قطعی نفوذ نیست، اما بررسی فوری را ضروری می‌کند:

بررسی‌های Wordfence نشان داده است که حملات مرتبط با این زنجیره می‌توانند برای ایجاد حساب مدیریتی جدید استفاده شوند. این منبع همچنین توصیه می‌کند حساب‌های مدیر ناشناس و درخواست‌های ثبت‌شده برای مسیر گروهی REST API بررسی شوند؛ بااین‌حال، نبود این شواهد تضمین نمی‌کند که سایت سالم است. تحلیل فنی WP2Shell توسط Wordfence

اگر سایت آلوده شده باشد چه کار کنیم؟

۱. سایت را ایزوله و شواهد را حفظ کنید

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

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

۲. از یک دستگاه سالم مدیریت را انجام دهید

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

۳. هسته، افزونه‌ها و قالب‌ها را از منابع معتبر جایگزین کنید

فایل‌های هسته وردپرس باید با بسته رسمی و سالم جایگزین شوند. افزونه‌ها و قالب‌ها نیز فقط از مخزن رسمی یا وب‌سایت معتبر توسعه‌دهنده دریافت شوند.

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

۴. تمام دسترسی‌ها را تغییر دهید

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

اگر کلید API یا اطلاعات پرداخت در سایت ذخیره شده است، نحوه چرخش آن باید با ارائه‌دهنده همان سرویس هماهنگ شود.

۵. حساب‌ها و وظایف زمان‌بندی‌شده را بررسی کنید

همه کاربران دارای سطح دسترسی بالا، افزونه‌های فعال، کدهای سفارشی، Cron Jobهای هاست و وظایف WP-Cron را بررسی کنید. مهاجم ممکن است برای حفظ دسترسی از بیش از یک روش استفاده کرده باشد.

۶. سایت را پیش از بازگشت آزمایش کنید

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

خدمات پشتیبانی و رفع آلودگی وردپرس» ← صفحه خدمات پشتیبانی فنی سایت

مثال کاربردی: سایت به‌ روزرسانی شده اما مدیر ناشناس دارد

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

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

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

چک‌ لیست فوری مدیر سایت

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

جمع‌ بندی

در پاسخ به پرسش «آموزش آسیب‌پذیری WP2Shell در وردپرس چیست و چگونه از آن پیشگیری کنیم؟» باید گفت WP2Shell یک زنجیره نقص در هسته وردپرس است، نه یک افزونه مخرب مستقل. این زنجیره از ترکیب تزریق SQL و اشکال پردازش درخواست‌های گروهی REST API استفاده می‌کند و در نسخه‌های آسیب‌پذیر می‌تواند به ایجاد حساب مدیر و اجرای کد منجر شود.

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

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

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

سؤالات متداول

آیا WP2Shell یک افزونه آلوده وردپرس است؟

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

کدام نسخه، آسیب‌پذیری WP2Shell را برطرف می‌کند؟

اصلاح زنجیره کامل در وردپرس 6.9.5 و 7.0.2 ارائه شده است. نقص مرتبط با شاخه 6.8 نیز در نسخه 6.8.6 اصلاح شد. نصب نسخه پایدار جدیدتر توصیه می‌شود.

آیا تغییر رمز مدیر برای جلوگیری از WP2Shell کافی است؟

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

آیا WAF بدون به‌ روزرسانی وردپرس کافی است؟

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

چگونه بفهمیم سایت قبلاً هک شده است؟

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

آیا باید REST API وردپرس را کاملاً غیرفعال کنیم؟

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

آیا بازیابی یک بکاپ قدیمی مشکل را حل می‌کند؟

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