وردپرس بدذات نیست — رهاشده است. هسته به‌ندرت مسیر نفوذ است؛ افزونهها، قالب‌ها و حسابهای مدیر هستند که سایت را باز می‌گذارند. ما پیش از ربات‌ها سراغشان می‌رویم.
پیش از فهرست خدمات، یک واقعیت که تعیین‌کننده‌ی کل رویکرد ماست: سایت‌های وردپرسی تقریباً هرگز از راه هسته‌ی وردپرس هک نمی‌شوند. هسته توسط تیمی بزرگ نگهداری میشود، وصله‌های امنیتی سریع منتشر میشوند و بهروزرسانی خودکار نسخه‌های امنیتی به‌صورت پیش‌فرض فعال است. مسیر نفوذ تقریباً همیشه یکی از این‌هاست: افزونه یا قالب وصلهنشده، افزونه یا قالب «نالشده» با در پشتی از پیش کاشتهشده، یا رمز ضعیف حساب مدیر.
به زبان استاندارد، این دقیقاً همان چیزی است که OWASP در نسخهی ۲۰۲۵ فهرست ده‌گانه‌ی خود زیر عنوان A03:2025 Software Supply Chain Failures قرار داده است: شکست در فرایند ساخت، توزیع یا بهروزرسانی نرمافزار. یک سایت وردپرسی معمولی بین ۱۵ تا ۴۰ قطعه کد از نویسندگان مختلف اجرا میکند که هیچ‌کدام تحت کنترل شما نیستند؛ امنیت وردپرس عملاً یعنی مدیریت همین زنجیره‌ی تأمین.
باور غلط رایج: «وردپرس ذاتاً ناامن است.» وردپرس بیشترین سهم بازار سیستم‌های مدیریت محتوا را دارد، پس بیشترین تعداد حادثه هم به نامش ثبت میشود — اما این نسبت، نه ذات. سایت وردپرسیِ به‌روز، با افزونههای محدود و منتخب، احراز هویت دومرحله‌ای و پشتیبان آزموده‌شده، از بسیاری از سامانه‌های اختصاصیِ رهاشده امن‌تر است. راهنمای کامل را در امنیت وردپرس نوشته‌ایم.
فهرست کامل هر افزونه و قالب نصبشده — فعال و غیرفعال — با نسخه، تاریخ آخرین بهروزرسانی، وضعیت نگهداری و انطباق با آسیب‌پذیری‌های شناختهشده. افزونه‌ای که دو سال بهروزرسانی نشده، حتی اگر امروز CVE ثبت‌شده‌ای نداشته باشد، یک ریسک است.
سپس آزمون دستی نقاط حساس: فرم‌های عمومی، آپلود فایل، نقاط انتهایی REST API، پارامترهای شناسه‌دار و ماتریس نقش‌های کاربری — همان چیزی که در کنترل دسترسی بررسی میشود.
بهروزرسانی امن (ابتدا در محیط تست)، حذف افزونههای نالشده و بلااستفاده، غیرفعال کردن ویرایشگر فایل پیشخوان، محدودسازی تلاش‌های ورود و فعال‌سازی احراز هویت چندعاملی برای همه‌ی حسابهای مدیر — نه فقط حساب اصلی.
در سطح فایل: اصلاح مجوزهای دسترسی، جلوگیری از اجرای PHP در پوشه‌ی آپلود، محافظت از wp-config.php و جابه‌جایی کلیدهای امنیتی، مسدودسازی فهرست‌شدن دایرکتوری‌ها و حذف فایل‌های پشتیبان و آرشیو از مسیر عمومی.
و کنترل سطح در معرض: بستن یا محدود کردن XML-RPC (که برای حملات انبوه رمز و تقویت درخواست سوءاستفاده میشود)، محدود کردن نقاط انتهایی REST API که فهرست کاربران را برمی‌گردانند، و جلوگیری از شمارش نام کاربری از راه author=۱ و پیام‌های خطای ورود.
اگر آلوده شده‌اید: حذف درهای پشتی و کدهای تزریق‌شده، بررسی حسابهای مدیر ناشناس و وظایف زمان‌بندی‌شده‌ی مشکوک، و مقایسه‌ی فایل‌های هسته با نسخهی رسمی.
اما ترتیب مهم است: اول مسیر نفوذ، بعد پاکسازی. پاکسازی بدون یافتن راه ورود یعنی همان هک چند روز بعد تکرار میشود. فرایند کامل پاکسازی و بازگشت به نتایج سالم گوگل را ببینید.
امنیت وردپرس یک پروژه‌ی یک‌باره نیست: افزونه‌ای که امروز امن است، ماه بعد ممکن است آسیبپذیری اعلام‌شده داشته باشد. نگهداری شامل رصد هشدارهای امنیتی اجزایی است که واقعاً روی سایت شما نصب‌اند، اعمال بهروزرسانی ابتدا در محیط تست، و گزارش ماهانه‌ی وضعیت.
پشتیبانگیری هم بخشی از همین است — با یک شرط: پشتیبانی که هرگز بازگردانده نشده، پشتیبان نیست. دستکم فصلی یکبار یک بازگردانی واقعی روی محیط تست انجام میشود.
فروشگاه علاوه بر مسائل وردپرس، ریسکهای خاص خود را دارد: افزونههای درگاه پرداخت و نحوه‌ی اعتبارسنجی بازگشت از درگاه، دستکاری قیمت و مقدار در سبد خرید، سوءاستفاده از کد تخفیف و شرایط رقابتی در ثبت سفارش، و دسترسی به اطلاعات سفارش سایر مشتریان.
این‌ها آسیبپذیری منطق کسب‌وکارند و هیچ اسکنر یا افزونهی امنیتی پیدایشان نمی‌کند. توضیح بیشتر در امنیت فروشگاه اینترنتی.
روی هاست اشتراکی، آلودگی می‌تواند از یک سایت همسایه منتقل شود؛ در نصب چندسایتی، یک افزونهی آسیب‌پذیر روی همه‌ی سایت‌ها اثر میگذارد. جداسازی حساب‌ها، بررسی مجوزهای متقاطع و ارزیابی این‌که یک نفوذ تا کجا گسترش می‌یابد، بخشی از ارزیابی است.
مواردی که در بیشتر ارزیابی‌های وردپرس با آن‌ها روبه‌رو می‌شویم:
فهرست کامل‌تر با شرح هر مورد در آسیب‌پذیری‌های وردپرس آمده است.
پرسش‌هایی که مدیران سایت‌های وردپرسی پیش از سفارش ارزیابی می‌پرسند.
افزونهی امنیتی لایهی مفیدی است اما جای ارزیابی را نمیگیرد: روی سایتی که افزونهی وصلهنشده یا قالب نالشده دارد، مثل قفل گران روی درِ باز عمل میکند. این افزونهها معمولاً یک فایروال برنامه در سطح PHP اجرا میکنند که الگوهای شناختهشده را میبیند، اما نسبت به نقص کنترل دسترسی، منطق کسبوکار و درِ پشتیِ از قبل کاشتهشده نابیناست — چون آن درخواستها کاملاً معتبر به نظر میرسند.
پاکسازی کار پس از حادثه است: حذف بدافزار، بستن مسیر نفوذ و بازگرداندن سایت به وضعیت سالم. امنسازی کار پیش از حادثه است: کاهش سطح حمله تا نفوذ اصلاً رخ ندهد. اگر سایت شما همین حالا علائم آلودگی دارد — ریدایرکت ناخواسته، کاربر مدیر ناشناس، صفحات اسپم در گوگل — از پاکسازی سایت هک شده شروع کنید. اگر نه، امنسازی به‌مراتب ارزان‌تر است. نکته‌ی مهم: هر پاکسازی باید با امنسازی تمام شود، وگرنه چرخه تکرار میشود.
خطرناکاند و این تنها موردی است که در آن قاطع صحبت میکنیم. نسخهی نالشده یعنی کسی کد را تغییر داده تا بررسی لایسنس را بردارد — و همان فرد در موقعیت کامل بود که هر چیز دیگری هم اضافه کند. الگوی رایج، کدی است که در ظاهر کار میکند اما یک حساب مخفی میسازد، لینک تزریق میکند یا مسیر اجرای کد از راه دور باز میگذارد. این دقیقاً مصداق A03:2025 است: دریافت نرمافزار از منبعی که قابل اعتماد و قابل راستیآزمایی نیست. اجزا را فقط از مخزن رسمی وردپرس یا سایت خود توسعهدهنده دریافت کنید.
بستگی دارد و پاسخ مطلق ندارد. XML-RPC برای اپلیکیشن موبایل وردپرس، پینگ‌بک و برخی افزونههای یکپارچه‌سازی استفاده میشود؛ اگر هیچ‌کدام را لازم ندارید، بستن کامل ساده‌ترین و امن‌ترین کار است. اگر لازم دارید، متد system.multicall که امکان امتحان صدها رمز در یک درخواست را می‌دهد باید غیرفعال و دسترسی محدود شود. تصمیم باید بر اساس کاربرد واقعی سایت شما گرفته شود، نه یک توصیهی کلی اینترنتی.
گزارش دوسطحی شامل: فهرست کامل اجزای نصبشده با وضعیت آسیبپذیری هرکدام، یافتههای آزمون دستی با گامهای بازتولید و شمارهی CWE و شدت، فهرست تغییرات امنسازی اعمالشده، وضعیت پشتیبانگیری و نتیجهی آزمون بازگردانی، و یک برنامهی نگهداری پیشنهادی. پس از رفع، یافتهها دوباره آزمون و وضعیتشان ثبت میشود.
ممیزی کامل را دستکم سالی یکبار و علاوه بر آن پس از هر تغییر مهم انجام دهید: تعویض قالب، افزودن افزونهی جدید بهویژه افزونههای فرم و پرداخت، مهاجرت هاست، یا اضافه شدن نقش کاربری تازه. اما بین دو ممیزی، سه کار باید ماهانه انجام شود: اعمال بهروزرسانیهای امنیتی، بررسی حسابهای مدیر و آزمون بازگردانی پشتیبان. بیشتر سایتهایی که هک میشوند، سالی یک بار ارزیابی شده بودند اما شش ماه بهروزرسانی نشده بودند.
لزوماً نه. اگر روی وردپرس منطق اختصاصی نوشتهاید — درگاه پرداخت سفارشی، پنل کاربری با چند نقش، API برای اپلیکیشن موبایل — آن کد اختصاصی خارج از دامنهی یک ممیزی استاندارد وردپرس است و به تست نفوذ وب کامل با پوشش OWASP WSTG نیاز دارد. در جلسهی نیازسنجی همین را روشن میکنیم و اگر ارزیابی وردپرس برای شما کافی نیست، صریح میگوییم.
خیر. ارزیابی بدون اختلال انجام میشود و تغییرات پرریسک ابتدا در محیط تست (Staging) اعمال و سپس منتقل میشوند. پیش از هر تغییر، یک پشتیبان کامل از فایلها و پایگاه داده گرفته میشود و بهروزرسانیهای بزرگ در ساعت کمترافیک و با امکان بازگشت فوری انجام میگیرند.
چون مسیر نفوذ بسته نشده یا یک در پشتی باقی مانده است. ما پیش از پاکسازی، ریشه‌ی نفوذ را از لاگ‌های دسترسی و خطای سرور پیدا میکنیم؛ وگرنه هک تکرار میشود. رمزها هم باید همگی چرخانده شوند — پیشخوان، هاست، FTP/SSH و پایگاه داده — چون مهاجمی که یک بار به فایلها رسیده، اطلاعات اتصال داخل wp-config.php را هم دیده است.
بله — و توصیهی جدی ماست: فروشگاههای ووکامرس علاوه بر مسائل وردپرس، ریسکهای پرداخت و دادهی مشتری هم دارند.
ارزیابی، امنسازی و نگهداری تخصصی وردپرس با تیم پی‌هانتر. اگر سایت شما فراتر از وردپرس استاندارد است، تست نفوذ وب گزینه‌ی درست‌تری است — در جلسهی رایگان همین را مشخص میکنیم.