حفرهٔ Zimbra با شناسهٔ CVE-2026-73570: در ژوئیه وصله کردید؟ ببینید کسی پیش از شما وارد نشده باشد

Zimbra حفرهٔ CVE-2026-73570 را روز ۲۰ ژوئیهٔ ۲۰۲۶ در نسخهٔ 10.1.20 رفع کرد. این حفره به هر کسی که بتواند به سرور Zimbra ایمیل بفرستد اجازه می‌دهد روی آن دستور shell اجرا کند، بدون ورود و بدون هیچ کاری از طرف کاربر، به شرطی که بستهٔ اختیاری zimbra-snmp نصب و اعلان‌های SNMP روشن باشد. روز ۳۰ سپتامبر Microsoft Threat Intelligence گزارش داد مهاجمان با آن چه کرده‌اند: web shell، دسترسی root، سرقت کلیدهای احراز هویت و آرشیو صندوق‌های پستی، در سازمان‌هایی در بیش از یک منطقه و صنعت.

اگر در ژوئیه به‌روزرسانی کرده‌اید و هیچ‌وقت اعلان SNMP را روشن نکرده‌اید، می‌توانید همین‌جا متوقف شوید. بقیه دو کار دارند. اول وصله کردن. دوم، که بیشتر توصیه‌ها از آن می‌گذرند، بررسی اینکه کسی پیش از شما وارد شده یا نه، چون به‌روزرسانی حفره را می‌بندد اما web shell، خطی در sudoers یا کلید دزدیده‌شده را پاک نمی‌کند.

چرا این بار تاریخ وصله مهم‌تر از همیشه است

به گفتهٔ Microsoft، دو ابزار اسکن جداگانه بین ۲۸ ژوئیه و ۷ اوت مسیر آسیب‌پذیر را آزمایش کرده‌اند. یعنی بعد از انتشار وصله در ۲۰ ژوئیه و پیش از افشای عمومی در ۱۳ اوت. به بیان دیگر، مهاجمان سرورها را امتحان می‌کردند در حالی که بیشتر مدیران هنوز دلیلی برای عجله نداشتند. سروری که اواخر اوت به‌روز شده، در بازه‌ای در معرض خطر بوده که باگ در حال سوءاستفاده بوده است.

حمله چطور کار می‌کند، در یک بند

سرویس پایش Zimbra، یعنی swatchdog، لاگ ایمیل را برای خطوط «service status change» زیر نظر دارد و وقتی اعلان SNMP روشن باشد، یک snmptrap را از طریق shell می‌فرستد. Elastic Security Labs زنجیرهٔ حمله را بازسازی کرده: مهاجم یک دستور SMTP با آدرس خراب می‌فرستد، Postfix آن را در /var/log/zimbra.log می‌نویسد، و اگر متن شبیه خط وضعیت باشد، بخش نام سرویس به /bin/sh می‌رسد. نتیجه اجرای کد با دسترسی کاربر zimbra است. رکورد CVE امتیاز 8.9 را از طرف صادرکننده ثبت کرده است.

گام ۱: وصله کنید، یا عامل فعال‌کننده را بردارید

1. همهٔ نودهای Zimbra را به 10.1.20 یا بالاتر ارتقا دهید. Microsoft و Elastic هر دو این را تنها راه‌حل کامل می‌دانند.
2. اگر امروز نمی‌توانید ارتقا دهید، توصیهٔ موقت Microsoft این است: بستهٔ zimbra-snmp را حذف کنید، اعلان‌های SNMP را خاموش کنید و دسترسی SNMP و SMTP را به میزبان‌های مورد اعتماد محدود کنید.

به یک تست سریع با اکسپلویت به‌عنوان دلیل امن بودن اعتماد نکنید. Elastic دریافته چند اسکریپت اثبات مفهوم عمومی بارِ داده‌ای می‌نویسند که swatchdog هرگز با آن تطبیق نمی‌دهد، پس تست ناموفق ممکن است سرور آسیب‌پذیر را وصله‌شده نشان دهد. به‌جایش نسخهٔ نصب‌شده را بررسی کنید.

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

این بررسی‌ها مستقیم از رفتاری که Microsoft شرح داده آمده‌اند. آن‌ها را روی همهٔ نودهای mailbox و MTA اجرا کنید، نه فقط نودی که رو به اینترنت است، چون مهاجمان با کلید SSH خود Zimbra بین نودها جابه‌جا شده‌اند.

