کلیدهای UpdraftCentral دزدیده شد: همهٔ سایت‌های UpdraftPlus را بررسی کنید، حتی به‌روزشده‌ها

آخر هفتهٔ ۱۷ و ۱۸ اکتبر ۲۰۲۶ کسی به teamupdraft.com، شرکت سازندهٔ UpdraftPlus، نفوذ کرد. به گفتهٔ TeamUpdraft پایگاه دادهٔ مشتریان که احتمالاً به آن دسترسی پیدا شده، کلیدهای اتصال UpdraftCentral، سرویس مدیریت از راه دور این شرکت، را هم در خود داشت. چند ساعت بعد همین کلیدها برای نصب افزونه‌های درِ پشتی روی سایت‌های وردپرسی به کار رفتند. UpdraftPlus افزونهٔ پشتیبان‌گیری است که بیش از ۴ میلیون نصب فعال دارد؛ پس حتی سهم کوچکی از سایت‌های متصل یعنی تعداد زیادی سرور.

این ماجرا شبیه یک باگ معمولی افزونه نیست. فرمان‌های مخرب با کلیدهای واقعی امضا شده بودند و افزونه آن‌ها را مشروع می‌دانست. Patchstack می‌گوید جدیدترین نسخه‌های آن زمان هم دقیقاً مثل نسخه‌های قدیمی آسیب‌پذیر بودند. TeamUpdraft هم در ۲۹ اکتبر اضافه کرد که برخی سایت‌هایی که در موج اول آلوده شدند ظاهر سالمی داشتند و چند روز بعد صاحب یک حساب مدیر تازه شدند. به‌روزرسانی افزونه لازم است، ولی کار با آن تمام نمی‌شود.

چه اتفاقی افتاد، به ترتیب

• ۱۸ اکتبر، ساعت ۱۵:۳۲: اولین نصب درِ پشتی در داده‌های تله‌متری Patchstack. آخرین مورد ثبت‌شده در آن موج ساعت ۰۹:۲۳ روز ۱۹ اکتبر بود.
• ۱۹ اکتبر: Nethemba که حمله را روی سایت‌های خودش دیده بود، اولین تحلیل فنی را منتشر کرد. Wordfence قانون فایروالی منتشر کرد که فرمان‌های UpdraftCentral را روی نسخه‌های آسیب‌دیده مسدود می‌کند و آن را به‌جای تأخیر معمول ۳۰ روزه، ظرف چند ساعت به کاربران رایگان هم داد.
• ۱۹ اکتبر: نسخهٔ 1.26.12 برای باطل کردن کلیدهای ابری ساخته‌شده پیش از حادثه منتشر شد و 1.26.13 همان روز آمد، چون ابطال در 1.26.12 درست اعمال نمی‌شد. نسخه‌های Premium شمارهٔ 2.26.12 و 2.26.13 دارند.
• ۲۱ اکتبر: Nethemba گزارش داد مهاجم بعد از انتشار 1.26.13 هم فرمان‌های تازهٔ UpdraftCentral به دو سایت آن‌ها فرستاده است. فروشنده بعداً زمان مرز ابطال را به ساعت ۱۲:۰۷ UTC روز ۱۸ اکتبر اصلاح کرد؛ یعنی کلیدهایی که بعد از آن لحظه ساخته شده‌اند خودکار باطل نمی‌شوند.
• ۲۶ اکتبر: UpdraftPlus 1.26.14 دیگر هنگام اتصال حساب TeamUpdraft، سایت را به‌طور پیش‌فرض به UpdraftCentral اضافه نمی‌کند.
• ۲۹ اکتبر: TeamUpdraft نوشت: «افزونه‌ای که مهاجم نصب کرده بود سر جایش ماند و بعداً، پس از قطع اتصال سایت از UpdraftCentral، برای ساختن یک حساب مدیر جدید استفاده شد.»

چرا سایت‌هایی که هرگز از UpdraftCentral استفاده نکرده‌اند هم در خطرند

کلاینت UpdraftCentral داخل همهٔ نسخه‌های UpdraftPlus، رایگان و Premium، وجود دارد و تا وقتی سایت کلیدی نداشته باشد غیرفعال می‌ماند. به گفتهٔ Patchstack، صفحهٔ اتصال حساب TeamUpdraft.com یک چک‌باکس داشت که به‌طور پیش‌فرض تیک خورده بود و هم‌زمان سایت را به UpdraftCentral اضافه می‌کرد. خیلی‌ها برای UpdraftVault یا فعال‌سازی لایسنس حساب را وصل کردند و بی‌آنکه متوجه شوند، سایت را وارد مدیریت از راه دور کردند. Patchstack کلیدهایی هم پیدا کرد که نوامبر ۲۰۲۵ صادر شده بودند و در اکتبر ۲۰۲۶ هنوز کار می‌کردند.

