هشدار امنیتی وردپرس: آسیب‌پذیری SQL Injection با شناسه CVE-2026-60137؛ روش تشخیص و رفع

CVE-2026-60137 چیست؟

CVE-2026-60137 یک آسیب‌پذیری تزریق SQL در هسته وردپرس است. منشأ آن به نحوه پردازش آرگومان author__not_in در کلاس WP_Query مربوط می‌شود؛ آرگومانی که باید فهرستی از شناسه‌های عددی نویسندگان را دریافت کند و نوشته‌های آن نویسندگان را از نتیجه کنار بگذارد.

براساس مستندات رسمی توسعه‌دهندگان وردپرس، ورودی صحیح این پارامتر آرایه‌ای از شناسه‌های عددی است؛ برای نمونه:

$query = new WP_Query(
    array(
        'author__not_in' => array( 2, 6 )
    )
);

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

شرح این آسیب‌پذیری و نسخه‌های درگیر در پایگاه ملی آسیب‌پذیری‌های NIST، هشدار امنیتی رسمی پروژه WordPress و اطلاعیه انتشار WordPress 7.0.2 ثبت شده است.

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

نسخه آزمایشی WordPress 7.1 Beta 1 نیز درگیر بوده و اصلاح آن در Beta 2 منتشر شده است. نسخه‌های بتا نباید روی سایت عملیاتی استفاده شوند.

چرا خطر در وردپرس ۶.۹ و ۷.۰ بیشتر است؟

خود CVE-2026-60137 یک SQL Injection تسهیل‌شده است؛ یعنی برای قابل‌بهره‌برداری‌شدن آن باید ورودی کنترل‌نشده به author__not_in برسد. بااین‌حال، در وردپرس ۶.۹ و نسخه‌های بعد از آن، این ضعف می‌تواند با آسیب‌پذیری جداگانه CVE-2026-63030 در REST API ترکیب شود. هشدار رسمی پروژه وردپرس نتیجه این زنجیره را «اجرای کد از راه دور» یا RCE اعلام کرده است.

به زبان ساده:

• وردپرس ۶.۸: آسیب‌پذیری SQL Injection وجود دارد، اما برای بهره‌برداری باید افزونه یا قالبی ورودی کنترل‌نشده را به پارامتر آسیب‌پذیر برساند.
• وردپرس ۶.۹ و ۷.۰: علاوه بر SQL Injection، ضعف REST API نیز وجود دارد و ترکیب این دو می‌تواند به اجرای کد روی سرور منجر شود.

جزئیات زنجیره دوم در هشدار رسمی CVE-2026-63030 منتشر شده است.

نکته درباره شدت: منابع مختلف امتیازهای متفاوتی برای CVE-2026-60137 نمایش می‌دهند. هشدار GitHub پروژه وردپرس شدت مستقل آن را Moderate ثبت کرده است؛ صفحه NVD نیز در زمان آخرین بررسی، امتیاز ۵.۹ از WPScan و امتیاز ۹.۱ از CISA-ADP را نمایش می‌داد و هنوز امتیاز مستقل NVD را ارائه نکرده بود. این تفاوت نشان می‌دهد که نباید تصمیم به به‌روزرسانی را فقط بر اساس یک عدد گرفت. نسخه، وجود مسیر قابل‌بهره‌برداری و امکان ترکیب با CVE دوم مهم‌ترند.

کوئری مشکوک چگونه شناسایی می‌شود؟

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

SELECT SQL_CALC_FOUND_ROWS wp_posts.ID
FROM wp_posts
WHERE 1=1
  AND wp_posts.post_author NOT IN (
      SELECT IF(1=1, SLEEP(7), 0)
  )
  AND (
      wp_posts.post_type = 'post'
      AND wp_posts.post_status = 'publish'
  )
ORDER BY wp_posts.post_name ASC
LIMIT 0, 10;

لازم نیست کوئری سایت شما دقیقاً با این نمونه یکسان باشد. پیشوند جدول، نوع محتوا، وضعیت نوشته، زمان تأخیر، شرط داخل IF، ترتیب نتایج و مقدار LIMIT می‌توانند تغییر کنند. الگوی عمومی این خانواده از کوئری‌ها چنین است:

