وردپرس یک آسیب‌پذیری XSS بازتابی پیش از احراز هویت (Pre-Authentication Reflected XSS) را در صفحه ورود خود پچ کرده است. این آسیب‌پذیری وردپرس تمامی نسخه‌های این سیستم مدیریت محتوا را تحت تأثیر قرار می‌دهد و در شرایط خاص می‌تواند از طریق زنجیره حمله منجر به اجرای کد PHP روی سرور شود. این آسیب‌پذیری با شناسه CVE-2026-64638 و امتیاز 8.9 در سامانه CVSS در رده آسیب‌پذیری‌های با شدت بالا (High) قرار دارد و مهاجم برای اجرای مرحله اولیه حمله به هیچ سطحی از دسترسی یا احراز هویت نیاز ندارد. پژوهشگران pwn.ai اعلام کرده‌اند که مهاجم می‌تواند از این آسیب‌پذیری در کنار سایر تکنیک‌های حمله استفاده کند و در شرایط خاص، مسیر حمله را تا اجرای کد PHP روی سرور پیش ببرد. در این سناریو، یک ادمین باید وارد حساب کاربری خود شده باشد و با صفحه‌ای تحت کنترل مهاجم تعامل کند. اجرای XSS در صفحه ورود نیز به احراز هویت مهاجم نیاز ندارد. این ویژگی، آسیب‌پذیری وردپرس را به تهدیدی جدی‌تر برای سایت‌های تحت تأثیر تبدیل می‌کند.
آسیب‌پذیری وردپرس مسیر XSS تا اجرای کد را هموار می‌کند
مهاجم می‌تواند یک نام کاربری دست‌کاری‌شده را به صفحه ورود ارسال کند. وردپرس پس از ناموفق بودن تلاش برای ورود، این مقدار را در صفحه خطای ورود پردازش می‌کند و کد جاوااسکریپت (JavaScript) حاصل در مرورگر بازدیدکننده اجرا می‌شود. اجرای این کد در همان صفحه به هیچ تعامل دیگری از سوی کاربر نیاز ندارد.
البته اجرای کد پس از XSS به شرایط دیگری هم وابسته است. قربانی باید پیش از شروع حمله با حساب ادمین وارد وردپرس شده باشد و سپس صفحه‌ای را باز کند که مهاجم آن را کنترل می‌کند. در آزمایش pwn.ai، انجام این کار تنها به یک کلیک معمولی از سوی قربانی نیاز داشت.
پژوهشگران pwn.ai اعلام کرده‌اند که این حمله روی نصب‌های پیش‌فرض وردپرس نیز قابل اجرا است و به تنظیمات خاص یا غیرمعمول در محیط میزبانی و نحوه استقرار سیستم نیاز ندارد. همچنین پژوهشگران چند مسیر برای تبدیل XSS به اجرای کد شناسایی کرده‌اند که در برخی از آنها مهاجم می‌تواند یک پلاگین نصب کند یا یک فایل ZIP دلخواه را روی سایت آپلود نماید. به این ترتیب، آسیب‌پذیری وردپرس در شرایط مشخص می‌تواند از اجرای جاوااسکریپت در مرورگر فراتر برود و منجر به اجرای کد در سمت سرور شود.
ارزیابی وردپرس از شرایط اجرای حمله
وردپرس در اطلاعیه امنیتی (Advisory) خود، درباره امکان سوءاستفاده از این آسیب‌پذیری ارزیابی محتاطانه‌تری ارائه کرده است. طبق این ارزیابی، مهاجم برای تبدیل XSS به اجرای کد از راه دور (RCE) به همکاری ناخواسته قربانی نیاز دارد. این مرحله مستلزم مهندسی اجتماعی (Social Engineering) موفق و تعامل مستقیم قربانی با صفحه‌ای تحت کنترل مهاجم است. بنابراین، اگرچه مهاجم برای اجرای XSS اولیه نیازی به احراز هویت ندارد، اما ادامه حمله و رسیدن به RCE به تعامل قربانی با صفحه تحت کنترل مهاجم وابسته است.
در مجموع، آسیب‌پذیری وردپرس برای رسیدن از XSS به اجرای کد از راه دور به چند پیش‌شرط مشخص وابسته است و همین موضوع باعث شده وردپرس در ارزیابی قابلیت اجرای این زنجیره حمله، رویکرد محتاطانه‌تری در پیش بگیرد.
انتشار پچ امنیتی وردپرس
وردپرس این آسیب‌پذیری را در 6 آگوست 2026 با انتشار نسخه 7.0.3 پچ کرد. اصلاحات امنیتی این نسخه برای شاخه 4.7 و نسخه‌های پس از آن نیز بک‌پورت (Backport) شده است.
وردپرس به مدیران سایت‌ها توصیه کرده است که در اسرع وقت سیستم خود را به نسخه پچ‌شده به‌روزرسانی کنند. سایت‌هایی که از قابلیت به‌روزرسانی خودکار در پس‌زمینه (Automatic Background Updates) پشتیبانی می‌کنند، این به‌روزرسانی امنیتی را به‌صورت خودکار دریافت خواهند کرد.
نسخه‌های پیش از 4.7 همچنان در برابر این ضعف امنیتی آسیب‌پذیر هستند و وردپرس برای این نسخه‌ها پچ امنیتی منتشر نمی‌کند. به همین دلیل، مدیران سایت‌هایی که از نسخه‌های قدیمی استفاده می‌کنند باید سیستم خود را به یک نسخه پشتیبانی‌شده ارتقا دهند تا این آسیب‌پذیری وردپرس در نسخه مورد استفاده آنها برطرف شود.
نقش هوش مصنوعی در شناسایی زنجیره حمله
پژوهشگران pwn.ai این زنجیره حمله را XSS2Shell نام‌گذاری کرده‌اند. به گفته آنها سامانه خودکار این شرکت با استفاده از پژوهش Paulos Yibelo درباره تکنیک اجرای متد از مبدأ یکسان (Same Origin Method Execution یا SOME) که در سال 2022 منتشر شده بود، به‌عنوان نقطه شروع توانسته است زنجیره حمله را شناسایی و بازتولید کند.
به گفته pwn.ai، این فرآیند نزدیک به چهار روز زمان برده است. پژوهشگران در این فرآیند از مدل‌های متن‌باز و یک گردش کار چندعاملی (Multi-Agent Workflow) استفاده کرده‌اند. سامانه خودکار pwn.ai در 26 جولای توانست زنجیره حمله را بازتولید کند و این شرکت نیز یک روز بعد، در 27 جولای، جزئیات آسیب‌پذیری را به وردپرس گزارش داد.
ریشه فنی آسیب‌پذیری وردپرس در پردازش نام کاربری
ریشه این آسیب‌پذیری به نحوه پردازش نام کاربری در وردپرس پس از یک تلاش ناموفق برای ورود برمی‌گردد. به گفته پژوهشگران مقدار واردشده ابتدا از تابع sanitize_user() عبور می‌کند و سپس به wp_strip_all_tags() می‌رسد. این تابع نیز برای پردازش ورودی به strip_tags() در PHP متکی است.
پژوهشگران دریافتند که اگر پس از علامت < در یک رشته شبیه به تگ HTML فاصله وجود داشته باشد، این ورودی ممکن است توسط پارسر یا به عبارتی تجزیه‌کننده (Parser) به‌عنوان متن پردازش شود و از این مرحله عبور کند. وردپرس در مرحله بعد همین مقدار را با استفاده از تابع wp_kses_post() دوباره پردازش می‌کند. این تابع از پارسر دیگری استفاده می‌کند و همان ورودی را این بار به‌عنوان HTML مجاز تفسیر می‌کند. در نتیجه، کد HTML تحت کنترل مهاجم می‌تواند به ساختار DOM صفحه خطای ورود اضافه شود و در مرورگر اجرا گردد.
سپس این کدهای تزریق‌شده با اسکریپت داخلی user-profile.js وردپرس تعامل می‌کنند. این اسکریپت برای مدیریت پروفایل کاربران به کار می‌رود و چون صفحه ورود از قابلیت بازیابی رمز عبور پشتیبانی می‌کند، در همین صفحه نیز بارگذاری می‌شود.
با این حال، برخی از ورودی‌هایی که user-profile.js انتظار دارد در صفحه وجود داشته باشند، در صفحه ورود تعریف نشده‌اند. دو ورودی مورد انتظار مقدار undefined دریافت می‌کنند و همین موضوع باعث می‌شود شرط مقایسه با موفقیت برقرار شود. از سوی دیگر، متغیر ajaxurl که به‌طور معمول در این صفحه تعریف نشده است، می‌تواند با یک المنت DOM تزریق‌شده جایگزین شود.
این وضعیت باعث می‌شود کد جاوااسکریپت داخلی وردپرس به سمت یک درخواست REST از همان مبدأ هدایت شود که مقصد آن را مهاجم تعیین کرده است.
سپس پژوهشگران از قابلیت REST JSONP در وردپرس استفاده کردند تا این درخواست را به جاوااسکریپت قابل اجرا در مبدأ سایت تبدیل کنند. در محیط‌هایی که درخواست‌های REST بدون احراز هویت با پاسخ HTTP 401 مواجه می‌شوند، پارامتر _envelope=1 می‌تواند پاسخ 401 را داخل یک پاسخ HTTP با وضعیت 200 قرار دهد. در این حالت، jQuery پاسخ را به‌عنوان اسکریپت پردازش می‌کند و اجرای آن را ادامه می‌دهد.
همچنین پژوهشگران در آزمایش‌های خود بررسی کردند که آیا سیاست امنیتی محتوای (CSP) مبتنی بر Nonce با استفاده از strict-dynamic می‌تواند این مسیر حمله را مسدود کند یا خیر. نتایج نشان داد که این سیاست امنیتی نتوانسته است مسیر حمله اثبات‌شده را متوقف کند.
زنجیره حمله از XSS تا اجرای کد PHP
پژوهشگران برای تبدیل آسیب‌پذیری وردپرس از XSS به اجرای کد PHP از تکنیک «اجرای متد از مبدأ یکسان» (SOME) استفاده کرده‌اند که پیش‌تر توسط Yibelo معرفی شده بود. این تکنیک با استفاده از یک زنجیره ویژگی مجاز (Property Chain) در JSONP، امکان فراخوانی یک متد را در پنجره‌ای دیگر از مرورگر فراهم می‌کند.
pwn.ai در یکی از مسیرهای آزمایش‌شده، از XSS موجود در مبدأ وردپرس برای فراخوانی قابلیت داخلی تأیید رمز عبور اپلیکیشن (Application Password) در نشست فعال یک ادمین استفاده کرد. وردپرس پس از تأیید، یک اعتبارنامه برای دسترسی به API ایجاد کرده و سپس آن را به آدرس success_url تحت کنترل مهاجم هدایت می‌کند. رمزهای عبور اپلیکیشن اعتبارنامه‌های قابل لغو هستند که برای دسترسی به API استفاده می‌شوند. بنابراین، مهاجم برای ادامه این مسیر حمله نیازی به سرقت رمز عبور اصلی ادمین ندارد.
پژوهشگران از اعتبارنامه ایجادشده برای دسترسی احراز هویت‌شده به REST API استفاده کردند و یک صفحه وردپرس حاوی جاوااسکریپت از همان مبدأ ایجاد کردند. زمانی که ادمین با همان نشست فعال این صفحه را باز کرد، جاوااسکریپت موجود در صفحه توانست Nonce مورد نیاز برای آپلود پلاگین را دریافت کند.
سپس مهاجم یک فایل ZIP تحت کنترل خود را روی سایت آپلود کرد. وردپرس فایل را از حالت فشرده خارج کرد و در نتیجه، فایل‌های PHP موجود در پلاگین در دسترس قرار گرفتند. مهاجم پس از آن می‌توانست فایل PHP را مستقیماً اجرا کند. این پلاگین برای اجرای کد PHP نیازی به فعال شدن نداشت.
محدوده آزمایش‌ها و پیامدهای احتمالی اجرای PHP
شواهد به‌دست‌آمده از محیط عملیاتی تنها اجرای XSS را تأیید می‌کند. همچنین پژوهشگران XSS صفحه ورود را بدون نیاز به کوکی، روی دو نصب وردپرس 7.0.2 بازتولید کردند. این آزمایش‌ها در پروفایل‌های جدید مرورگر کروم و بدون هیچ کوکی یا اعتبارنامه وردپرس انجام شد.
پژوهشگران در این دو محیط، ایجاد رمز عبور اپلیکیشن، آپلود فایل، ایجاد پایداری (Persistence) یا اجرای کد PHP را آزمایش نکردند. پژوهشگران زنجیره کامل حمله تا اجرای PHP را به‌صورت جداگانه روی یک نصب مستقل و لوکال از وردپرس 7.0.2 بازتولید کردند.
پژوهشگران تأکید کرده‌اند که اقدامات ایمن‌سازی (Hardening) شناخته‌شده وردپرس نباید به‌عنوان راهکاری کامل برای مقابله با XSS در نظر گرفته شوند. به گفته آنها، نصب به‌روزرسانی امنیتی برای رفع این آسیب‌پذیری وردپرس ضروری است.
اجرای موفق کد PHP می‌تواند پیامدهای جدی برای امنیت سایت به همراه داشته باشد. مهاجم در این شرایط می‌تواند به اطلاعات دسترسی پایگاه داده وردپرس که در فایل wp-config.php ذخیره شده‌اند، دسترسی پیدا کند. همچنین این سطح از دسترسی به مهاجم اجازه می‌دهد حساب‌های ادمین دائمی ایجاد کند، محتوای سایت را تغییر دهد و به فایل‌ها و اطلاعات محرمانه‌ای دسترسی پیدا کند که برای پردازشگر PHP (PHP Worker) قابل خواندن هستند. مهاجم حتی می‌تواند دستورات سیستم‌عامل را با سطح دسترسی PHP Worker اجرا کند.
وردپرس شناسایی این آسیب‌پذیری و افشای مسئولانه آن را به تیم pwn.ai نسبت داده است. اطلاعیه امنیتی پروژه تا 7 آگوست 2026، هیچ گزارشی از سوءاستفاده واقعی (In-the-Wild Exploitation) از این آسیب‌پذیری ارائه نکرده است.
