آسیب پذیری بحرانی WordPress 7.0.2؛ راهنمای Patch و بررسی نفوذ

WordPress در 17 ژوئیه 2026 نسخه 7.0.2 را برای اصلاح یک SQL Injection با شدت High و یک Remote Code Execution بدون احراز هویت با شدت Critical منتشر کرد. این راهنما مشخص می کند کدام شاخه ها متاثرند، چگونه بدون از دست رفتن سایت Patch کنید و بعد از ارتقا چه نشانه هایی را برای احتمال نفوذ بررسی کنید.

در یک نگاه

• CVE-2026-60137: SQL Injection با شدت High، از WordPress 6.8 به بعد.
• CVE-2026-63030: Remote Code Execution بدون Login با شدت Critical، از WordPress 6.9 به بعد.
• نسخه های اصلاح شده: 6.8.6، 6.9.5، 7.0.2 و 7.1 Beta 2.
• RCE به Batch Endpoint در REST API و شرایط مربوط به Persistent Object Cache وابسته است.
• Cloudflare برای هر دو آسیب پذیری Rule مسدودکننده منتشر کرده، اما WAF جای Patch را نمی گیرد.
• بعد از Patch باید User، Plugin، File، Scheduled Task، Log و Credentialها بازبینی شوند.

چه اتفاقی افتاد و چه نسخه هایی متاثرند؟

تیم امنیت WordPress نسخه 7.0.2 را در 17 ژوئیه 2026 با اولویت امنیتی بسیار بالا عرضه کرد. اطلاعیه رسمی از یک مشکل SQL Injection و یک مسیر مرتبط در REST API خبر می دهد که می تواند به اجرای کد از راه دور برسد. چون آسیب پذیری Critical بدون احراز هویت و بدون تعامل کاربر قابل بهره برداری توصیف شده، تیم WordPress به روزرسانی اجباری خودکار را برای نصب های متاثر فعال کرده است. این تصمیم نشان می دهد مدیران سایت نباید Patch را به چرخه معمول ماهانه موکول کنند.

دامنه نسخه ها یکسان نیست. SQL Injection از شاخه 6.8 وجود دارد، اما مسیر RCE از 6.9 به بعد مطرح است. به همین دلیل WordPress 6.8.6 فقط اصلاح مرتبط با SQL Injection را دارد، درحالی که 6.9.5 و 7.0.2 هر دو اصلاح را دریافت کرده اند. نسخه های قدیمی تر از 6.8 طبق اطلاعیه رسمی متاثر نیستند، اما قدیمی بودن آن ها همچنان می تواند آسیب پذیری های دیگر و مشکل پشتیبانی ایجاد کند؛ «متاثر نبودن از این دو CVE» به معنی امن بودن کلی نسخه قدیمی نیست.

مدیر سایت باید بین تاریخ انتشار خبر و زمان واقعی رخداد تفاوت بگذارد. Ruleهای WAF و Patch در همان 17 ژوئیه منتشر شدند. اگر سایت از آن تاریخ تا زمان Patch عمومی و قابل دسترسی بوده، بازه بررسی Log از قبل از انتشار آغاز شود؛ مهاجم ممکن است Scan را بلافاصله پس از عمومی شدن جزئیات شروع کرده باشد. در رخداد امنیتی، فقط زمان نصب Patch مهم نیست؛ باید بدانید چه مدت Exposure وجود داشته است.

دو آسیب پذیری دقیقاً چه هستند؟

CVE-2026-60137؛ SQL Injection

SQL Injection زمانی رخ می دهد که ورودی کنترل شده توسط مهاجم بتواند ساختار Query دیتابیس را تغییر دهد. در این رخداد، WordPress وجود ورودی Crafted را که Query را تحت تاثیر قرار می دهد تأیید کرده است. شدت High یعنی اثر بالقوه جدی است، اما جزئیات بهره برداری و شرایط دقیق باید از Advisory رسمی دنبال شود. برای مدیر عملیاتی، پیام روشن است: فیلتر ورودی در Plugin یا CDN به تنهایی تضمین کافی نیست و Core باید به نسخه اصلاح شده برسد.

