Cảnh báo CVE-2026-73570: lỗ hổng RCE trên Zimbra đang bị khai thác, 274 mail server đã bị chiếm quyền

Ngày 22/08/2026, Shadowserver Foundation đếm được 274 máy chủ mail Zimbra trên Internet đã bị chiếm quyền qua lỗ hổng CVE-2026-73570. Hai ngày trước đó con số mới là 155. Bản vá đã có từ 20/07, tức là hơn một tháng trước khi làn sóng khai thác này bùng lên.

Nếu bạn đang tự host Zimbra Collaboration Suite cho mail doanh nghiệp, đây là việc cần xử lý trong hôm nay chứ không phải chờ đến kỳ bảo trì tháng sau.

CVE-2026-73570 là gì

Đây là lỗ hổng OS command injection (CWE-78) nằm trong thành phần giám sát SNMP của Zimbra Collaboration Suite, điểm CVSS 3.1 là 8.9 (High), vector AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L.

Cơ chế khai thác ngắn gọn: kẻ tấn công gửi một SMTP request được đặc chế, dữ liệu do attacker kiểm soát đi vào luồng xử lý SNMP notification mà không được lọc ký tự đặc biệt, và biến thành lệnh hệ thống. Không cần tài khoản, không cần nạn nhân click gì cả. Chỉ cần một kết nối SMTP tới cổng 25 đang mở ra Internet.

Lệnh chạy với quyền của user zimbra, không phải root. Nhưng với một mail server thì như vậy đã là quá đủ: user zimbra đọc được toàn bộ mailbox, cấu hình LDAP bind credential, và có chỗ để cắm webshell vào webroot.

Không phải mọi server Zimbra đều dính

Điểm này quan trọng, nói thẳng để anh em khỏi hoảng loạn không cần thiết. Lỗ hổng chỉ khai thác được khi hội đủ ba điều kiện:

1. ZCS đang chạy phiên bản thấp hơn 10.1.20
2. Có cài package tùy chọn zimbra-snmp
3. SNMP notification đang bật (snmp_notify) và service swatchdog đang chạy

Đây là cấu hình non-default. Shadowserver ghi nhận hơn 8200 instance chưa vá nhưng chính họ cũng lưu ý không phải tất cả đều khai thác được, vì cần đúng cấu hình trên. Vấn đề là swatchdog bật mặc định, và nhiều admin đã cài gói SNMP từ nhiều năm trước để làm monitoring rồi quên luôn.

Diễn biến theo mốc thời gian

• 26/06/2026: Synacor công bố lỗ hổng, kèm biện pháp giảm thiểu tạm thời
• 20/07/2026: phát hành ZCS 10.1.20 chứa bản vá chính thức
• 13/08/2026: NVD công bố hồ sơ CVE
• 17/08/2026: CERT Polska xác nhận lỗ hổng đang bị khai thác ngoài thực địa
• 20/08/2026: Shadowserver phát hiện 155 instance bị chiếm quyền
• 21/08/2026: CISA đưa CVE vào danh mục KEV, hạn chót vá cho cơ quan liên bang Mỹ là 24/08
• 22/08/2026: số instance bị chiếm quyền lên 274, tăng 77% trong 48 giờ
• 24/08/2026: 267 instance còn dấu hiệu bị chiếm quyền, dẫn đầu là Mỹ (46), Thụy Điển (21), Pháp (20), Đức (17)

Tốc độ tăng gần gấp đôi trong hai ngày cho thấy đây là khai thác tự động hàng loạt bằng tool scan, không phải tấn công có chủ đích từng mục tiêu. Nghĩa là server của bạn không cần "đáng giá" mới bị quét tới.

Một lưu ý về thông tin đang lan trên mạng xã hội: hiện chưa có nhóm tấn công nào bị quy trách nhiệm cho chiến dịch này, và cũng chưa có công bố nào xác định dữ liệu gì đã bị lấy đi từ 274 server đó. Việc Zimbra từng bị các nhóm APT nhắm tới trong quá khứ là chuyện có thật, nhưng đó là bối cảnh lịch sử chứ không phải attribution của đợt này.

Kiểm tra server của bạn có dính không

Chạy lần lượt ba lệnh sau trên máy chủ Zimbra.

Kiểm tra phiên bản:

su - zimbra -c "zmcontrol -v"

Kiểm tra package SNMP đã cài chưa:

# RHEL / CentOS / Rocky
rpm -qa | grep zimbra-snmp

# Ubuntu / Debian
dpkg -l | grep zimbra-snmp

Kiểm tra SNMP notification và swatchdog:

su - zimbra -c "zmlocalconfig snmp_notify smtp_notify"
ps aux | grep -i swatch

Nếu phiên bản dưới 10.1.20 và cả ba điều kiện đều đúng, coi như server đã phơi mình ra Internet suốt từ tháng 7 tới giờ. Vá xong vẫn phải điều tra ngược lại giai đoạn trước đó.

Xử lý ngay

1. Nâng cấp lên ZCS 10.1.20 hoặc mới hơn

Đây là ranh giới khắc phục duy nhất có giá trị. Dùng đúng quy trình upgrade của Zimbra cho môi trường của bạn, đừng thay file thủ công. Môi trường multi-node phải kiểm tra từng node một, chỉ cần sót một node là bề mặt tấn công vẫn còn nguyên.

