باگ اجرای کد از راه دور در وردپرس هنگام آپدیت هسته (CVE-2026-119977)؛ کدام نسخه‌ها آسیب‌پذیرند و چطور وصله کنیم
چه اتفاقی افتاده است؟
تیم امنیتی وردپرس در ۲۸ اکتبر ۲۰۲۶ (۶ آبان ۱۴۰۵) نسخه ۷.۱.۴ را منتشر کرد تا یک آسیب‌پذیری بحرانی به نام CVE-2026-119977 را برطرف کند. این باگ را اوموت بایرام از شرکت امنیتی Picus Security گزارش کرده است.
ماهیت مشکل یک وضعیت رقابتی زمان بررسی/زمان استفاده (TOCTOU) است: وقتی وردپرس در حالت آپدیت کامل بسته هسته (full-package core upgrade) قرار می‌گیرد، فایل‌های جدید را در یک پوشه موقت زیر مسیر wp-content/upgrade/ باز می‌کند. مسیر این پوشه موقت قابل پیش‌بینی و در عین حال از طریق وب در دسترس است. یک مهاجم ناشناس که در همان بازه کوتاه آپدیت درخواست‌هایی به این مسیر ارسال کند، می‌تواند به اجرای کد از راه دور (RCE) روی سرور دست پیدا کند.
نکتهٔ مهم: این حمله به احراز هویت یا تعامل کاربر نیاز ندارد، اما وابسته به زمان‌بندی است و فقط در لحظه‌ای که سایت در حال اجرای یک آپدیت کامل هسته است ممکن می‌شود؛ نه در هر لحظه‌ای از عمر سایت.
روز ۳ نوامبر ۲۰۲۶، آژانس امنیت سایبری آمریکا (CISA) این آسیب‌پذیری را به فهرست آسیب‌پذیری‌های فعالانه مورد سوءاستفاده (KEV) اضافه کرد و بر اساس مشاهدات، بهره‌برداری فعال از این باگ از حدود ۳۰ اکتبر ۲۰۲۶ آغاز شده بود. مهلت وصله برای سازمان‌های فدرال آمریکا ۶ نوامبر ۲۰۲۶ تعیین شده است؛ این مهلت نشان‌دهنده جدیت مشکل است، نه اینکه فقط نهادهای دولتی باید اقدام کنند.
چه نسخه‌هایی آسیب‌پذیرند؟
تمام شاخه‌های وردپرس از ۴.۷.۰ تا ۷.۱.۳ آسیب‌پذیر هستند، یعنی عملا هر نسخه وردپرس منتشرشده در طول حدود ده سال گذشته که هنوز به نسخه وصله‌شدهٔ شاخهٔ خودش ارتقا نیافته باشد.
| شاخه نسخه | تا نسخه آسیب‌پذیر | نسخه وصله‌شده |
|---|---|---|
| ۷.۱ | ۷.۱.۳ | ۷.۱.۴ |
| ۷.۰ | ۷.۰.۷ | ۷.۰.۸ |
| ۶.۹ | ۶.۹.۱۰ | ۶.۹.۱۱ |
| ۶.۸ | ۶.۸.۱۱ | ۶.۸.۱۲ |
| ۶.۷ | ۶.۷.۱۰ | ۶.۷.۱۱ |
| ۶.۶ | ۶.۶.۱۰ | ۶.۶.۱۱ |
| ۶.۵ | ۶.۵.۱۳ | ۶.۵.۱۴ |
| ۶.۴ | ۶.۴.۱۳ | ۶.۴.۱۴ |
| ۶.۳ | ۶.۳.۱۳ | ۶.۳.۱۴ |
| ۶.۲ | ۶.۲.۱۴ | ۶.۲.۱۵ |
| ۶.۱ | ۶.۱.۱۵ | ۶.۱.۱۶ |
| ۶.۰ | ۶.۰.۱۷ | ۶.۰.۱۸ |
| ۵.۸ و پایین‌تر | — | به نسخه وصله‌شدهٔ همان شاخه (مثلا ۵.۸.۱۹، ۵.۷.۲۱، ۵.۰.۳۱، ۴.۷.۳۹ و...) |
اگر سایت شما روی نسخه ۵.۹ یا هر یک از شاخه‌های قدیمی‌تر از ۴.۷ تا ۵.۸ است، در فهرست رسمی وردپرس (لینک در بخش منابع) نسخه وصله‌شدهٔ دقیق همان شاخه ذکر شده؛ در هر صورت راه‌حل یکسان است: ارتقا به آخرین نسخه موجود در همان شاخه یا به‌طور کلی به ۷.۱.۴.
این باگ چقدر خطرناک است؟
شدت این آسیب‌پذیری CVSS 8.1 (بالا) با بردار CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H ثبت شده و در دو دسته‌بندی قرار می‌گیرد:
- CWE-367 — وضعیت رقابتی زمان بررسی/زمان استفاده (TOCTOU)
- CWE-552 — دسترسی طرف‌های خارجی به فایل‌ها یا پوشه‌هایی که نباید در دسترس باشند
ترکیب «نیازی به احراز هویت نیست» و «تأیید شده در فهرست KEV» باعث می‌شود این مورد را نباید به تعویق انداخت، حتی اگر شرط زمانی (وابسته به لحظهٔ آپدیت) احتمال سوءاستفاده تصادفی را کمی پایین بیاورد.
چطور وضعیت سایت خودم را بررسی کنم؟
چند راه ساده برای فهمیدن نسخهٔ فعلی وردپرس:
از طریق پیشخان مدیریت
وارد wp-admin شوید و پایین صفحهٔ «داشبورد» یا بخش «به‌روزرسانی‌ها» نسخهٔ فعلی را نشان می‌دهد.
از طریق WP-CLI (اگر به سرور دسترسی SSH دارید)
wp core version
آموزش کامل‌تر نصب و مدیریت وردپرس با WP-CLI را هم ببینید.
از طریق فایل نسخه در هسته
grep "wp_version =" wp-includes/version.php
از بیرون سایت، بدون دسترسی سرور
curl -s https://example.com/readme.html | grep -i "Version"
(در بسیاری از سایت‌ها این فایل حذف یا محدود شده، که خودش یک اقدام امنیتی خوب است.)
همچنین ارزش دارد لاگ دسترسی وب‌سرور را برای درخواست‌های غیرعادی به مسیر wp-content/upgrade/ بررسی کنید، به‌خصوص اگر اخیرا یک آپدیت کامل هسته روی سایت اجرا شده باشد:
grep "wp-content/upgrade" /var/log/nginx/access.log
چطور وصله یا مقابله کنیم؟
- اولویت اول: ارتقا به ۷.۱.۴ (یا نسخهٔ وصله‌شدهٔ همان شاخه). بسیاری از سایت‌ها این آپدیت را به‌صورت خودکار از طریق «به‌روزرسانی‌های پس‌زمینه» وردپرس دریافت می‌کنند؛ از بخش «به‌روزرسانی‌ها» در پیشخان مطمئن شوید که این فرایند کامل شده است.
- اگر ارتقای فوری ممکن نیست، به‌عنوان راه‌حل موقت، دسترسی HTTP به مسیر
wp-content/upgrade/را در سطح وب‌سرور مسدود کنید. وردپرس برای کار کردن با این مسیر فقط به دسترسی فایل‌سیستمی نیاز دارد، نه دسترسی از طریق وب، بنابراین مسدود کردن آن چیزی را خراب نمی‌کند.
نمونه قانون در Nginx:
location ^~ /wp-content/upgrade/ {
deny all;
return 403;
}
- یک قانون فایروال وب (WAF) را جایگزین نصب آپدیت نکنید — مسدودسازی موقت مسیر فقط یک پل زمانی است، نه راه‌حل نهایی. اگر هنوز روی سرورتان فایروال سطح سیستم‌عامل ندارید، راه‌اندازی فایروال nftables نقطهٔ شروع خوبی است.
اگر مدیریت وردپرس روی هاست اشتراکی برایتان محدودیت ایجاد می‌کند — مثلا نمی‌توانید تنظیمات Nginx را شخصی‌سازی کنید یا زمان دقیق اجرای آپدیت پس‌زمینه را کنترل کنید — داشتن یک سرور مجازی اختصاصی این کنترل را به شما برمی‌گرداند: می‌توانید پیش از هر آپدیت حساس یک snapshot بگیرید، قوانین فایروال خودتان را تعریف کنید و خودتان زمان‌بندی آپدیت‌ها را مدیریت کنید، بدون وابستگی به تنظیمات پیش‌فرض هاست. تفاوت دو حالت را در وردپرس روی سرور ابری یا هاست اشتراکی؟ با جزئیات بیشتر می‌بینید.
برای سخت‌سازی کلی وردپرس فراتر از این یک آسیب‌پذیری، چک‌لیست امنیت و سخت‌سازی وردپرس را هم بررسی کنید.
سؤالات متداول
آیا همهٔ سایت‌های وردپرسی که آپدیت نکرده‌اند هک شده‌اند؟ نه. سوءاستفاده فقط در بازهٔ زمانی اجرای یک آپدیت کامل هسته ممکن است، نه در هر لحظه. اما چون حمله به احراز هویت نیاز ندارد و در فهرست KEV ثبت شده، باید سریع وصله کنید.
آیا پلاگین‌ها یا قالب‌ها هم در این آسیب‌پذیری نقش دارند؟ نه، این باگ فقط در کد هسته (WordPress Core) است و به پلاگین یا قالب خاصی مربوط نمی‌شود.
بعد از ارتقا به ۷.۱.۴ چه کار دیگری لازم است؟
بررسی کنید مسیر wp-content/upgrade/ خالی باشد و لاگ‌های دسترسی وب‌سرور را برای فعالیت‌های مشکوک در روزهای اخیر مرور کنید، به‌خصوص بین ۳۰ اکتبر تا تاریخ ارتقای شما.
اگر نمی‌توانم همین حالا آپدیت کنم چه کار کنم؟
مسیر wp-content/upgrade/ را در سطح وب‌سرور مسدود کنید (نمونه در بالا) تا زمانی که بتوانید ارتقا را کامل انجام دهید.
منابع
- اعلامیه رسمی وردپرس — انتشار نسخه ۷.۱.۴
- صفحه مستندات نسخه ۷.۱.۴
- فهرست آسیب‌پذیری‌های فعالانه مورد سوءاستفاده CISA (KEV)
- جزئیات فنی CVE-2026-119977 — Strix.ai
- رکورد CVE-2026-119977 — OpenCVE
برای کنترل کامل روی آپدیت‌ها، snapshot و فایروال سرور، سرور مجازی آریانت را بررسی کنید
