در یک حمله زنجیره تأمین به وردپرس، مهاجمان با دستکاری فایلهای جاوااسکریپت (JavaScript) مورد اعتماد در پلاگینهای PushEngage، OptinMonster و TrustPulse، مسیر نفوذ مستقیم به وبسایتهای وردپرسی را فراهم کردند. در این حمله زنجیره تأمین به وردپرس کد مخرب فقط وقتی فعال میشد که ادمین وارد حساب کاربری خود شده بود و سایت همان لحظه فایل آلوده را بارگذاری میکرد. در ادامه، مهاجم با سوءاستفاده از نشست فعال یک حساب کاربری ادمین جدید ایجاد میکرد و همزمان یک پلاگین مخفی برای حفظ دسترسی پایدار (Persistence) روی سایت نصب میشد. شرکت امنیتی Sansec در تاریخ 13 ژوئن این کمپین را افشا کرد و اعلام نمود که کد مخرب یکسانی در نسخه جاوااسکریپت ارائهشده برای هر سه پلاگین مشاهده شده است. یک روز بعد، PushEngage نیز با انتشار یک اطلاعیه رسمی امنیتی تأیید کرد که نسخههای دستکاریشده اسکریپتهای این سرویس از طریق شبکه توزیع محتوا (CDN) منتشر شده بودند و در صورت بارگذاری روی سایتها، میتوانستند در نهایت کنترل کامل وبسایتهای آسیبپذیر را در اختیار مهاجم قرار دهند.
دامنه آلودگی و ابعاد حمله زنجیره تأمین به وردپرس
بررسیهای Sansec نشان میدهد که بازه زمانی انتشار کد مخرب در میان پلاگینهای هدف یکسان نبوده و هر یک از آنها برای مدت متفاوتی در معرض آلودگی قرار داشتهاند.
بر اساس یافتههای این شرکت:
- کد مخرب در پلاگینهای OptinMonster و TrustPulse در تاریخ 12 ژوئن تنها حدود 25 دقیقه از ساعت 22:17 UTC تا 22:42 UTC مشاهده شده است.
- پلاگین PushEngage برای مدت طولانیتری تحت تأثیر این آلودگی قرار داشت و نسخه دستکاریشده اسکریپت آن برای چندین ساعت در دسترس وبسایتها بود.
- برخی از سرورهای CDN تا 14 ژوئن نیز همچنان فایل آلوده را در اختیار کاربران قرار میدادند.
نکته قابل توجه این است که دو پلاگینی که بیشترین تعداد نصب فعال را دارند، کوتاهترین بازه آلودگی را تجربه کردهاند؛ در حالی که PushEngage بیشترین مدتزمان مواجهه با کد مخرب را داشته است.
هر سه پلاگین آسیبپذیر تحت مدیریت شرکت Awesome Motive قرار دارند. با این حال، این شرکت تا 15 ژوئن درباره دو پلاگین OptinMonster و TrustPulse هیچ اطلاعیه یا راهنمای رسمی منتشر نکرده بود. در میان سه سرویس، PushEngage تنها موردی بود که با انتشار اطلاعیه امنیتی و توصیههای اولیه، کاربران خود را از جزئیات رخداد مطلع کرد.
همچنین Sansec برآورد میکند که این سه پلاگین در مجموع در بیش از 1.2 میلیون وبسایت مورد استفاده قرار میگیرند. بخش عمده این تعداد مربوط به OptinMonster است که بهتنهایی بیش از یک میلیون نصب فعال دارد. پلاگین وردپرسی PushEngage نیز بیش از 9 هزار نصب فعال ثبت کرده است.
البته این ارقام تنها گستره استفاده از این پلاگینها را نشان میدهند و نباید آنها را معادل تعداد وبسایتهای آلوده در نظر گرفت؛ زیرا هنوز مشخص نیست چه تعداد از این سایتها در بازه زمانی حمله واقعاً تحت تأثیر کد مخرب قرار گرفتهاند.
از سوی دیگر، PushEngage اعلام کرده است که بررسیهای انجامشده هیچ نشانهای از نفوذ به سایر سامانههای این شرکت نشان نداده و مهاجمان به اپلیکیشن اصلی یا سرورهای حاوی اطلاعات مشتریان دسترسی پیدا نکردهاند. با این وجود، کارشناسان امنیتی تأکید میکنند هر وبسایتی که در بازه زمانی حمله نسخه دستکاریشده این اسکریپتها را بارگذاری کرده باشد باید بهعنوان یک سامانه آلوده در نظر گرفته شود؛ زیرا احتمال ایجاد بکدور، دسترسی غیرمجاز و پایداری مهاجم در آن وجود دارد.
نقش CDN در توزیع اسکریپتهای آلوده
در این حمله زنجیره تأمین به وردپرس، اسکریپت آلوده در بازدیدهای عادی هیچ فعالیتی نداشت و تنها زمانی فعال میشد که یک ادمین وردپرس وارد حساب کاربری خود شده بود و فایل آلوده نیز همزمان در سایت بارگذاری میشد. در این شرایط، کد مخرب با سوءاستفاده از نشست فعال ادمین، امکان انجام عملیات با سطح دسترسی کامل را برای مهاجم فراهم میکرد.
همین موضوع باعث شده بود تشخیص آلودگی از طریق داشبورد وردپرس عملاً امکانپذیر نباشد. بکدور بهگونهای طراحی شده بود که در بخشهای مدیریتی وردپرس نمایش داده نشود؛ به همین دلیل، بررسی پنل مدیریت بهتنهایی نمیتوانست وجود آلودگی را تأیید یا رد کند و تنها راه قابل اعتماد، بررسی فایلها و لاگها در سطح سرور بود.
در مورد PushEngage، فایلهای دستکاریشده شامل دو اسکریپت اصلی این سرویس یعنی pushengage-web-sdk.js و pushengage-subscription.js بودند که از طریق دامنه clientcdn.pushengage.com در اختیار وبسایتها قرار میگرفتند. این زیرساخت بخشی از CDN مورد استفاده PushEngage برای ارائه اسکریپتهای خود به وبسایتهای مشتریان است.
همچنین بررسیها نشان داد که پلاگینهای OptinMonster و TrustPulse نیز از طریق Endpointهای مجزای CDN متعلق به Awesome Motive تحت تأثیر این حمله قرار گرفته بودند.
نحوه عملکرد بکدور و حفظ دسترسی مهاجم در سایتهای آلوده
بر اساس توضیحات منتشرشده از سوی شرکت PushEngage، پس از آنکه اسکریپت آلوده در مرورگر یک ادمین وردپرس اجرا میشد، مهاجم میتوانست از نشست فعال همان ادمین برای انجام عملیات با سطح دسترسی کامل استفاده کند. این فرآیند شامل مراحل زیر بود:
- سوءاستفاده از نشست ادمین برای اجرای دستورات با دسترسی کامل
- ایجاد یک حساب کاربری ادمین جدید تحت کنترل مهاجم
- نصب یک پلاگین مخفی که در داشبورد وردپرس نمایش داده نمیشد
- ارسال اطلاعات حساب ادمین ایجادشده و جزئیات سایت به دامنه tidio[.]cc که مهاجمان آن را با ظاهری مشابه com راهاندازی کرده بودند.
شرکت Sansec اعلام کرده است که زنجیره حمله در هر سه پلاگین مشاهده شده است. همچنین بررسیها نشان میدهد دامنه tidio[.]cc در تاریخ 28 آوریل، چند هفته پیش از آغاز حمله، ثبت شده بود؛ موضوعی که نشان میدهد این عملیات از قبل برنامهریزی شده و یک حمله فرصتطلبانه یا مقطعی نبوده است.
مهمترین بخش این حمله زنجیره تأمین به وردپرس، پلاگین مخفی نصبشده روی سایت است. این پلاگین یک وب شل ) (Web Shell در اختیار مهاجم قرار میدهد؛ کانالی برای اجرای دستورات از راه دور که به مهاجم اجازه میدهد بدون نیاز به ورود به پنل مدیریت، کدهای دلخواه خود را روی سرور اجرا کند.
پس از ایجاد این دسترسی، مهاجم میتواند:
- فایلهای موجود روی سرور را مشاهده کرده، تغییر داده یا حذف کند.
- از پایگاه داده نسخه کپی تهیه کند.
- بکدورهای بیشتری در سیستم ایجاد کند.
- کدهای سرقت اطلاعات بانکی را به سایت تزریق کند.
- بازدیدکنندگان را به صفحات دیگری هدایت کند.
- دادههای حساس را سرقت کند.
علاوه بر این، حساب کاربری ادمین ایجادشده نیز یک مسیر دسترسی پشتیبان برای مهاجم محسوب میشود. در نتیجه، حتی اگر پلاگین مخفی شناسایی و حذف شود، باقی ماندن این حساب کاربری همچنان امکان بازگشت مهاجم را فراهم میکند. از آنجا که مهاجم از طریق وب شل قادر به اجرای آزادانه کد روی سرور بوده است، حذف حساب کاربری و پلاگین شناساییشده لزوماً به معنای پاکسازی کامل سیستم نیست. به همین دلیل، Sansec و PushEngage به مدیران سایتها توصیه کردهاند احتمال وجود بکدورهای دیگر را نیز در نظر بگیرند.
اختلاف نظر درباره نقطه نفوذ اولیه مهاجمان در حمله زنجیره تأمین به وردپرس
یکی از ابهامهای اصلی در این حمله زنجیره تأمین به وردپرس، نحوه دسترسی اولیه مهاجمان به زیرساخت قربانی است. PushEngage اعلام کرده که مهاجم ابتدا به سرور میزبان وبسایت بازاریابی (Marketing Website) این شرکت نفوذ کرده و برای این کار از یک آسیبپذیری شناختهشده در UpdraftPlus (پلاگین بکاپ یا پشیبانگیری وردپرس) سوءاستفاده کرده است. به گفته این شرکت، این سرور از سامانههای اصلی محصول و همچنین سرورهای حاوی اطلاعات مشتریان کاملاً جدا بوده است.
با این حال، هدف اصلی مهاجم خود سرور نبود؛ بلکه کلید API مربوط به CDN بود که روی آن ذخیره شده بود. دسترسی به این کلید به مهاجم اجازه میداد بدون نفوذ به سامانههای اصلی PushEngage، فایلهایی را که از طریق CDN برای وبسایتهای مشتریان ارائه میشدند تغییر داده و نسخههای دستکاریشده را جایگزین آنها کند.
در مقابل، شرکت Sansec هنوز این سناریو را قطعی نمیداند و معتقد است سامانهای که ابتدا مورد نفوذ قرار گرفته، همچنان بهطور دقیق شناسایی نشده است. این شرکت اعلام کرده محتملترین سناریو، نفوذ به سرورهای خود Awesome Motive است. سوءاستفاده از حساب CDN نیز همچنان یکی از احتمالات مطرحشده محسوب میشود، اما احتمال دخالت مستقیم ارائهدهنده CDN یعنی BunnyNet بسیار پایین ارزیابی شده است.
همچنین Sansec در تحلیل عمومی خود، ادعای PushEngage درباره نقش آسیبپذیری UpdraftPlus در این رخداد را نه بررسی کرده و نه تأیید کرده است.
وضعیت آسیبپذیری UpdraftPlus و ضرورت بهروزرسانی فوری
با وجود گمانهزنیها درباره نقش UpdraftPlus در این حمله زنجیره تأمین به وردپرس، تاکنون هیچ مدرک قطعی مبنی بر ارتباط این پلاگین با نفوذ اخیر منتشر نشده است. به همین دلیل، منشأ اولیه حمله همچنان بهطور دقیق مشخص نیست.
با این حال، UpdraftPlus دارای یک آسیبپذیری مستقل از نوع دور زدن احراز هویت (Authentication Bypass) با شناسه CVE-2026-10795 بوده است؛ یک ضعف امنیتی که شرکت Wordfence برای آن امتیاز 8.1 از 10 و سطح ریسک بالا (High Severity) را در نظر گرفته است.
این ضعف امنیتی اکنون برطرف شده است و پچ امنیتی آن در دسترس کاربران قرار دارد. همچنین، طبق گزارش Wordfence مهاجمان پیش از این تلاشهایی برای سوءاستفاده از این آسیبپذیری انجام دادهاند.
بنابراین، حتی اگر ارتباط مستقیم CVE-2026-10795 با رخداد اخیر هرگز اثبات نشود، مدیران وبسایتهایی که از پلاگین UpdraftPlus استفاده میکنند باید در اسرع وقت آن را بهروزرسانی کرده و از نصب آخرین پچهای امنیتی اطمینان حاصل کنند.
اقدامات ضروری برای بررسی آلودگی سایتها
در این حمله زنجیره تأمین به وردپرس، حذف فایلهای آلوده از زیرساخت توسعهدهندگان به این معنا نیست که وبسایتهای آلوده نیز پاکسازی شدهاند. بر اساس گزارش Sansec، فایلهای آلوده مرتبط با OptinMonster و TrustPulse تا 13 ژوئن از چرخه توزیع خارج شده بودند، اما اسکریپت دستکاریشده PushEngage همچنان تا 14 ژوئن از طریق برخی سرورهای CDN در دسترس بود.
PushEngage اعلام کرده است که پس از شناسایی رخداد، فایلهای آلوده را با نسخههای سالم جایگزین کرده، کش CDN را پاکسازی کرده، کلیدهای CDN و اعتبارنامههای مرتبط را تغییر داده و وبسایت خود را به زیرساخت جدیدی منتقل کرده است. با این حال، این اقدامات بهصورت خودکار باعث پاکسازی سایتهایی نمیشود که پیشتر مورد نفوذ قرار گرفتهاند.
از آنجا که بکدور مورد استفاده در این حمله در داشبورد وردپرس قابل مشاهده نیست، بررسی پنل مدیریت بهتنهایی نمیتواند آلودگی یا عدم آلودگی یک سایت را مشخص کند. اگر در بازه زمانی تهدید از پلاگینهای PushEngage، OptinMonster یا TrustPulse استفاده کردهاید، تنها راه قابل اعتماد برای ارزیابی وضعیت سایت، انجام اسکن سمت سرور (Server-side Scan) است.
کارشناسان تأکید میکنند که نباید آلوده بودن سایت را فقط بر اساس این فرض رد یا تأیید کرد که مدیر سایت هنگام حمله در پنل مدیریتی حضور داشته است یا خیر؛ زیرا در بسیاری از موارد اثبات این موضوع ممکن نیست.
اقدامات پیشنهادی برای بررسی و جلوگیری از آلودگی عبارتند از:
- انجام اسکن کامل در سطح سرور: هر وبسایتی که در بازه زمانی حمله از یکی از این سه پلاگین استفاده کرده است باید مستقیماً در سطح سرور بررسی شود. بررسی از طریق مرورگر یا داشبورد وردپرس کافی نیست، زیرا ممکن است پیلودی که فقط برای ادمینهای احراز هویتشده فعال میشود، در این روش قابل شناسایی نباشد
- بررسی فایلهای موجود روی سرور: در مسیر wp-content/plugins به دنبال پوشههای content-delivery-helper و database-optimizer بگردید. در چنین مواردی، معیار قابل اعتماد بررسی مستقیم فایلهای موجود در سرور است، نه اطلاعاتی که در داشبورد وردپرس نمایش داده میشود.
- شناسایی و حذف حسابهای مدیریتی مشکوک: فهرست تمام حسابهای ادمین را بررسی کنید. اگر حسابی وجود دارد که خودتان آن را ایجاد نکردهاید، آن را بهدقت بررسی کنید. بهویژه حسابهایی با نام developer_api1 یا الگوهای مشابه dev_xxxxxx میتوانند نشانهای از نفوذ باشند و باید بهدقت بررسی شده و در صورت تأیید، حذف گردند.
- تحلیل لاگهای وبسرور: لاگهای دسترسی سرور در بازه زمانی 12 تا 14 ژوئن (UTC) را بررسی کنید و به دنبال ارتباطات خروجی با دامنه cc، مسیرهای /cdn-cgi/ و همچنین آدرس IP 84.201.6.54 بگردید.
- تغییر تمامی اطلاعات دسترسی در صورت مشاهده آلودگی: در صورت مشاهده نشانه نفوذ یا آلودگی، باید بدترین سناریو را در نظر بگیرید. در این حالت لازم است همه اطلاعات دسترسی، از جمله رمزهای عبور ادمین، کلیدهای API، اطلاعات اتصال پایگاه داده و کلیدهای محرمانه (Salts) در فایل wp-config.php تغییر داده شوند. از آنجا که مهاجم ممکن است امکان اجرای کد روی سرور را داشته باشد، احتمال باقی ماندن مکانیزمهای پایداری یا بکدورهای دیگر نیز وجود دارد.