خود درِ پشتی طوری ساخته شده که از بررسی‌های معمول رد شود. Patchstack توضیح می‌دهد که حسابی با نقش ویرایشگر (Editor) می‌سازد و بی‌سروصدا دسترسی‌های manage_options و install_plugins را به آن می‌دهد. اگر فقط فهرست مدیرها را نگاه کنید، آن را نمی‌بینید. ورود با تنظیم مستقیم کوکی انجام می‌شود، پس احراز هویت دومرحله‌ای و افزونه‌های محدودکنندهٔ ورود اصلاً اجرا نمی‌شوند. این حساب بعد از حذف افزونه هم باقی می‌ماند.

در همین کانال یک مشکل قدیمی‌تر هم هست. فروشنده در ژوئن ۲۰۲۶ آسیب‌پذیری CVE-2026-10795 را در نسخه‌های 1.26.5 و 2.26.5 رفع کرد؛ نقصی که اجازه می‌داد بدون هیچ کلیدی فرمان UpdraftCentral جعل شود. Patchstack می‌گوید تلاش برای سوءاستفاده از آن هنوز ادامه دارد، پس سایتی که پایین‌تر از این نسخه‌هاست با هر دو مشکل روبه‌روست.

گام ۱: پیدا کنید کدام سایت‌ها کلید دارند

این دستورها را در ریشهٔ وردپرس هر سایت اجرا کنید. پرچم‌های --skip-plugins --skip-themes مهم‌اند: Nethemba یادآوری می‌کند که برخی نمونه‌های درِ پشتی خطای مرگبار می‌دهند و اگر WP-CLI بارشان کند از کار می‌افتد.

wp plugin list --fields=name,version,update --skip-plugins --skip-themes
wp option get updraft_central_localkeys --format=json --skip-plugins --skip-themes

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

بعد فایل‌های افزونه‌ها را با نسخهٔ wordpress.org مقایسه کنید:

wp plugin verify-checksums --all --skip-plugins --skip-themes

این دستور فقط افزونه‌های میزبانی‌شده در wordpress.org را بررسی می‌کند. افزونه‌های Premium و سفارشی با یک هشدار رد می‌شوند و هر درِ پشتی هم همین‌طور، چون هیچ‌کدام checksum منتشرشده ندارند. فهرست رد‌شده‌ها را خط به خط بخوانید. هر نامی در آن باید چیزی باشد که خودتان آگاهانه نصب کرده‌اید.

گام ۲: همین بررسی روی تعداد زیادی سایت در Docker

ایمیج رسمی wordpress شامل WP-CLI نیست، اما نسخهٔ wordpress:cli می‌تواند به کانتینر در حال اجرای سایت وصل شود. مستندات Docker می‌گوید این کانتینر به فایل‌های سایت، شبکهٔ آن و همان متغیرهای محیطی WORDPRESS_* نیاز دارد، چون wp-config.php ایمیج مستقیماً آن‌ها را می‌خواند. همچنین هشدار می‌دهد که ایمیج CLI با UID 82 اجرا می‌شود در حالی که ایمیج‌های وردپرس مبتنی بر Debian از UID 33 استفاده می‌کنند، پس معمولاً --user 33:33 لازم است. این حلقه همهٔ این‌ها را برای هر کانتینر وردپرس در حال اجرا روی یک سرور کنار هم می‌گذارد:

for c in $(docker ps --format '{{.Names}} {{.Image}}' | awk '$2 ~ /wordpress/ && $2 !~ /cli/ {print $1}'); do
  env=$(mktemp)
  docker inspect -f '{{range .Config.Env}}{{println .}}{{end}}' "$c" | grep '^WORDPRESS_' > "$env"
  echo "== $c"
  docker run --rm --volumes-from "$c" --network "container:$c" \
    --env-file "$env" --user 33:33 -e HOME=/tmp wordpress:cli \
    sh -c 'wp plugin get updraftplus --field=version --skip-plugins --skip-themes;
           wp option get updraft_central_localkeys --format=json --skip-plugins --skip-themes'
  rm -f "$env"
done

