CVE-2026-73570 là lỗ hổng OS Command Injection nghiêm trọng trong Zimbra Collaboration Suite (ZCS), liên quan đến thành phần SNMP notification.

Trong điều kiện bị ảnh hưởng, kẻ tấn công từ Internet có thể gửi SMTP request được tạo đặc biệt và khiến máy chủ thực thi lệnh hệ điều hành dưới quyền user zimbra mà không cần tài khoản đăng nhập Zimbra hợp lệ.

Theo thông tin công bố, các máy chủ sử dụng phiên bản Zimbra trước 10.1.20, có cài đặt zimbra-snmp và bật SNMP notification cần được ưu tiên kiểm tra.

Zimbra đã phát hành bản vá trong phiên bản ZCS 10.1.20.

CVE-2026-73570 cũng đã được đưa vào danh mục Known Exploited Vulnerabilities – KEV của CISA, cho thấy lỗ hổng đã được ghi nhận khai thác thực tế.

Lưu ý: Bài viết tập trung vào việc kiểm tra, phát hiện dấu hiệu compromise và xử lý phòng thủ. Không bao gồm mã khai thác hoặc payload tấn công.

---

1. CVE-2026-73570 là gì?

CVE-2026-73570 thuộc nhóm lỗi:

CWE-78 – OS Command Injection

Lỗ hổng liên quan đến quá trình xử lý SNMP notification của Zimbra.

Dữ liệu không tin cậy có thể được xử lý không an toàn trước khi được chuyển tới cơ chế thực thi command, từ đó dẫn tới khả năng OS Command Injection.

Có thể hình dung chuỗi tấn công như sau:

Internet
    ↓
SMTP request được tạo đặc biệt
    ↓
Zimbra SMTP
    ↓
SNMP Notification
    ↓
OS Command Injection
    ↓
Thực thi command dưới user zimbra
    ↓
Payload / Persistence / Malware

Điểm nguy hiểm là attacker có thể khai thác từ xa mà không cần có mailbox hoặc tài khoản Zimbra hợp lệ.

Quyền thực thi ban đầu là user:

zimbra

không phải root.

Tuy nhiên đây vẫn là mức ảnh hưởng nghiêm trọng bởi user zimbra có quyền truy cập và vận hành nhiều thành phần quan trọng của hệ thống mail.

---

2. Máy chủ Zimbra nào có nguy cơ?

Nên ưu tiên kiểm tra nếu server đáp ứng các điều kiện:

• Đang chạy Zimbra Collaboration Suite.
• Phiên bản thấp hơn 10.1.20.
• Có package zimbra-snmp.
• SNMP notification đang được bật.
• SMTP server được public ra Internet.

---

3. Kiểm tra phiên bản Zimbra

Đăng nhập SSH vào server và chạy:

su - zimbra -c 'zmcontrol -v'

Hoặc:

su - zimbra
zmcontrol -v

Ví dụ:

Release 10.1.19.GA...

Nếu phiên bản thấp hơn:

10.1.20

thì nên tiếp tục kiểm tra SNMP và các dấu hiệu compromise.

 

---

4. Kiểm tra package SNMP

Với Ubuntu/Debian:

dpkg -l | grep -E 'zimbra-snmp|zimbra-net-snmp'

Với hệ điều hành sử dụng RPM:

rpm -qa | grep -E 'zimbra-snmp|zimbra-net-snmp'

Nếu server có package liên quan đến SNMP, tiếp tục kiểm tra service.

su - zimbra -c 'zmprov gs $(zmhostname) zimbraServiceEnabled | grep -i snmp'

Nếu xuất hiện:

zimbraServiceEnabled: snmp

nghĩa là SNMP service đang được enable trên server.

---

5. Kiểm tra SNMP notification

Chạy:

su - zimbra -c 'zmlocalconfig snmp_notify'

Nếu kết quả:

snmp_notify = yes

thì SNMP notification đang được bật.

Trong trường hợp máy chủ đồng thời đang chạy phiên bản vulnerable, cần ưu tiên cập nhật bản vá.

