وردپرس یک نقص XSS انعکاسی پیش‌احراز هویتی را با شناسه CVE-2026-64638 (امتیاز CVSS: 8.9) وصله کرد. گروه پژوهشی pwn.ai نشان داده این آسیب‌پذیری در شرایط خاص می‌تواند زنجیروار منجر به اجرای کد PHP روی سرور شود، به‌ویژه اگر یک کاربر با نقش Administrator وارد شده و با صفحه‌ای تحت کنترل مهاجم تعامل کند.

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

وردپرس نقص را در نسخهٔ 7.0.3 در تاریخ 6 اوت رفع کرده و اصلاحات تا شاخهٔ 4.7 بازپس‌برده شده‌اند. سایت‌هایی که به‌روزرسانی خودکار پس‌زمینه فعال دارند باید این نسخهٔ امنیتی را به‌طور خودکار دریافت کنند؛ اما نصب‌های قدیمی‌تر از 4.7 همچنان در معرض خطر باقی می‌مانند. توصیهٔ فوری: هر چه سریع‌تر وردپرس را به آخرین نسخه ارتقاء دهید. اطلاع‌رسانی رسمی در: wordpress.org/news.

نام حمله و اهمیت امنیتی

پژوهشگران زنجیرهٔ حمله را «XSS2Shell» نامیده‌اند. XSS موردنظر در صفحهٔ ورود به سایت رخ می‌دهد و برای فراخوانی اولیه به هیچ احراز هویتی نیاز ندارد؛ هرگاه رشتهٔ نام‌کاربری ساخته‌شده به صفحهٔ خطای ورود منتقل شود، کد جاوااسکریپت در مرورگر قربانی اجرا می‌شود. تبدیل این XSS به اجرای کد سرور نیازمند تعامل صریحِ یک مدیر واردشده (مثلاً یک کلیک) با صفحه‌ای تحت کنترل مهاجم است. در نمونهٔ نمایشی pwn.ai آن تعامل تنها یک کلیک بود.

شرح فنی زنجیره حمله

گام‌های فنی زنجیره به‌طور خلاصه:

  • مقدار نام‌کاربری ابتدا از توابع sanitize_user() و wp_strip_all_tags() عبور می‌کند؛ wp_strip_all_tags() به strip_tags() در PHP متکی است. رشته‌ای شبیه تگ که پس از علامت < یک فاصله داشته باشد می‌تواند از این پارسر به‌عنوان متن عبور کند.
  • همان مقدار سپس توسط wp_kses_post() پردازش می‌شود که پارسر متفاوتی است و ورودی را به‌عنوان HTML مجاز تفسیر می‌کند؛ در نتیجه عناصر DOM تحت کنترل مهاجم روی صفحهٔ خطای ورود ظاهر می‌شوند.
  • آن عناصر با اسکریپت مدیریتی وردپرس (user-profile.js) که به‌خاطر قابلیت بازنشانی رمز روی صفحهٔ ورود هم بارگذاری می‌شود، تعامل می‌کنند. نبود بعضی المنت‌ها در صفحهٔ ورود باعث می‌شود مقدارهای undefined عبور کنند و یک شرط بررسی شود؛ همچنین متغیر ajaxurl که معمولاً مقداردهی نشده است می‌تواند با یک عنصر DOM تزریق‌شده بازنویسی شود و جاوااسکریپت را به ارسال درخواست REST هم‌مبدا به مقصد مهاجم هدایت کند.
  • پژوهشگران از پشتیبانی JSONP در REST وردپرس استفاده کردند تا پاسخ به‌صورت اسکریپت در منشأ سایت اجرا شود. در استقرارهایی که پاسخ REST ناشناس 401 برمی‌گرداند، پارامتر _envelope=1 می‌تواند پاسخ را در یک HTTP 200 بسته‌بندی کند و به jQuery اجازه دهد آن را به‌عنوان اسکریپت اجرا کند.

چرا برخی تدابیر دفاعی ناکافی بودند

pwn.ai گزارش داده است که حتی CSP مبتنی بر nonce و strict-dynamic در آزمایش‌های آن‌ها مانع این زنجیره نشد. مسیر از تکنیک SOME (Same Origin Method Execution) نیز بهره می‌برد که اجرا در منشأ را ممکن می‌سازد. برای مروری بر XSS و مکانیزم‌ها می‌توانید به ویکی‌پدیا: Cross-site scripting مراجعه کنید.

نمونهٔ کاملِ حمله: ایجاد Application Password به‌جای سرقت رمز

در یک سناریوی نمایشی، مهاجم با فراخوانی عملکرد داخلی Application Password در جلسهٔ مدیر واردشده، موجب تولید یک اعتبارنامهٔ API می‌شود که به success_url انتخاب‌شدهٔ مهاجم ارسال می‌گردد. Application Passwordها قابل لغو‌اند و برای دسترسی API طراحی شده‌اند؛ بنابراین نیازی به سرقت رمز اصلی مدیر نیست. با چنین اعتبارنامه‌ای می‌توان درخواست‌های REST احرازشده فرستاد، صفحه‌ای حاوی جاوااسکریپتِ هم‌منشأ منتشر کرد و وقتی مدیر آن صفحه را باز کند، nonce آپلود افزونه را به‌دست آورد و یک فایل ZIP آماده‌شده توسط مهاجم را آپلود کند. پس از استخراج ZIP می‌توان فایل‌های PHP را مستقیماً درخواست کرد، حتی بدون فعال‌سازی افزونه.

آیا بهره‌جویی عملی است؟

وردپرس در اطلاعیهٔ رسمی هشدار داده که دستیابی به اجرای کد روی سرور مستلزم شرایطی خارج از کنترل مهاجم است، از جمله مهندسی اجتماعی موفق و تعامل صریح قربانی. با این حال pwn.ai می‌گوید چند مسیر مختلف برای تبدیل XSS به اجرای کد وجود دارد و برخی واریانت‌ها را بازتولید کرده‌اند. شواهد ارائه‌شده به رسانه‌ها تا مرحلهٔ XSS پیش‌رفتن را نشان می‌دهد؛ پژوهشگران در برخی آزمایش‌ها XSS را بدون نیاز به کوکی در پروفایل‌های تازهٔ مرورگر بازتولید کردند اما مراحل بعدی مانند ساخت Application Password و آپلود فایل را در همهٔ تست‌ها اجرا نکردند.

اقدامات فوری و توصیه‌های عملی برای مدیران

  • فوری به‌روزرسانی کنید: وردپرس را به نسخهٔ 7.0.3 یا بالاتر ارتقاء دهید. اگر از نسخهٔ پایین‌تر از 4.7 استفاده می‌کنید، برنامهٔ مهاجرت یا وصلهٔ دستی را در دستور کار قرار دهید.
  • افزونه‌ها و قالب‌ها را به‌روز نگه دارید: ترکیب چند نقص می‌تواند زنجیرهٔ بهره‌جویی ایجاد کند.
  • نظارت فعال: لاگ‌های REST، ایجاد Application Passwordهای ناگهانی و آپلود فایل‌های ZIP را پایش کنید.
  • محدودسازی نقش‌ها و امتیازات: تعداد مدیران را کاهش دهید و از اصل حداقل دسترسی استفاده کنید.
  • تقویت دفاع‌های چندلایه: بازبینی سیاست‌های CSP و هاردنینگ جاوااسکریپت را انجام دهید. صرفِ یک CSP ممکن است کافی نباشد؛ لایه‌های دفاعی متنوع لازم‌اند.

منابع و ارجاعات

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