فایل env موقت رمز پایگاه داده را در خود دارد و به همین دلیل حلقه بلافاصله پاکش می‌کند. اگر سایت‌هایتان رمزها را از متغیرهای *_FILE می‌خوانند، آن فایل‌ها را هم در کانتینر CLI مونت کنید. برای اجرای هر کدام از بررسی‌های این مقاله روی کل سرورها، کافی است دستورهای داخلی را عوض کنید.

گام ۳: اول کانال را قطع کنید، بعد به‌روزرسانی

حذف کلید روی هر نسخه‌ای کار می‌کند و جلوی فرمان‌های تازه را فوراً می‌گیرد:

wp option delete updraft_central_localkeys --skip-plugins --skip-themes
wp option delete updraft_migrator_localkeys --skip-plugins --skip-themes

خط دوم کلیدهای Migrator را پاک می‌کند که Nethemba توصیه می‌کند حذف شوند، مگر اینکه وسط یک مهاجرت باشید. حذف سایت از داشبورد UpdraftCentral کافی نیست، چون کلید اصلی روی خود سایت است. پشتیبان‌گیری بعد از حذف کلید ادامه پیدا می‌کند.

سپس به‌روزرسانی کنید. برای نسخهٔ رایگان، wp plugin update updraftplus کافی است. نسخهٔ Premium از به‌روزرسان متصل به لایسنس خودش استفاده می‌کند که با --skip-plugins بارگذاری نمی‌شود؛ پس بعد از اینکه سایت بررسی‌های زیر را گذراند، آن را از wp-admin به‌روز کنید یا بستهٔ آن را از حساب TeamUpdraft بارگذاری کنید. هدف 1.26.14 یا 2.26.14 است و هرگز روی 1.26.12 نمانید. اگر Dockerfile شما افزونه‌ها را داخل ایمیج کپی می‌کند و wp-content روی volume نیست، نسخه را همان‌جا عوض کنید و ایمیج را دوباره بسازید، وگرنه استقرار بعدی افزونهٔ قدیمی را برمی‌گرداند.

گام ۴: دنبال ردپای مهاجم بگردید

از فایل‌ها شروع کنید. برخی نمونه‌ها خود را از صفحهٔ افزونه‌های وردپرس پنهان می‌کنند، به همین دلیل TeamUpdraft می‌گوید پوشه‌های wp-content/plugins/ و wp-content/mu-plugins/ را مستقیم بررسی کنید. بهترین نشانهٔ Patchstack در سطح فایل، یک خط توضیح مشترک در نمونه‌هاست:

grep -rl "Small maintenance toolkit: keeps option storage tidy\." wp-content/plugins/ wp-content/mu-plugins/

فقط به این رشته تکیه نکنید. Nethemba نسخه‌های بعدی را با توضیحات دیگر ثبت کرده است: یک نسخهٔ تک‌فایلی و یکی به نام site-health-cache که خودش را از فهرست افزونه‌ها حذف می‌کند. مقالهٔ آن‌ها نام‌ها، کلیدهای option و هش‌های SHA-256 را دارد، به‌علاوهٔ یک ابزار بررسی فقط‌خواندنی که با wp eval-file check-updraftcentral.php --skip-plugins --skip-themes اجرا می‌شود.

بعد سراغ حساب‌ها بروید. بر اساس دسترسی بررسی کنید، نه نام نقش. کوئری Patchstack پیشوند پیش‌فرض wp_ را فرض می‌کند و wp db prefix پیشوند شما را نشان می‌دهد:

wp db query "SELECT u.user_login,u.user_email FROM wp_users u
  JOIN wp_usermeta m ON m.user_id=u.ID
  WHERE m.meta_key='wp_capabilities'
    AND m.meta_value LIKE '%editor%' AND m.meta_value LIKE '%manage_options%'"
wp option list --search='*_sync_token' --fields=option_name --skip-plugins --skip-themes

نام‌های کاربری تأییدشده تا امروز الگوی دو کلمه به‌علاوهٔ دو رقم دارند، مثل data-ops43، با نشانی @example.org و نام نمایشی «Site Tools». Nethemba نوع دومی را هم گزارش کرده که از @example.com و نام‌هایی مثل «System Team» استفاده می‌کند.

در آخر لاگ‌ها. پیدا شدن پارامتر فعال‌ساز یعنی درِ پشتی استفاده شده، نه اینکه فقط نصب شده باشد. نسخه‌های Apache ایمیج رسمی وردپرس لاگ‌ها را به stdout می‌فرستند، پس در Docker می‌توانید با docker logs جست‌وجو کنید:

docker logs mysite 2>&1 | grep -E '[?&]_[A-Za-z0-9]{4,10}=[A-Za-z0-9_]{32}([&"[:space:]]|$)'