اثر SQL Injection می تواند از خواندن داده و دورزدن منطق تا دست کاری اطلاعات متغیر باشد، اما نباید بدون شواهد ادعا کرد هر نصب دقیقاً چه خروجی قابل استخراجی دارد. Scope واقعی به مسیر آسیب پذیر، Permission دیتابیس، Prefix جدول، تنظیمات و نسخه بستگی دارد. به همین دلیل اصل Least Privilege برای User دیتابیس اهمیت دارد: حساب WordPress نباید مجوز مدیریتی کل Server یا دسترسی به Databaseهای دیگر داشته باشد.

CVE-2026-63030؛ اجرای کد بدون احراز هویت

آسیب پذیری دوم یک Confusion در Batch Route REST API و SQL Injection مرتبط است که می تواند به Remote Code Execution برسد. Cloudflare توضیح داده این مسیر WordPress 6.9 و بالاتر را هنگامی متاثر می کند که Persistent Object Cache در استفاده نباشد. مهاجم برای تلاش بهره برداری نیاز به Login یا کلیک کاربر ندارد. RCE از خطرناک ترین طبقات رخداد است، چون در صورت موفقیت می تواند اجرای دستور یا کد در Context سرویس وب را ممکن کند.

وجود Persistent Object Cache را به عنوان راه حل امنیتی دائمی تلقی نکنید. شرط بهره برداری بخشی از تحلیل آسیب پذیری است، نه Patch. Config ممکن است میان Environmentها متفاوت باشد و Cache ممکن است موقتاً غیرفعال شده باشد. همچنین ضعف SQL Injection جداگانه همچنان مطرح است. معیار درست، قرارگرفتن Core روی نسخه اصلاح شده و تأیید Integrity است.

جدول نسخه امن

برای دیدن نسخه، Dashboard را بررسی کنید یا در WP-CLI فرمان wp core version را اجرا کنید. فایل version.php نیز اطلاعات دارد، اما خواندن مستقیم فایل تنها در صورتی قابل اعتماد است که Integrity نصب حفظ شده باشد. در Hosting مدیریت شده، Panel ممکن است نسخه هدف را نمایش دهد درحالی که Rollout هنوز کامل نشده است. نتیجه را از داخل Runtime و فایل های Core تأیید کنید.

راهنمای Patch ایمن

Patch امنیتی باید سریع و درعین حال قابل بازگشت باشد. ابتدا Snapshot یا Backup سازگار از Database و فایل های wp-content تهیه کنید و امکان Restore را واقعاً بررسی کنید. Backup روی همان Server و همان حساب تنها نسخه پشتیبان محسوب نمی شود؛ اگر مهاجم یا خطای Disk آن را تحت تاثیر قرار دهد، بازیابی ممکن نیست. سپس Maintenance Window کوتاه تعریف و تغییرات محتوا یا سفارش را در سایت های تراکنشی کنترل کنید.

1. نسخه فعلی Core، PHP، Pluginها، Theme و Object Cache را ثبت کنید.
2. Backup دیتابیس و wp-content را در مقصد جدا بگیرید و Restore Test یا حداقل Integrity Check انجام دهید.
3. در Staging مشابه Production، نسخه مقصد را نصب و Login، Checkout، فرم، Cron و REST API را تست کنید.
4. Production را با Dashboard، WP-CLI یا ابزار Hosting به نسخه امن ارتقا دهید.
5. Cacheهای Page، Object، Opcode و CDN را به شکل کنترل شده پاک کنید.
6. نسخه Core و Checksum فایل ها را تأیید کنید.
7. Log و Metric را در ساعات بعد از انتشار برای Error، Spike و درخواست مشکوک رصد کنید.

# مشاهده نسخه
wp core version

# تهیه نسخه پشتیبان دیتابیس
wp db export before-wordpress-security-update.sql

# ارتقای Core به نسخه امن شاخه 7.0
wp core update --version=7.0.2

# اجرای تغییرات احتمالی دیتابیس
wp core update-db

# بررسی یکپارچگی فایل های Core
wp core verify-checksums

فرمان ها باید با User درست سیستم عامل، مسیر صحیح سایت و Backup تاییدشده اجرا شوند. روی Hosting اشتراکی ممکن است WP-CLI در دسترس نباشد و Dashboard یا ابزار Provider مسیر مناسب باشد. بعد از Upgrade، فقط صفحه اصلی را باز نکنید. Login ادمین، REST API، فرم تماس، Upload، پرداخت، Search، Cron و یک مسیر Cache را بررسی کنید. Error Log PHP و Web Server باید در همان زمان مشاهده شود.