• Web shell. در پوشه‌های برنامهٔ وب Jetty و mailboxd، از جمله پوشه‌های کاری servlet، دنبال فایل‌های JSP بگردید که به نسخهٔ Zimbra شما تعلق ندارند. Microsoft روی هر سرور چند نسخه و روی نودهای کناری هم نسخه‌هایی دیده است.
• دسترسی sudo برای حساب zimbra. دستور sudo -l -U zimbra را اجرا کنید و در /etc/sudoers و /etc/sudoers.d/ دنبال NOPASSWD: ALL بگردید. مهاجمان دقیقاً همین خط را ساخته‌اند، با تصاحب موقت مالکیت /etc/pam.d/sudo؛ بعد فایل PAM را برگردانده‌اند اما خط sudoers را نگه داشته‌اند.
• سرویس systemd جعلی. وجود /etc/systemd/system/zimlog.service را بررسی کنید. اسمش شبیه بخشی از Zimbra است، اما Microsoft آن را دستی نصب‌شده در پوشهٔ systemd سراسری و بیرون از پوشه‌های Zimbra دیده است. مهاجمان زمان فایل را هم تغییر داده‌اند تا شبیه سرویس‌های قدیمی سیستم باشد، پس مرتب‌سازی بر اساس تاریخ آن را نشان نمی‌دهد.
• cron و پردازه‌های عجیب. crontab کاربر zimbra و root را مرور کنید و دنبال named pipe در /tmp/s یا پردازهٔ openssl s_client متصل به shell بگردید، که Microsoft آن را به‌عنوان reverse shell رمزشده دیده است.
• شواهد در لاگ. در /var/log/zimbra.log دنبال خطوط «Illegal address syntax» بگردید که $(، بک‌تیک یا عبارت «Service status change» دارند، و در لاگ وب دنبال User-Agent با نام ZB73570 که ابزارهای اسکن اولیه از آن استفاده کرده‌اند.

گام ۳: اگر چیزی پیدا کردید، کلیدها را عوض کنید، نه فقط رمزها را

Microsoft می‌گوید مهاجمان سراغ رازهای مرکزی Zimbra رفته‌اند، نه رمز تک‌تک کاربران. آن‌ها zmlocalconfig -s را اجرا کرده‌اند که اطلاعات ورود LDAP، MySQL، Postfix، Amavis و replication را نشان می‌دهد، و بعد با LDAP مقادیر zimbraPreAuthKey، zimbraAuthTokenKey و zimbraTwoFactorAuthSecret را برداشته‌اند. با کلید pre-auth یا auth token، مهاجم می‌تواند بدون دانستن رمز با هر کاربری وارد شود، پس عوض کردن رمز کاربران به‌تنهایی فایده ندارد. روی سروری که نفوذ در آن تأیید شده، برنامه‌ریزی کنید که:

1. اطلاعات ورود سرویس‌هایی را که zmlocalconfig -s نشان می‌دهد عوض کنید.
2. کلیدهای pre-auth هر دامنه و کلید auth token را دوباره بسازید تا توکن‌های امضاشده با کلیدهای دزدیده‌شده از کار بیفتند.
3. احراز هویت دومرحله‌ای را دوباره ثبت کنید، چون ممکن است رازهای مشترک کپی شده باشند.
4. کلید SSH حساب zimbra در /opt/zimbra/.ssh/ را روی همهٔ نودها عوض کنید.
5. فرض کنید محتوای صندوق‌ها خوانده شده است. Microsoft دیده که آرشیو ساخته و به بیرون منتقل شده است.

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

درس کلی‌تر برای ایمیل سازمانی روی سرور خودتان

این باگ در یک افزونهٔ پایش اختیاری بود، نه در مسیر ایمیلی که بیشتر مدیران به آن فکر می‌کنند. همان الگوی حفره‌های NetScaler است: وصله در را می‌بندد، اما رازهایی که پیش از وصله برداشته شده تا وقتی عوضشان نکنید معتبر می‌مانند. دو عادت روی هر سرور ایمیل کمک می‌کند: فقط بسته‌هایی را نصب کنید که واقعاً استفاده می‌کنید، و فهرست مکتوبی از همهٔ کلیدهایی که سرور نگه می‌دارد داشته باشید، تا عوض کردنشان بعد از حادثه یک چک‌لیست باشد، نه یک پروژهٔ تحقیقاتی. اگر بین سکوهای ایمیل خودمیزبان مقایسه می‌کنید، مقایسهٔ Mailcow، Stalwart و Mailu ساختار هر کدام را توضیح می‌دهد.

همین ماه Roundcube، یکی دیگر از وب‌میل‌های پرکاربرد، هم نسخهٔ امنیتی داد، از جمله برای یک تزریق SQL پیش از ورود که مورد سوءاستفاده است: Roundcube 1.6.20 و 1.7.5.

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

منابع: Microsoft Threat Intelligence (۳۰ سپتامبر ۲۰۲۶)، Elastic Security Labs (۲۳ اکتبر ۲۰۲۶) و NVD CVE-2026-73570.