نسخه‌های تحت تأثیر و نسخه‌های پچ‌شده وردپرس
آسیب‌پذیری CVE-2026-87902 تمام نسخه‌های وردپرس از 4.7.0 تا 7.1.1 را تحت تأثیر قرار می‌دهد. نسخه 7.1.1 نیز در میان نسخه‌های آسیب‌پذیر قرار دارد؛ نسخه‌ای که 17 سپتامبر در قالب یک به‌روزرسانی امنیتی منتشر شده بود. بنابراین، حتی سایت‌هایی که در 17 سپتامبر به نسخه 7.1.1 به‌روزرسانی شده‌اند نیز باید این پچ امنیتی را نصب کنند. این آسیب‌پذیری ارتباطی با آسیب‌پذیری‌های برطرف‌شده در به‌روزرسانی امنیتی 17 سپتامبر ندارد و یک ضعف امنیتی جداگانه محسوب می‌شود.
نسخه مناسب برای به‌روزرسانی، بر اساس شاخه مورد استفاده تعیین می‌شود:
شاخه مورد استفاده | نسخه قابل نصب |
7.1.x | 7.1.2 |
7.0.x | 7.0.6 |
6.9.x | 6.9.9 |
6.8.x | 6.8.10 |
6.7.x | 6.7.9 |
6.6.x | 6.6.9 |
وردپرس این پچ را برای تمام شاخه‌های قدیمی‌تری که همچنان تحت پشتیبانی هستند نیز بک‌پورت (Backport) کرده است؛ این به‌روزرسانی حتی برای شاخه 4.7 و تا نسخه 4.7.37 نیز ارائه شده است. فهرست کامل نسخه‌های پچ‌شده در یادداشت انتشار نسخه 7.1.2 (Release Notes) منتشر شده است.
سایت‌هایی که قابلیت به‌روزرسانی خودکار پس‌زمینه را فعال کرده‌اند، به‌صورت خودکار به‌روزرسانی خواهند شد. سایر سایت‌ها می‌توانند از طریق بخش به‌روزرسانی‌ها (Updates) در محیط مدیریت، سیستم را به‌صورت دستی به‌روزرسانی کرده یا نسخه جدید را از وب‌سایت WordPress.org دریافت کنند. برای این آسیب‌پذیری، راهکار موقت (Workaround) جداگانه‌ای ارائه نشده است؛ بنابراین، نصب نسخه پچ‌شده، راهکار اصلی برای رفع این آسیب‌پذیری است.
شرایط لازم برای اجرای کد دلخواه
بارگذاری یک فایل PHP لوکال به‌تنهایی باعث اجرای کد موجود در آن فایل می‌شود. اما برای اینکه مهاجم بتواند از این قابلیت برای اجرای کد دلخواه استفاده کند، باید یک شرط دیگر هم وجود داشته باشد:
- سرور از قبل باید یک فایل PHP داشته باشد که با بارگذاری آن، قابلیت موردنظر مهاجم اجرا شود.
این شرط مشخص می‌کند چرا وردپرس در توضیح این آسیب‌پذیری، از عبارت «برخی سرورها» استفاده کرده است. در نتیجه، وجود این آسیب‌پذیری در یک سایت لزوماً به معنای آن نیست که مهاجم بتواند در تمام سایت‌های آسیب‌پذیر کد دلخواه اجرا کند؛ اجرای کد به وجود شرایط و فایل موردنیاز روی سرور نیز وابسته است.
ریشه آسیب‌پذیری وردپرس
این آسیب‌پذیری ناشی از نحوه انتخاب فایل قالب (Template File) برای نمایش صفحات در وردپرس است. بخشی از نام فایل در وردپرس بر اساس اطلاعات موجود در آدرس وب (URL) تعیین می‌شود. در نسخه‌های آسیب‌پذیر، این مقدار پیش از استفاده برای ساخت مسیر فایل، از نظر وجود الگوی پیمایش مسیر (Path Traversal) مانند ../بررسی نمی‌شد؛ در حالی که بخش‌های دیگر کد، همین بررسی امنیتی را انجام می‌دادند.
از آنجا که نام فایل نهایی با الگوی page-{value}.php ساخته می‌شود، سوءاستفاده از این آسیب‌پذیری به وجود شرایط زیر در ساختار سایت وابسته است:
- قالب فعال سایت: وجود یک پوشه در پوشه اصلی قالب که نام آن با page- شروع شود.
- فایل هدف: یک فایل PHP با پسوند .php که امکان بارگذاری آن از طریق این آسیب‌پذیری وجود داشته باشد.
برخی قالب‌ها، از جمله تعدادی از قالب‌های پیش‌فرض قدیمی، این ساختار را دارند؛ اما در قالب‌های پیش‌فرض جدید، چنین پوشه‌ای وجود ندارد.
دو شاخص برای شناسایی سایت‌های آسیب‌پذیر
شرکت امنیتی Patchstack در تحلیل خود به دو مورد اشاره کرده است که می‌توانند به مدیران سایت در شناسایی شرایط لازم برای سوءاستفاده از این آسیب‌پذیری کمک کنند:
- ساختار قالب فعال: قالب فعال سایت باید در پوشه اصلی خود، پوشه‌ای داشته باشد که نام آن با page-شروع شود.
- تنظیمات PHP: گزینه register_argc_argv در PHP فعال باشد؛ فعال بودن این گزینه در سناریوی اجرای کد از طریق این آسیب‌پذیری نقش دارد.
Patchstack تأکید می‌کند که هیچ‌یک از این دو مورد، راهکاری برای رفع آسیب‌پذیری نیستند؛ بلکه وجود آن‌ها نشان می‌دهد سایت تا چه اندازه شرایط لازم برای اجرای موفق حمله را دارد. گزینه register_argc_argv در PHP 8.5 به‌صورت پیش‌فرض غیرفعال است، در حالی که در نسخه‌های قدیمی‌تر PHP به صورت پیش‌فرض فعال بوده است.
اثبات آسیب‌پذیری در محیط آزمایشگاهی
این آسیب‌پذیری توسط یک پژوهشگر امنیتی به نام رابرت رسل (Robert Ressl) شناسایی شده است. رسل در ماه جولای، این آسیب‌پذیری را به‌صورت خصوصی و از طریق برنامه باگ‌بانتی HackerOne به تیم وردپرس گزارش داد.
این پژوهشگر هم‌زمان با انتشار پچ، یک گزارش فنی جامع نیز منتشر کرد که شامل کد اثبات مفهوم (PoC) و یک محیط آزمایش مستقل و آماده برای بازتولید سناریوی حمله بود.
رسل برای نمایش نحوه سوءاستفاده از آسیب‌پذیری، حمله را در یک محیط آزمایشی اجرا کرد. در این آزمایش، کد با سطح دسترسی حساب کاربری وب‌سرور (Web Server Account) اجرا شد، اما این سطح دسترسی امکان کنترل کامل سرور را فراهم نمی‌کرد.
این آزمایش روی نسخه 7.0.2 و در محیط‌های آزمایشگاهی لوکال و ایزوله انجام شد؛ بنابراین، سناریوی حمله روی نسخه پچ‌شده یا یک سایت واقعی اجرا و آزمایش نشده است.
همچنین این پژوهشگر اعلام کرده است اپراتورهایی که فعلاً امکان به‌روزرسانی فوری را ندارند، می‌توانند با غیرفعال کردن register_argc_argv برای درخواست‌های وب و حذف کامپوننت‌های بلااستفاده PEAR، احتمال سوءاستفاده از این آسیب‌پذیری برای اجرای کد را کاهش دهند.
با این حال، هیچ‌یک از این اقدامات آسیب‌پذیری اصلی را برطرف نمی‌کنند و صرفاً می‌توانند ریسک اجرای کد در جریان حمله را کاهش دهند. بنابراین، نصب نسخه پچ‌شده همچنان راهکار اصلی برای رفع این آسیب‌پذیری است.