Auto-update اجباری می تواند سایت را Patch کرده باشد، اما احتمال Failure، Permission نامناسب، Disk پر یا Fork سفارشی وجود دارد. ایمیل موفقیت Update مدرک نهایی نیست. نسخه را دوباره بخوانید، Checksum Core را بررسی کنید و مطمئن شوید همه Nodeهای Load-balanced یا Containerها نسخه یکسان دارند. اگر Immutable Image استفاده می کنید، Patch داخل Container موقت کافی نیست؛ Image پایه را بازسازی و Deploy کنید.

چگونه تأیید کنیم سایت واقعاً اصلاح شده؟

تأیید در سه سطح انجام می شود: Version، Integrity و Behavior. در سطح Version باید شماره اصلاح شده دیده شود. در سطح Integrity، فایل های Core با Checksum رسمی تطبیق پیدا کنند و تغییر ناشناخته در wp-admin یا wp-includes وجود نداشته باشد. در سطح Behavior، مسیرهای اصلی سایت بعد از Update سالم باشند. Theme و Plugin سفارشی ممکن است با Core جدید مشکل پیدا کنند، اما Rollback طولانی به نسخه آسیب پذیر پاسخ مناسبی نیست؛ Compatibility را رفع یا Feature مسئله دار را موقتاً محدود کنید.

نقش Cloudflare WAF و کنترل های موقت

Cloudflare برای هر دو CVE Rule مسدودکننده منتشر کرده و گفته مشتریان Free و Paid که ترافیک سایتشان از WAF عبور می کند پوشش دریافت می کنند. برای پلن های Pro، Business و Enterprise باید Managed Rules فعال باشند و Overrideها بررسی شوند. اگر Rule سطح Ruleset از Block به Log تغییر کرده، محافظت عملی ممکن است اعمال نشود. Security Events را برای Matchهای مرتبط ببینید و Timestamp، Source و مسیر درخواست را برای بررسی نگه دارید.

WAF یک لایه کاهش Exposure است، نه جایگزین Patch. Origin ممکن است مستقیم از اینترنت قابل دسترسی باشد، DNS قدیمی یا IP لو رفته باشد، ترافیک داخلی از WAF عبور نکند یا Rule با Payload تازه دور زده شود. IP Origin را محدود کنید تا فقط Edge مجاز بتواند وصل شود، اما مسیر مدیریت، Health Check و Backup را در طراحی لحاظ کنید. اگر Cloudflare ندارید، Provider WAF خود را برای Signature و Virtual Patch رسمی بررسی کنید؛ Rule دست ساز عجولانه می تواند سایت را بشکند یا Gap داشته باشد.

اگر احتمال سوءاستفاده وجود دارد

Patch کردن جلوی تلاش بعدی را می گیرد، اما Backdoor یا User ساخته شده را حذف نمی کند. اگر سایت در بازه Exposure عمومی بوده، Logهای Web Server، WAF، WordPress و Hosting را حفظ کنید. به درخواست های غیرعادی REST Batch، Spike در 4xx/5xx، Queryهای مشکوک، اجرای PHP در Upload، فایل تازه در Core، Admin User ناشناس و Scheduled Task جدید توجه کنید. نبودن یک نشانه خاص، نفوذ را رد نمی کند.

1. از سیستم فعلی Snapshot و Log غیرقابل تغییر تهیه کنید؛ قبل از پاک سازی Evidence را حفظ کنید.
2. سایت را در صورت شواهد قوی محدود یا از شبکه جدا کنید و صفحه نگه داری کنترل شده نشان دهید.
3. فایل های Core را با Checksum و wp-content را با Baseline و زمان تغییر مقایسه کنید.
4. Userهای Administrator، Application Password، API Key، SSH Key و حساب Hosting را Audit کنید.
5. wp-cron، Cron سیستم عامل، MU Plugin، Drop-in و فایل های Upload قابل اجرا را بررسی کنید.
6. Credential دیتابیس، WordPress Salt، حساب ادمین، Hosting، CDN و سرویس های متصل را Rotate کنید.
7. از Backup سالم قبل از نفوذ بازیابی و سپس Patch و Hardening را اعمال کنید.