Patchstack نشانی‌های 43.250.53.42 و 2a09:bac5:4e21:2e3c::49b:9 را به‌عنوان مبدأ فهرست کرده، اما مهاجم در کمتر از یک روز زیرساختش را عوض کرد. IPها را عبارت جست‌وجو بدانید، نه فهرست مسدودسازی‌ای که امنیت شما را تضمین کند.

گام ۵: پاک‌سازی و تعویض اعتبارنامه‌ها

اگر درِ پشتی پیدا کردید، ترتیب کار مهم است. اول کلید UpdraftCentral را حذف کنید، وگرنه مهاجم می‌تواند نسخهٔ جایگزین بفرستد. بعد افزونه را غیرفعال کنید و پوشه‌اش را به بیرون از ریشهٔ وب منتقل کنید، نه اینکه از wp-admin حذفش کنید؛ Patchstack دریافته که روال حذف آن ردپای خودش را پاک می‌کند. Patchstack همچنین هشدار می‌دهد که خطای مرگبار نمونه‌های معیوب را اصلاح نکنید، چون این کار درِ پشتی را روشن می‌کند. گزینهٔ _sync_token و حساب غیرمجاز را حذف کنید.

سپس اعتبارنامه‌ها را عوض کنید، چه روی آن سایت چیزی پیدا کرده باشید چه نه:

• wp config shuffle-salts تا همهٔ کوکی‌های ورود، از جمله کوکی ماندگار مهاجم، باطل شوند.
• رمز تازه برای همهٔ مدیرها و ویرایشگرها.
• رمز حساب teamupdraft.com و تنظیمات دومرحله‌ای آن، که TeamUpdraft از همهٔ دارندگان حساب خواسته است.
• اعتبارنامه‌های فضای ذخیره‌سازی راه دور. Wordfence توصیهٔ TeamUpdraft را نقل می‌کند که روی هر سایتی که از طریق UpdraftCentral به آن دسترسی پیدا شده، فضای ذخیره‌سازی دوباره مجوز بگیرد و کلیدهای دسترسی آن عوض شود. Nethemba اضافه می‌کند که نسخهٔ Premium ممکن است رمز حساب را به‌صورت متن ساده در گزینهٔ updraftplus-addons_options نگه دارد.
• سایت‌های UpdraftVault باید از بخش Settings دوباره متصل شوند و بعد یک پشتیبان آزمایشی گرفته شود.

اگر آن حساب وجود دارد یا پارامتر فعال‌ساز در لاگ‌هایتان دیده می‌شود، سایت را کاملاً آلوده فرض کنید. از پشتیبانی که پیش از ۱۷ اکتبر گرفته شده بازیابی کنید، رمز پایگاه داده و رازهای wp-config.php را عوض کنید و فقط بعد از آن چیزی را دوباره وصل کنید. اینکه چرا پشتیبان‌ها باید دور از دسترس مهاجم باشند را در مقالهٔ باج‌افزار SafePay توضیح داده‌ایم، و اینکه چرا وصله به‌تنهایی نفوذ را خنثی نمی‌کند را در مقالهٔ NetScaler.

نظر ما

کلید مدیریت از راه دور به دارنده‌اش اجازه می‌دهد بدون تأیید هیچ‌کس روی سایت شما کد نصب کند. این کلید همان مراقبتی را می‌خواهد که یک کلید SSH: آگاهانه صادرش کنید، تا جایی که می‌شود آن را به حسابی بدون install_plugins بدهید (Patchstack دید که همین یک جزئیات جلوی حمله را روی یکی از سایت‌های تحلیل‌شده گرفت)، و وقتی کسی از آن استفاده نمی‌کند حذفش کنید. روی بیشتر سایت‌هایی که فقط پشتیبان‌گیری می‌کنند، تعداد درست کلیدهای UpdraftCentral صفر است. اگر وردپرس را در کانتینر اجرا می‌کنید، حالا که سراغش رفته‌اید PHP زیرین را هم بررسی کنید؛ راهنمای PHP2Shell روشش را نشان می‌دهد.

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

منابع: اطلاعیهٔ حادثهٔ TeamUpdraft (به‌روزشده در ۲۹ اکتبر ۲۰۲۶)، Patchstack، اطلاعیهٔ Wordfence، تحلیل Nethemba (به‌روزشده در ۲۶ اکتبر ۲۰۲۶)، تغییرات UpdraftPlus در wordpress.org و مستندات ایمیج رسمی وردپرس در Docker.