SELECT ...
FROM <prefix>posts
WHERE ...
  AND <prefix>posts.post_author NOT IN (
      SELECT IF(
          <condition>,
          SLEEP(<delay_in_seconds>),
          <fallback_value>
      )
  )
...

اثر انگشت اصلی این نمونه حمله عبارت زیر است:

post_author NOT IN ( SELECT ... SLEEP(...) )

در حالت عادی، داخل NOT IN باید فقط شناسه‌های عددی نویسندگان قرار داشته باشد؛ برای مثال:

post_author NOT IN (2, 6, 15)

وجود SELECT، IF، SLEEP یا توابع غیرمنتظره در این بخش، نشانه جدی تزریق SQL است. در نمونه بالا، شرط 1=1 همیشه درست است و در نتیجه MySQL به مدت هفت ثانیه مکث می‌کند. مهاجم از تفاوت زمان پاسخ برای تشخیص این موضوع استفاده می‌کند که آیا ورودی او واقعاً به دیتابیس رسیده است یا نه؛ این روش «Blind SQL Injection زمان‌محور» نام دارد.

چه قسمت‌هایی ممکن است تغییر کنند؟

• wp_posts ممکن است با پیشوند سفارشی مانند abc_posts دیده شود.
• SLEEP(7) ممکن است زمان دیگری مانند ۳، ۵ یا ۱۰ ثانیه داشته باشد.
• IF(1=1,...) ممکن است با شرط دیگری جایگزین شود.
• post_type ممکن است post، page، product یا نوع محتوای سفارشی باشد.
• ORDER BY، LIMIT، post_status و ستون‌های انتخاب‌شده ممکن است متفاوت باشند.
• وجود یا نبودن SQL_CALC_FOUND_ROWS برای تشخیص این حمله تعیین‌کننده نیست.

الگوی دفاعی برای جست‌وجو در لاگ SQL