فایل های رایج Backdoor ممکن است نامی شبیه Core یا Plugin معتبر داشته باشند. فقط جست وجوی eval یا base64_decode کافی نیست؛ کد مشروع نیز ممکن است این الگوها را داشته باشد و مهاجم می تواند از روش دیگر استفاده کند. بهترین روش مقایسه با Artifact معتبر، Checksum، Repository و Backup شناخته شده است. برای فروشگاه یا سایت دارای داده شخصی، تعهدات اطلاع رسانی و بررسی حقوقی نیز باید براساس حوزه فعالیت ارزیابی شود.

سخت سازی پس از Patch

پس از مهار رخداد، Permission فایل و User سرویس را بازبینی کنید. Web Server نباید امکان نوشتن در تمام Document Root داشته باشد. مسیرهای لازم مانند Upload به Permission محدود نیاز دارند، اما اجرای PHP در Upload باید بسته شود. Database User فقط مجوزهای لازم Database همان سایت را داشته باشد. XML-RPC، REST Endpoint و Pluginهای استفاده نشده را براساس نیاز واقعی محدود کنید، نه با Ruleهای کور که عملکرد را می شکنند.

Plugin و Theme متروک Attack Surface مهمی هستند. Inventory بگیرید، موارد غیرفعال و بدون استفاده را حذف کنید و Update خودکار یا برنامه Patch مشخص داشته باشید. Admin باید MFA داشته باشد و Password مشترک ممنوع باشد. Log ورود، تغییر Plugin، ساخت User و تغییر فایل به سامانه مرکزی ارسال شود تا مهاجم نتواند با حذف Log محلی رد را پاک کند. Backup باید Immutable یا حداقل جدا از Credential Production باشد.

در معماری Container، wp-content و Database Persistent هستند و Core ممکن است داخل Image باشد. نسخه امن را در Dockerfile یا Image Vendor ثبت و Redeploy کنید. Update دستی داخل Pod با Restart از بین می رود. در چند سایت WordPress، یک Inventory مرکزی از Domain، Owner، نسخه، Hosting و زمان آخرین Patch بسازید. رخدادهایی مانند 7.0.2 نشان می دهند پیدا نکردن یک نصب فراموش شده می تواند کل شبکه یا اعتبار سازمان را درگیر کند.

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

آیا WordPress 6.7 هم متاثر است؟

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

اگر Auto-update انجام شده، کار تمام است؟

خیر. نسخه، Checksum، عملکرد سایت و نشانه های سوءاستفاده باید بررسی شوند. Auto-update می تواند شکست بخورد یا پیش از Patch بهره برداری رخ داده باشد.

Cloudflare WAF برای محافظت کافی است؟

WAF Exposure را کم می کند و Rule رسمی برای هر دو CVE دارد، اما Patch Core همچنان ضروری است. Origin مستقیم، Override Rule و مسیرهای خارج از Proxy می توانند پوشش را ناقص کنند.

آیا باید تمام Passwordها را عوض کنیم؟

اگر Evidence یا احتمال معتبر نفوذ وجود دارد، Rotation گسترده Credential منطقی است. در Patch پیشگیرانه بدون نشانه، حداقل حساب های ادمین، Application Password و Accessهای قدیمی را Audit کنید.

آیا Restore از Backup کافی است؟

Backup باید مربوط به قبل از نفوذ و از نظر سلامت قابل اعتماد باشد. پس از Restore نیز نسخه امن، Pluginهای به روز، Credential تازه و Hardening لازم اند؛ وگرنه همان مسیر دوباره باز می ماند.

جمع بندی

WordPress 7.0.2 و Backportهای 6.9.5 و 6.8.6 باید بدون تعویق نصب شوند. نسخه درست را براساس شاخه انتخاب کنید، Backup قابل بازیابی بگیرید، Core را Patch و Checksum را تأیید کنید. WAF را به عنوان لایه موقت نگه دارید، نه جایگزین Update. اگر سایت در معرض بوده یا نشانه غیرعادی دارد، از حالت Maintenance ساده عبور کنید و Incident Response، حفظ Evidence، Rotation Credential و بازیابی از منبع سالم را انجام دهید.

منابع رسمی

• اطلاعیه رسمی WordPress 7.0.2 و Backportهای امنیتی
• جزئیات فنی و Ruleهای WAF منتشرشده توسط Cloudflare