2. Nếu chưa vá được ngay

Biện pháp tạm thời là tắt luồng SNMP notification hoặc gỡ package zimbra-snmp nếu bạn không thực sự dùng nó cho monitoring. Kèm theo đó là hạn chế truy cập SMTP từ Internet qua firewall hoặc mail gateway phía trước. Nhớ đây chỉ là compensating control, không thay thế được việc vá. Code lỗi vẫn nằm nguyên đó.

3. Giữ log trước khi dọn dẹp

Nếu nghi ngờ server đã bị đụng tới, sao lưu log và trạng thái hệ thống trước khi rotate, xóa hay rebuild. Vá trước để bịt lỗ là đúng, nhưng dọn dẹp vội sẽ xóa luôn bằng chứng cần thiết để biết chuyện gì đã xảy ra.

Săn dấu hiệu bị xâm nhập

CERT Polska công bố mấy chỉ dấu cụ thể sau. Chạy trên server đã từng ở trạng thái dễ bị tấn công.

Tìm entry bất thường trong log Zimbra. Trường tên service lẽ ra chỉ chứa tên dịch vụ, nếu thấy dấu chấm phẩy, pipe, backtick, chuỗi base64, URL hay địa chỉ IP thì đó là dấu hiệu inject:

grep -n "Service status change:" /var/log/zimbra.log

Tìm file lạ do user zimbra tạo trong webroot Jetty 30 ngày gần nhất. Bất kỳ file JSP hay JSPX nào bạn không tự đặt vào đều đáng nghi là webshell:

find /opt/zimbra/jetty/webapps /opt/zimbra/jetty_base/webapps \
  -user zimbra -mtime -30 -type f \
  \( -name "*.jsp" -o -name "*.jspx" \) -ls 2>/dev/null

Tìm payload được stage trong thư mục tạm:

find /tmp -user zimbra -mtime -30 -type f -ls 2>/dev/null

Ngoài ra nên soi thêm: process con bất thường sinh ra từ tiến trình Java hoặc SNMP của Zimbra (sh, bash, curl, wget, python, perl, base64), kết nối outbound từ user zimbra tới IP lạ ngoài dải mail relay quen thuộc, cron job mới, khóa SSH mới, và các rule forward mail được thêm sau mốc thời gian nghi ngờ.

Lưu ý là các lệnh trên không phải công cụ khẳng định bị hack. Hoạt động hợp lệ của Zimbra cũng tạo file. Mục tiêu là tìm ra điểm bất thường để đào sâu tiếp.

Nếu xác nhận đã bị xâm nhập

Xóa được cái webshell đầu tiên tìm thấy không có nghĩa là server sạch. Với một mail server bị chiếm quyền, quy trình tối thiểu là:

• Cô lập server khỏi mạng nội bộ và Internet trước khi điều tra sâu
• Đổi toàn bộ credential mà host đó chạm tới được: LDAP bind, tài khoản admin, API key, mật khẩu người dùng, token phiên
• Rà soát rule forward và delegate quyền mailbox, đây là cách phổ biến để duy trì truy cập mail sau khi mất webshell
• Cân nhắc dựng lại server từ đầu và migrate dữ liệu mailbox sang, thay vì dọn tại chỗ
• Đánh giá phạm vi rò rỉ dữ liệu, mail server nằm ở trung tâm liên lạc nên thiệt hại hiếm khi dừng ở một máy

Bài học rút ra

Không có zero-day nào ở đây. Bản vá đã nằm sẵn 33 ngày trước khi Shadowserver đếm được 274 nạn nhân. Toàn bộ thiệt hại đến từ khoảng trống giữa lúc vendor phát hành fix và lúc admin thực sự cài nó.

Với hạ tầng tự host, mail server là mục tiêu ưu tiên vì nó vừa mở cổng ra Internet 24/7, vừa nắm dữ liệu nhạy cảm nhất của doanh nghiệp, vừa được các hệ thống khác tin tưởng. Nếu bạn tự vận hành Zimbra, tối thiểu nên có: theo dõi advisory của vendor, một quy trình vá khẩn cấp tách khỏi lịch bảo trì thường kỳ, và gỡ bỏ những package tùy chọn không dùng tới.

Nếu bạn đang chạy Zimbra trên VPS tại TND và cần hỗ trợ kiểm tra phiên bản, nâng cấp lên 10.1.20 hay rà soát dấu hiệu xâm nhập, liên hệ bên mình qua kênh support hoặc [email protected]. Với doanh nghiệp không muốn gánh phần vận hành và vá lỗi mail server, chuyển sang mail dịch vụ có nhà cung cấp chịu trách nhiệm bản vá cũng là một hướng đáng cân nhắc.

Nguồn tham khảo

• Zimbra, Patch Release Update: Zimbra 10.1.20, 20/07/2026
• CERT Polska, cảnh báo khai thác thực địa CVE-2026-73570, 17/08/2026
• CISA Known Exploited Vulnerabilities Catalog, bổ sung ngày 21/08/2026
• Shadowserver Foundation, thống kê quét Internet ngày 20-24/08/2026
• NVD, hồ sơ CVE-2026-73570