---

6. Kiểm tra trạng thái dịch vụ Zimbra

Trước khi thực hiện thay đổi, nên lưu lại trạng thái hiện tại:

su - zimbra -c 'zmcontrol status'

Ví dụ:

Host mail.example.com
    amavis                  Running
    antispam                Running
    antivirus               Running
    ldap                    Running
    logger                  Running
    mailbox                 Running
    memcached               Running
    mta                     Running
    proxy                   Running
    snmp                    Running
    stats                   Running

Một điểm cần lưu ý:

Tất cả service đang Running không có nghĩa server chắc chắn chưa bị compromise.

Malware vẫn có thể hoạt động dưới user zimbra trong khi Zimbra hoạt động bình thường.

---

7. Kiểm tra dấu hiệu máy chủ đã bị khai thác

Server thuộc phiên bản vulnerable không đồng nghĩa chắc chắn đã bị hack.

Cần kiểm tra thêm các dấu hiệu bất thường.

---

7.1. Kiểm tra /dev/shm

Chạy:

ls -lah /dev/shm

Liệt kê chi tiết file:

find /dev/shm -maxdepth 1 -type f \
-printf '%TY-%Tm-%Td %TH:%TM:%TS %u %g %m %s %p\n' | sort

/dev/shm là vùng shared memory dạng tmpfs.

Malware có thể sử dụng vị trí này để:

• Lưu binary tạm thời.
• Chạy payload.
• Tạo file persistence.
• Lưu script tải malware.

Tuy nhiên:

Không được kết luận file là malware chỉ vì file nằm trong /dev/shm.

Cần kiểm tra thêm:

• Owner.
• Process đang sử dụng.
• Hash.
• Thời gian tạo.
• Nội dung file.

---

7.2. Kiểm tra cron của user zimbra

Chạy:

crontab -l -u zimbra

Đặc biệt chú ý cron gọi file từ:

/dev/shm
/tmp
/var/tmp

Ví dụ dạng đáng nghi:

* * * * * /dev/shm/<random-file>

Nếu một file lạ được chạy mỗi phút, đây là dấu hiệu cần điều tra.

Backup cron trước khi thay đổi:

crontab -l -u zimbra \
> /root/zimbra-crontab-$(date +%F-%H%M%S).txt 2>&1

---

7.3. Kiểm tra process của user zimbra

Chạy:

ps -fu zimbra

Hoặc:

ps auxf | grep '[z]imbra'

Có thể kiểm tra executable thực tế:

for pid in $(pgrep -u zimbra); do
    echo "===== PID $pid ====="
    readlink -f /proc/$pid/exe 2>/dev/null
    tr '\0' ' ' < /proc/$pid/cmdline 2>/dev/null
    echo
done

Nếu process thuộc user zimbra đang chạy binary từ:

/dev/shm/
/tmp/
/var/tmp/

thì cần ưu tiên kiểm tra.

---

7.4. Kiểm tra kết nối mạng

Chạy:

ss -tunap

Hoặc:

lsof -nP -i -a -u zimbra

Cần lưu ý các outbound connection:

• Tới IP Internet không rõ nguồn gốc.
• Connection được duy trì liên tục.
• Port bất thường.
• Process không thuộc thành phần Zimbra quen thuộc.

---

7.5. Kiểm tra file mới được tạo bởi user zimbra

Có thể kiểm tra:

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

Lệnh trên tìm các file thuộc user zimbra được thay đổi trong vòng 30 ngày gần nhất.

Không nên chạy:

find /

trên production server lớn nếu không cần thiết vì có thể tạo thêm I/O cho hệ thống.

---

8. Vì sao chỉ xóa file malware là chưa đủ?

Giả sử phát hiện file:

/dev/shm/<malware>

và chỉ thực hiện:

rm -f /dev/shm/<malware>

thì chưa thể kết luận server đã sạch.

File có thể được tạo lại bởi:

• Process vẫn đang chạy trong RAM.
• Cron persistence.
• Systemd timer.
• Systemd service.
• Webshell.
• Script khác.
• Máy chủ tiếp tục bị khai thác do chưa vá.

Quy trình đúng nên theo hướng:

Containment
      ↓
Thu thập evidence
      ↓
Xác định persistence
      ↓
Dừng malicious process
      ↓
Quarantine malware
      ↓
Patch Zimbra
      ↓
Kiểm tra lại hệ thống

---

9. Quy trình xử lý khi nghi ngờ server đã bị compromise

Đối với server production, không nên xóa file ngay khi phát hiện dấu hiệu bất thường.

Nên thu thập evidence trước.

---

Bước 1: Tạo thư mục lưu thông tin incident

TS=$(date +%Y%m%d_%H%M%S)
INC="/root/zimbra-incident-$TS"

mkdir -p "$INC"

---

Bước 2: Lưu danh sách process

ps auxf > "$INC/process.txt"

---

Bước 3: Lưu kết nối mạng

ss -tunap > "$INC/network.txt"

---

Bước 4: Lưu cron của user zimbra

crontab -l -u zimbra \
> "$INC/zimbra-crontab.txt" 2>&1

---

Bước 5: Lưu thông tin /dev/shm

ls -lah /dev/shm \
> "$INC/dev-shm.txt"

---

Bước 6: Lưu trạng thái Zimbra

su - zimbra -c 'zmcontrol status' \
> "$INC/zmcontrol-status.txt" 2>&1

Lưu version:

su - zimbra -c 'zmcontrol -v' \
> "$INC/zimbra-version.txt" 2>&1

---

10. Tạm thời tắt SNMP notification

Nếu chưa thể patch ngay, có thể cân nhắc disable SNMP notification để giảm vector tấn công.

Kiểm tra:

su - zimbra -c 'zmlocalconfig snmp_notify'

Tắt:

su - zimbra -c 'zmlocalconfig -e snmp_notify=no'

Kiểm tra lại:

su - zimbra -c 'zmlocalconfig snmp_notify'

Kết quả:

snmp_notify = no

Đây chỉ là giải pháp containment tạm thời.

Giải pháp chính vẫn là upgrade Zimbra lên phiên bản đã vá.

Nếu doanh nghiệp đang sử dụng SNMP để giám sát hệ thống thì cần lưu ý việc tắt SNMP notification có thể ảnh hưởng monitoring.

---

11. Xác định process sử dụng file nghi ngờ

Ví dụ:

lsof /dev/shm/<suspicious-file>

Hoặc:

fuser -v /dev/shm/<suspicious-file>

Kiểm tra hash:

sha256sum /dev/shm/<suspicious-file>

Kiểm tra metadata:

stat /dev/shm/<suspicious-file>

Nếu đã xác định process độc:

kill <PID>

Nếu process không dừng:

kill -9 <PID>

Không nên sử dụng pkill với pattern quá rộng vì có thể kill nhầm process Zimbra hợp lệ.

---

12. Kiểm tra persistence

Ngoài cron của user zimbra, cần kiểm tra thêm.

Systemd timer

systemctl list-timers --all

Systemd service

systemctl list-unit-files --type=service

Cron hệ thống

find /etc/cron* -type f -mtime -30 -ls 2>/dev/null

Cron spool

find /var/spool/cron -type f -mtime -30 -ls 2>/dev/null

Không xóa entry chỉ vì thấy lạ.

Cần xác minh xem entry có thuộc hệ thống hoặc phần mềm hợp lệ hay không.

---

13. Quarantine malware thay vì xóa ngay

Tạo thư mục quarantine:

QUA="/root/zimbra-quarantine-$(date +%Y%m%d_%H%M%S)"
mkdir -p "$QUA"

Copy evidence:

cp -a /dev/shm/<suspicious-file> "$INC/"

Di chuyển malware:

mv /dev/shm/<suspicious-file> "$QUA/"

Tính SHA256:

sha256sum "$QUA"/* \
> "$QUA/sha256.txt" 2>/dev/null

Sau đó có thể hạn chế quyền:

chmod -R 000 "$QUA"

Việc giữ lại hash và file giúp phục vụ:

• Điều tra incident.
• Đối chiếu IOC.
• Kiểm tra bằng antivirus.
• So sánh với các server khác.

---

14. Kiểm tra JSP/Webshell

Sau khi attacker có khả năng chạy command dưới user zimbra, không nên giả định /dev/shm là persistence duy nhất.

Một vị trí cần kiểm tra là Jetty webapps.

find /opt/zimbra/jetty/webapps \
     /opt/zimbra/jetty_base/webapps \
-type f \( -iname '*.jsp' -o -iname '*.jspx' \) \
-printf '%TY-%Tm-%Td %TH:%TM:%TS %u %g %s %p\n' \
2>/dev/null | sort

Kiểm tra file được thay đổi gần đây:

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

Cần lưu ý:

File JSP mới không mặc định là webshell.

File có thể thuộc:

• Zimbra patch.
• Zimlet.
• Customization.
• Web application hợp lệ.

Cần kiểm tra nội dung, package, owner và hash trước khi xử lý.

---

15. Kiểm tra SSH persistence

Kiểm tra user hệ thống:

awk -F: '$3 >= 1000 {print $1,$3,$6,$7}' /etc/passwd

Kiểm tra SSH authorized keys:

find /root /home /opt/zimbra \
-name authorized_keys -type f \
-print -exec cat {} \; 2>/dev/null

Nếu phát hiện key lạ, cần đối chiếu với key quản trị hợp lệ trước khi xóa.

---

16. Upgrade Zimbra để vá CVE-2026-73570

Zimbra đã sửa lỗi liên quan trong:

Zimbra Collaboration 10.1.20

Nếu đang sử dụng phiên bản vulnerable, nên nâng lên:

10.1.20

hoặc phiên bản mới hơn đang được Zimbra hỗ trợ.

Trước khi upgrade nên:

• Backup mailbox.
• Backup database.
• Backup configuration.
• Kiểm tra dung lượng ổ đĩa.
• Kiểm tra repository.
• Đọc release notes.
• Xác nhận OS tương thích.
• Chuẩn bị phương án rollback.

Sau khi update:

su - zimbra -c 'zmcontrol -v'

Tiếp tục kiểm tra service:

su - zimbra -c 'zmcontrol status'

---

17. Kiểm tra sau khi xử lý

Kiểm tra /dev/shm

ls -lah /dev/shm

Kiểm tra cron

crontab -l -u zimbra

Kiểm tra process

ps -fu zimbra

Kiểm tra network

ss -tunap

Kiểm tra dịch vụ

su - zimbra -c 'zmcontrol status'

Kiểm tra version

su - zimbra -c 'zmcontrol -v'

Kiểm tra mail queue

/opt/zimbra/common/sbin/postqueue -p

Nếu malware hoặc file bất thường tiếp tục xuất hiện lại sau khi đã xóa thì rất có thể:

persistence vẫn còn

hoặc:

vector khai thác chưa được xử lý triệt để

---

18. Có mất dữ liệu email khi xử lý không?

Các thao tác:

• Disable SNMP notification.
• Dừng malicious process.
• Xóa persistence.
• Quarantine malware.
• Upgrade Zimbra.

không trực tiếp xóa mailbox.

Dữ liệu email Zimbra thường nằm tại:

/opt/zimbra/store/

Database nằm tại:

/opt/zimbra/db/data/

Do đó tuyệt đối không tự ý:

xóa
move
chỉnh sửa

các thư mục trên nếu chưa xác định database hoặc mailbox thực sự gặp sự cố.

---

19. Không recovery MySQL nếu database vẫn bình thường

CVE-2026-73570 là lỗi OS Command Injection.

Nó không đồng nghĩa database Zimbra chắc chắn đã bị lỗi.

Kiểm tra:

su - zimbra -c 'zmcontrol status'

Kiểm tra MySQL:

su - zimbra -c 'mysql.server status'

Kiểm tra port:

ss -ltnp | grep 7306

Kiểm tra log:

tail -n 200 /opt/zimbra/log/mysql_error.log

Nếu kết quả vẫn:

mysql is running
mailbox Running

và log không ghi nhận corruption hoặc lỗi database nghiêm trọng thì không nên thực hiện MySQL recovery.

Database recovery là một quy trình riêng và có rủi ro lớn hơn malware cleanup.

---

20. Những việc nên làm sau incident

Sau khi hoàn tất xử lý, nên tiếp tục:

1. Theo dõi CPU và Load Average.
2. Theo dõi /dev/shm.
3. Theo dõi cron user zimbra.
4. Kiểm tra outbound connection.
5. Kiểm tra mail queue.
6. Kiểm tra JSP/webshell.
7. Kiểm tra SSH key.
8. Kiểm tra systemd timer/service.
9. Kiểm tra file mới tạo bởi user zimbra.
10. Rotate credential nếu nghi ngờ bị lộ.
11. Đối chiếu IOC với các Zimbra server khác.
12. Kiểm tra log SMTP tại thời điểm nghi ngờ compromise.
13. Đảm bảo server đang chạy phiên bản Zimbra đã được vá.

---

21. CISA đã ghi nhận khai thác thực tế

CVE-2026-73570 đã được đưa vào danh mục:

Known Exploited Vulnerabilities – KEV

của CISA.

Điều đó có nghĩa đây không chỉ là một lỗ hổng tồn tại trên lý thuyết mà đã có bằng chứng được sử dụng trong các cuộc tấn công thực tế.

Vì vậy, đối với Zimbra server public ra Internet, việc kiểm tra và patch cần được ưu tiên.

Một điểm rất quan trọng:

zmcontrol status

có thể vẫn hiển thị:

mailbox Running
mta Running
proxy Running

trong khi process malware vẫn đang chạy dưới user zimbra.

Do đó không thể chỉ dựa vào việc dịch vụ đang Running để kết luận server an toàn.

---

22. Tóm tắt quy trình

1. Kiểm tra version Zimbra
        ↓
2. Kiểm tra package/config SNMP
        ↓
3. Kiểm tra /dev/shm
        ↓
4. Kiểm tra cron
        ↓
5. Kiểm tra process
        ↓
6. Kiểm tra network
        ↓
7. Thu thập evidence
        ↓
8. Disable SNMP notification tạm thời
        ↓
9. Dừng malicious process
        ↓
10. Loại bỏ persistence
        ↓
11. Quarantine malware
        ↓
12. Hunt JSP/Webshell/SSH persistence
        ↓
13. Upgrade Zimbra >= 10.1.20
        ↓
14. Kiểm tra service + mail queue
        ↓
15. Theo dõi dấu hiệu tái nhiễm

---

Kết luận

CVE-2026-73570 là lỗ hổng nghiêm trọng trong Zimbra Collaboration Suite liên quan đến SNMP notification.

Trong điều kiện vulnerable, attacker từ xa chưa xác thực có thể lợi dụng SMTP request được tạo đặc biệt để thực thi OS command dưới quyền user zimbra.

Các điều kiện cần đặc biệt lưu ý:

Zimbra < 10.1.20
+
zimbra-snmp
+
SNMP notification được bật

Nếu phát hiện server có dấu hiệu compromise, không nên chỉ:

rm malware

rồi kết luận hệ thống đã an toàn.

Quy trình đầy đủ cần bao gồm:

Containment
+
Evidence Collection
+
Process Analysis
+
Persistence Removal
+
Malware Quarantine
+
Patch
+
Verification

Quan trọng nhất vẫn là nâng cấp Zimbra lên phiên bản đã được vá và tiếp tục theo dõi server sau khi xử lý.

---

Nguồn tham khảo

• NIST National Vulnerability Database – CVE-2026-73570
• Zimbra Security Advisories
• Zimbra Collaboration 10.1.20 Release Notes
• CISA Known Exploited Vulnerabilities Catalog
• CERT Polska