(?is)\bpost_author\s+NOT\s+IN\s*\(\s*SELECT\b.{0,500}?\bSLEEP\s*\(

این عبارت منظم برای پیدا‌کردن نمونه‌های زمان‌محور مشابه در Slow Query Log، General Log یا خروجی ابزار مانیتورینگ دیتابیس مفید است، اما همه روش‌های ممکن تزریق SQL را پوشش نمی‌دهد. مهاجم می‌تواند از تابع، رمزگذاری یا ساختار دیگری استفاده کند؛ بنابراین نبودن این الگو در لاگ، پاک‌بودن قطعی سایت را ثابت نمی‌کند.

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

مشاهده این کوئری یعنی سایت هک شده است؟

نه لزوماً؛ محل مشاهده شواهد اهمیت دارد:

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

بنابراین سه گزاره را باید از هم جدا کرد:

1. تلاش برای حمله: payload در درخواست یا WAF دیده شده، اما اجرای آن در دیتابیس ثابت نشده است.
2. بهره‌برداری موفق از SQL Injection: payload یا اثر زمانی آن در دیتابیس تأیید شده است.
3. نفوذ کامل: شواهدی مانند ایجاد کاربر مدیر، تغییر فایل‌ها، webshell، Cron ناشناس یا اجرای کد مشاهده شده است.

خطرات احتمالی این آسیب‌پذیری چیست؟

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

• خواندن یا استخراج تدریجی اطلاعات دیتابیس؛
• افشای اطلاعات کاربران، تنظیمات سایت یا داده‌های افزونه‌ها؛
• ایجاد بار و کندی در دیتابیس از طریق درخواست‌های زمان‌بر؛
• در سناریوهای ترکیبی وردپرس ۶.۹ و ۷.۰، اجرای کد از راه دور؛
• در صورت دستیابی به اجرای کد، ایجاد کاربر مدیر، تغییر فایل‌ها، نصب در پشتی یا سوءاستفاده از منابع هاست.

مشاهده یک کوئری SLEEP به‌تنهایی اثبات‌کننده تمام این پیامدها نیست. گزارش فنی معتبر باید میان «خطر ممکن» و «اثر مشاهده‌شده» تفاوت بگذارد.

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

از پیشخوان وردپرس

در پیشخوان به مسیر پیشخوان ← به‌روزرسانی‌ها بروید. نسخه نصب‌شده را با جدول بالا مقایسه کنید. اگر نسخه شما ۶.۸.۵، ۶.۹.۴، ۷.۰.۰، ۷.۰.۱ یا هر نسخه پایین‌تر در همان شاخه است، به نسخه اصلاح‌شده ارتقا دهید.

با WP-CLI

wp core version

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

wp core update
wp core verify-checksums

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

اقدامات فوری مدیر سایت

1. شواهد را حفظ کنید: زمان رخداد، منطقه زمانی، IP، URL، شناسه درخواست و خطوط مرتبط Access Log، WAF و دیتابیس را ذخیره کنید. اگر حمله فعال است، حفظ شواهد نباید باعث تأخیر طولانی در مهار و به‌روزرسانی شود.
2. از وضعیت فعلی نسخه پشتیبان بگیرید: یک کپی از فایل‌ها، دیتابیس و لاگ‌ها برای بررسی فنی نگه دارید. این نسخه ممکن است آلوده باشد و نباید بدون بررسی به‌عنوان بکاپ سالم استفاده شود.
3. وردپرس را فوراً به‌روزرسانی کنید: حداقل به ۶.۸.۶، ۶.۹.۵ یا ۷.۰.۲ بروید. استفاده از آخرین نسخه پایدار و پشتیبانی‌شده انتخاب بهتری است.
4. موفقیت به‌روزرسانی را بررسی کنید: وردپرس اعلام کرده برای نسخه‌های آسیب‌پذیر به‌روزرسانی اجباری خودکار فعال شده است، اما نباید فرض کنید عملیات حتماً موفق بوده؛ نسخه نصب‌شده را مستقیماً کنترل کنید.
5. افزونه‌ها و قالب‌ها را به‌روزرسانی کنید: به‌خصوص افزونه یا قالبی را که پارامترهای نویسنده، فهرست نوشته‌ها، جست‌وجو یا REST API را پردازش می‌کند بررسی کنید. از روی نام افزونه حدس نزنید؛ مسیر درخواست و زمان اجرای کوئری را با لاگ‌ها تطبیق دهید.
6. نشانه‌های ماندگاری مهاجم را جست‌وجو کنید: کاربران مدیر جدید، تغییرات غیرمنتظره فایل‌ها، فایل PHP در پوشه uploads، افزونه‌های ناشناس، Must-Use Pluginهای جدید، Cronهای غیرعادی و تغییر در wp-config.php را بررسی کنید.
7. در صورت وجود شواهد بهره‌برداری، دسترسی‌ها را تعویض کنید: رمز مدیران وردپرس، پنل هاست، FTP/SFTP/SSH و دیتابیس را تغییر دهید و کلیدهای امنیتی وردپرس را نوسازی کنید. تغییر رمز دیتابیس باید هم‌زمان با اصلاح اطلاعات اتصال در wp-config.php انجام شود.
8. در صورت تأیید نفوذ، از بکاپ سالم بازیابی کنید: بکاپی را انتخاب کنید که قبل از اولین رخداد مشکوک ایجاد شده باشد. پیش از بازگرداندن سایت به حالت آنلاین، وردپرس، افزونه‌ها و قالب‌ها را در محیط ایزوله به‌روزرسانی کنید.
9. مانیتورینگ را ادامه دهید: پس از اصلاح، لاگ‌ها و مصرف دیتابیس را برای تکرار payload، تأخیرهای غیرعادی و نشانه‌های دسترسی مجدد زیر نظر بگیرید.

وظیفه مدیر سایت چیست و وظیفه شرکت هاستینگ چیست؟

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

مسدودکردن یک IP، متوقف‌کردن یک پردازش MySQL یا افزودن یک قانون WAF فقط اقدام موقت برای مهار است. این کارها آسیب‌پذیری را از بین نمی‌برند؛ اصلاح اصلی، نصب نسخه امن وردپرس است. از سوی دیگر، به‌روزرسانی هسته نیز به‌تنهایی ثابت نمی‌کند که سایت پیش از اصلاح مورد نفوذ قرار نگرفته است.

برای بررسی رخداد چه اطلاعاتی به پشتیبانی هاست بدهیم؟

گزارش مبهمی مانند «سایت من هک شده» امکان بررسی دقیق را کم می‌کند. حداقل این اطلاعات را ارسال کنید:

• نام دامنه و نام کاربری هاست؛
• نسخه وردپرس در زمان رخداد و نسخه فعلی؛
• زمان دقیق مشاهده با ذکر منطقه زمانی؛
• IP یا Request ID مشکوک، در صورت وجود؛
• URL و متد درخواست، اگر در لاگ ثبت شده است؛
• نمونه کامل کوئری یا چند خط لاگ قبل و بعد از آن؛
• محل مشاهده شواهد: Processlist، Slow Log، WAF، Access Log یا ابزار مانیتورینگ؛
• هر تغییر مشاهده‌شده در فایل‌ها، کاربران یا Cronها.

رمز عبور، کلید خصوصی، محتوای کامل wp-config.php یا اطلاعات حساس مشتریان را داخل تیکت عادی ارسال نکنید؛ فقط از مسیر امنی که شرکت میزبانی مشخص کرده استفاده کنید.

پرسش‌های متداول

آیا همه سایت‌های وردپرسی به CVE-2026-60137 آسیب‌پذیرند؟

خیر. نسخه‌های ۶.۸.۰ تا ۶.۸.۵، ۶.۹.۰ تا ۶.۹.۴ و ۷.۰.۰ تا ۷.۰.۱ درگیرند. نسخه‌های قبل از ۶.۸ طبق اعلام رسمی وردپرس از این CVE مشخص تأثیر نمی‌پذیرند. برای بهره‌برداری مستقل از SQL Injection نیز باید مسیری وجود داشته باشد که ورودی کنترل‌نشده را به author__not_in برساند.

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

نسخه‌های اصلاح‌شده ۶.۸.۶، ۶.۹.۵ و ۷.۰.۲ هستند. در عمل بهتر است آخرین نسخه پایدار و پشتیبانی‌شده وردپرس را نصب کنید.

آیا دیدن SLEEP در کوئری وردپرس یعنی اطلاعات سرقت شده است؟

خیر. SLEEP در نمونه نشان‌دهنده آزمون Blind SQL Injection زمان‌محور است و مستقیماً داده‌ای را نمی‌خواند یا تغییر نمی‌دهد. اجرای موفق آن نشان می‌دهد مهاجم توانسته رفتار کوئری را کنترل کند؛ برای تشخیص استخراج اطلاعات یا نفوذ کامل باید شواهد بیشتری بررسی شود.

اگر کوئری فقط در Access Log دیده شود، حمله موفق بوده است؟

نه لزوماً. ثبت payload در Access Log یا WAF ممکن است فقط نشان‌دهنده تلاش باشد. مشاهده کوئری ساخته‌شده در MySQL Processlist، Slow Query Log، General Log یا Audit Log شواهد قوی‌تری از رسیدن آن به دیتابیس است.

آیا فعال‌بودن به‌روزرسانی خودکار کافی است؟

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

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

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

پس از به‌روزرسانی، آیا بررسی نفوذ لازم است؟

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

جمع‌بندی

CVE-2026-60137 یک آسیب‌پذیری واقعی در هسته وردپرس است، اما توصیف دقیق آن اهمیت دارد: در سناریوی مستقل، ورودی کنترل‌نشده باید به author__not_in برسد؛ در وردپرس ۶.۹ و ۷.۰، ترکیب آن با آسیب‌پذیری REST API می‌تواند اثر را تا اجرای کد از راه دور افزایش دهد.

اگر نسخه سایت شما در بازه آسیب‌پذیر است، اقدام درست روشن است: همین حالا وردپرس را به نسخه اصلاح‌شده ارتقا دهید، موفقیت به‌روزرسانی را کنترل کنید و لاگ‌ها و نشانه‌های نفوذ را بررسی کنید. مشاهده عبارت post_author NOT IN (SELECT ... SLEEP(...)) در کوئری اجراشده دیتابیس یک هشدار جدی است، ولی باید میان تلاش برای حمله، اجرای موفق SQL Injection و نفوذ کامل تفاوت گذاشت.