Ngày 26/08/2026, Internet Việt Nam đi quốc tế đang chịu ảnh hưởng khi hai tuyến cáp quang biển SJC2 và AAE-1 đồng thời gặp sự cố. Các nhà mạng đang thực hiện định tuyến lại lưu lượng qua những tuyến kết nối khác để duy trì dịch vụ, tuy nhiên người dùng có thể nhận thấy tốc độ truy cập quốc tế giảm hoặc độ trễ tăng cao.
SJC2 và AAE-1 gặp sự cố cùng lúc
Theo thông tin từ các đơn vị quản lý và nhà cung cấp dịch vụ mạng, tuyến SJC2 gặp sự cố tại phân đoạn S4 – Chung Hom Kok, Hồng Kông. Trong khi đó, tuyến AAE-1 mất kết nối do sự cố tại phân đoạn S1.H2, gần khu vực bờ biển phía Nam Thái Lan.
Hiện nguyên nhân cụ thể của các sự cố chưa được công bố và chưa có thời gian dự kiến khắc phục (ETA) chính thức.
Việc hai tuyến cáp quan trọng gặp lỗi cùng thời điểm khiến tổng dung lượng kết nối quốc tế của các nhà mạng Việt Nam bị giảm đáng kể. Một số nguồn thông tin ước tính sự cố đồng thời trên SJC2 và AAE-1 có thể ảnh hưởng khoảng 30% lưu lượng Internet quốc tế của Việt Nam.
Người dùng Internet có thể bị ảnh hưởng như thế nào?
Sự cố không đồng nghĩa với việc Internet tại Việt Nam bị mất hoàn toàn.
Các ISP đang reroute – định tuyến lại lưu lượng qua những tuyến cáp và đường truyền quốc tế còn hoạt động. Nhờ đó, các dịch vụ Internet trong nước vẫn có thể sử dụng bình thường.
Tuy nhiên, khi một phần dung lượng quốc tế bị mất, người dùng có thể gặp:
Truy cập website và dịch vụ quốc tế chậm hơn bình thường.
Độ trễ (latency/ping) tăng.
Kết nối VPN quốc tế không ổn định.
Tốc độ tải xuống/tải lên từ máy chủ nước ngoài giảm.
Một số dịch vụ có thể phản hồi chậm hoặc mất kết nối trong từng thời điểm.
Mức độ ảnh hưởng còn phụ thuộc vào nhà mạng, tuyến định tuyến và vị trí máy chủ mà người dùng đang truy cập.
Doanh nghiệp và hệ thống IT có thể cảm nhận rõ hơn
Đối với doanh nghiệp sử dụng nhiều dịch vụ đặt máy chủ ở nước ngoài, sự cố có thể dễ nhận thấy hơn so với người dùng thông thường.
Các dịch vụ như Microsoft 365, Azure, AWS, Google Cloud, GitHub, Cloudflare hoặc các hệ thống VPN kết nối quốc tế có thể xuất hiện tình trạng latency cao hoặc tốc độ không ổn định nếu lưu lượng phải đi qua các tuyến thay thế.
Vì vậy, nếu hệ thống mạng doanh nghiệp xuất hiện hiện tượng truy cập quốc tế chậm trong thời gian này, không nên vội kết luận rằng nguyên nhân nằm ở firewall, DNS, Wi-Fi hoặc máy chủ nội bộ. Cần kiểm tra thêm đường đi quốc tế và latency tới từng điểm đích.
Việt Nam vẫn còn các tuyến kết nối dự phòng
Việc Internet Việt Nam vẫn duy trì được kết nối dù hai tuyến cáp cùng gặp sự cố cho thấy vai trò quan trọng của hệ thống định tuyến dự phòng.
Các nhà mạng có thể chuyển một phần lưu lượng sang những tuyến cáp biển khác cũng như các tuyến kết nối đất liền. Nhờ đó, người dùng vẫn có thể truy cập Internet, dù chất lượng tới một số hướng quốc tế có thể suy giảm.
Đây cũng là lý do việc phát triển thêm các tuyến cáp biển và đa dạng hóa hướng kết nối quốc tế ngày càng quan trọng đối với hạ tầng Internet Việt Nam.
Khi nào Internet quốc tế sẽ trở lại bình thường?
Tại thời điểm hiện tại, chưa có ETA chính thức cho việc khắc phục SJC2 và AAE-1. Thời gian sửa chữa còn phụ thuộc vào việc xác định nguyên nhân, điều kiện triển khai tàu sửa chữa và các yếu tố kỹ thuật tại vị trí xảy ra sự cố.
Trong thời gian chờ khắc phục, các ISP sẽ tiếp tục điều chỉnh định tuyến để tối ưu lưu lượng trên những tuyến còn khả dụng.
Hai tuyến SJC2 và AAE-1 cùng gặp sự cố đang tạo thêm áp lực lên hạ tầng kết nối Internet quốc tế của Việt Nam. Internet trong nước vẫn hoạt động nhờ các tuyến dự phòng và phương án reroute, nhưng người dùng có thể gặp tốc độ quốc tế chậm hơn, ping cao và kết nối không ổn định.
Nếu hôm nay bạn nhận thấy website nước ngoài, VPN hoặc các dịch vụ cloud quốc tế chậm bất thường, rất có thể đây là một trong những nguyên nhân cần được xem xét.
Thông tin được tổng hợp từ các báo cáo ngày 25–26/08/2026 và có thể được cập nhật khi các đơn vị vận hành công bố thêm thông tin về nguyên nhân và tiến độ khắc phục.
CVE-2026-73570 là một lỗ hổng OS Command Injection dẫn đến Remote Code Execution (RCE) trong thành phần SNMP monitoring của Zimbra Collaboration Suite (ZCS). Lỗ hổng ảnh hưởng đến các hệ thống sử dụng phiên bản Zimbra trước 10.1.20, trong trường hợp package zimbra-snmp được cài đặt và tính năng SNMP notifications được bật.
Điểm đáng chú ý là lỗ hổng không yêu cầu xác thực. Kẻ tấn công từ xa có thể gửi các SMTP request được chế tạo đặc biệt để kích hoạt việc thực thi lệnh hệ điều hành với quyền của tài khoản zimbra.
Theo NVD, CVE-2026-73570 có mức độ nghiêm trọng High, CVSS 3.1 là 8.9/10. Đặc biệt, CVE này đã được đưa vào CISA Known Exploited Vulnerabilities (KEV) với trạng thái khai thác đang hoạt động. Vì vậy, các máy chủ Zimbra công khai Internet cần được ưu tiên kiểm tra và cập nhật.
CVE-2026-73570 là gì?
Lỗ hổng nằm trong thành phần SNMP monitoring của Zimbra.
Trong điều kiện bị ảnh hưởng, dữ liệu không tin cậy được gửi thông qua SMTP có thể đi vào quá trình xử lý SNMP notification mà không được lọc/sanitization đầy đủ. Điều này tạo điều kiện cho kẻ tấn công chèn lệnh hệ điều hành.
Luồng tấn công có thể được mô tả đơn giản như sau:
Internet
│
▼
Kẻ tấn công
│
│ SMTP request đặc biệt
▼
Zimbra Mail Server
│
▼
SNMP Notification
│
▼
Command Injection
│
▼
Thực thi lệnh hệ điều hành
│
▼
Quyền user "zimbra"
Điều đáng lo ngại là attacker không cần tài khoản Zimbra hoặc xác thực trước để thực hiện bước khai thác ban đầu.
Những hệ thống nào bị ảnh hưởng?
Theo thông tin từ Zimbra và NVD, hệ thống có nguy cơ khi đáp ứng các điều kiện chính:
Sử dụng Zimbra Collaboration phiên bản trước 10.1.20.
Package zimbra-snmp được cài đặt.
SNMP notifications được bật.
Zimbra đã phát hành bản sửa lỗi cho CVE-2026-73570 trong Zimbra Collaboration 10.1.20.
Điều này có nghĩa là không phải mọi máy chủ Zimbra đều mặc nhiên bị khai thác. Tuy nhiên, nếu máy chủ đang sử dụng phiên bản cũ, có zimbra-snmp và SNMP notifications được bật thì cần được xem xét là hệ thống có nguy cơ.
Tại sao lỗ hổng này nguy hiểm?
Mức độ nguy hiểm không chỉ nằm ở việc attacker có thể gửi một request SMTP.
Sau khi khai thác thành công, attacker có thể thực thi lệnh với quyền của user zimbra. Tùy vào cấu hình và các lỗ hổng khác trên hệ thống, kẻ tấn công có thể tiếp tục:
Tải và chạy malware.
Tạo persistence để duy trì quyền truy cập.
Tạo cron job độc hại.
Triển khai webshell.
Đọc các file cấu hình của Zimbra.
Thu thập thông tin kết nối LDAP, database hoặc secret.
Đánh cắp thông tin xác thực.
Gửi email spam hoặc email lừa đảo từ máy chủ.
Sử dụng máy chủ làm điểm trung gian để tấn công các hệ thống khác.
Tiếp tục mở rộng quyền nếu tìm thấy thêm điểm yếu trên máy chủ.
Do đó, việc xử lý CVE-2026-73570 không nên dừng ở việc “update package”. Nếu máy chủ đã tồn tại trong trạng thái dễ bị tấn công trong một khoảng thời gian dài, quản trị viên cũng nên kiểm tra xem hệ thống có dấu hiệu compromise hay không.
Kiểm tra phiên bản Zimbra
Trước tiên, đăng nhập vào máy chủ Zimbra bằng quyền root và kiểm tra phiên bản:
su - zimbra -c 'zmcontrol -v'
Ví dụ:
Release 10.1.19
Nếu đang sử dụng phiên bản 10.1.19 hoặc thấp hơn, cần kiểm tra tiếp các điều kiện ảnh hưởng.
Bản sửa lỗi chính thức cho CVE-2026-73570 nằm trong Zimbra 10.1.20.
Kiểm tra package zimbra-snmp
Trên hệ thống sử dụng Debian/Ubuntu:
dpkg -l | grep -E 'zimbra-snmp|zimbra-net-snmp'
Trên hệ thống sử dụng RHEL/CentOS/Rocky hoặc các hệ thống RPM:
rpm -qa | grep -E 'zimbra-snmp|zimbra-net-snmp'
Nếu xuất hiện package liên quan đến zimbra-snmp, cần kiểm tra tiếp trạng thái SNMP.
Trong trường hợp hệ thống không sử dụng SNMP monitoring, quản trị viên có thể cân nhắc vô hiệu hóa thành phần này như một biện pháp giảm thiểu tạm thời trong khi chuẩn bị cập nhật.
Tuy nhiên, disable SNMP không nên được xem là giải pháp thay thế cho việc cập nhật Zimbra.
Kiểm tra dấu hiệu máy chủ đã bị xâm nhập
Đây là bước rất quan trọng.
Do CVE-2026-73570 đã được đưa vào CISA KEV và được đánh giá có khai thác đang hoạt động, nếu máy chủ từng chạy phiên bản dễ bị tấn công và public Internet thì không nên mặc định rằng hệ thống “chưa bị hack”.
Có thể bắt đầu kiểm tra các tiến trình bất thường:
ps auxf
Kiểm tra kết nối mạng:
ss -tunap
Kiểm tra thư mục /dev/shm, nơi malware đôi khi có thể sử dụng để lưu payload:
Webshell hoặc JSP file không nằm trong bộ cài đặt Zimbra.
File mới xuất hiện trong thư mục web của Zimbra.
CPU/RAM tăng bất thường.
Mail queue tăng mạnh.
Máy chủ gửi email ra ngoài bất thường.
Tài khoản hoặc credential có dấu hiệu bị sử dụng trái phép.
Không nên chỉ xóa các file đáng ngờ ngay lập tức nếu nghi ngờ compromise. Trong môi trường doanh nghiệp, nên lưu lại log, process list, network connection và các file liên quan trước khi tiến hành cleanup để phục vụ điều tra.
Cách xử lý khuyến nghị
Bước 1: Backup
Trước khi nâng cấp Zimbra, cần đảm bảo có backup hoạt động và có khả năng restore.
Đặc biệt cần lưu ý backup phải có:
Mailbox.
Database/configuration.
LDAP.
Các file cấu hình quan trọng.
SSL certificate/key.
Cấu hình DNS và mail gateway nếu có.
Bước 2: Nếu cần, tạm thời vô hiệu hóa SNMP
Nếu hệ thống không cần SNMP, có thể tạm thời disable service trong quá trình xử lý:
su - zimbra -c 'zmprov ms $(zmhostname) -zimbraServiceEnabled snmp'
Đây chỉ là biện pháp giảm thiểu. Giải pháp lâu dài vẫn là nâng cấp lên phiên bản đã được vá.
Bước 3: Nâng cấp Zimbra lên phiên bản đã sửa lỗi
Zimbra xác nhận CVE-2026-73570 đã được xử lý trong:
Zimbra Collaboration 10.1.20
Trang Security Advisories chính thức của Zimbra liệt kê CVE-2026-73570 là lỗi command injection trong thành phần SNMP monitoring khi SNMP notifications được bật và ghi nhận 10.1.20 là bản sửa lỗi.
Quản trị viên nên thực hiện upgrade theo đúng hướng dẫn của phiên bản Zimbra đang sử dụng, thay vì tự ý thay thế riêng từng binary hoặc package.
Zimbra cũng khuyến nghị sử dụng các phiên bản còn được hỗ trợ; các phiên bản cũ không còn được hỗ trợ có thể tiếp tục tồn tại các lỗ hổng bảo mật và nên được nâng cấp.
Nếu không sử dụng SNMP, nên cân nhắc giữ service ở trạng thái disabled.
Nếu phát hiện máy chủ đã bị compromise thì sao?
Nếu phát hiện malware, webshell, cron bất thường hoặc hoạt động mạng đáng ngờ, không nên chỉ update Zimbra rồi coi như đã xử lý xong.
Quy trình nên là:
Phát hiện dấu hiệu compromise
│
▼
Containment
│
▼
Thu thập log / evidence
│
▼
Điều tra phạm vi xâm nhập
│
▼
Xác định persistence / malware
│
▼
Patch Zimbra
│
▼
Rotate credentials / secrets
│
▼
Kiểm tra toàn bộ hệ thống
│
▼
Khôi phục dịch vụ an toàn
Đặc biệt cần xem xét thay đổi các credential có khả năng đã bị lộ, chẳng hạn:
Tài khoản quản trị Zimbra.
LDAP credentials.
Database credentials.
API credentials.
SMTP relay credentials.
SSH credentials.
Các secret/key được lưu trên máy chủ.
Nếu mức độ compromise nghiêm trọng, phương án an toàn hơn có thể là rebuild server từ nguồn tin cậy và restore dữ liệu sau khi đã xác minh, thay vì chỉ xóa malware trên hệ thống hiện tại.
Có cần lo nếu chỉ mở SMTP port 25?
Có.
CVE-2026-73570 đặc biệt đáng chú ý đối với máy chủ Zimbra cung cấp dịch vụ email trực tiếp ra Internet vì quá trình khai thác bắt đầu từ các SMTP request được chế tạo đặc biệt. NVD mô tả attacker không cần xác thực và có thể dẫn đến thực thi lệnh hệ điều hành với quyền zimbra.
Do đó, việc firewall chỉ mở port 25 không đồng nghĩa máy chủ an toàn trước lỗ hổng này.
Ngược lại, nếu Zimbra nằm sau mail gateway hoặc một lớp bảo vệ SMTP, rủi ro có thể giảm tùy cấu hình, nhưng không nên xem đây là biện pháp thay thế cho việc patch.
Kết luận
CVE-2026-73570 là một lỗ hổng nghiêm trọng trên Zimbra liên quan đến SNMP command injection và có khả năng dẫn đến Remote Code Execution.
Các điểm cần nhớ:
Ảnh hưởng đến Zimbra trước 10.1.20 khi zimbra-snmp được cài đặt và SNMP notifications được bật.
Có thể bị khai thác không cần xác thực thông qua SMTP.
Lệnh được thực thi dưới quyền user zimbra.
CVSS 3.1 được MITRE ghi nhận là 8.9 – High.
CVE đã được đưa vào CISA Known Exploited Vulnerabilities (KEV).
Zimbra đã phát hành bản sửa lỗi trong 10.1.20.
Khuyến nghị: Nếu đang vận hành Zimbra public Internet, hãy kiểm tra ngay phiên bản bằng zmcontrol -v, xác định trạng thái zimbra-snmp, sau đó lên kế hoạch nâng cấp lên Zimbra 10.1.20 hoặc cao hơn. Nếu máy chủ đã chạy phiên bản dễ bị tấn công trong thời gian dài, cần thực hiện thêm bước kiểm tra compromise trước khi kết luận hệ thống an toàn.
Dù bạn đã vệ sinh mặt kính scan của máy in nhưng khi bạn thao tác scan văn bản trên máy in Brother 2700DW vẫn bị sọc dọc như ảnh trên thì có thể gương nhỏ có thể hư rồi.
Dưới đây là một số ứng dụng không thể thiếu khi sang Trung Quốc:
1. WeChat (微信) * Ứng dụng nhắn tin, gọi điện, thanh toán, quan trọng số 1.
2. Alipay (支付宝) * Ví điện tử thanh toán , đi tàu, thanh toán khi mua taobao gửi trực tiếp về VN * Hầu như mọi khoản chi tiêu đều có thể thực hiện qua Alipay.
3. Meituan (美团) Đặt hàng , đồ ăn ship nhanh, quét xe công cộng
4. China Unicom (中国联通) * Ứng dụng quản lý SIM và gói cước. Không có thì không có mạng :)))
5. 12306 Railway (铁路12306) * Ứng dụng chính thức đặt vé tàu cao tốc Trung Quốc. * Tra cứu lịch tàu, đặt vé, đổi hoặc hoàn vé.
6. Baidu Maps (百度地图) Google map
Thêm nữa:
– shadowClash: Sang bên đó dùng mạng và vẫn muốn coi tiktok các thứ nên nhất định phải có.
Trong giai đoạn vừa sinh và ở cữ, mỗi ngày 8 -12 lần.
– Từ ngày 1 đến ngày 3: Sau khi sinh, dạ dày bé bằng quả anh đào, mỗi cữ uống tầm 15-30ml sữa
– Từ ngày 3 đến ngày 11: Dạ dày bé bằng quả dâu tây, mỗi cữ uống tầm 30-60ml sữa
– Từ ngày 10 đến ngày 20: Dạ dày bé bằng quả trứng, mỗi cữ uống tầm 60-90ml sữa
– Từ ngày 20 đến ngày 30: Dạ dày bé bằng quả chanh, mỗi cữ uống tầm 90-120ml sữa
Lưu ý:
– Không phải bé khóc là cho con bú
– Lượng bú của bé 3kg và 4kg khác nhau (Ví dụ: Từ 90ml đến 120ml thì bé 3kg là 90ml, bé 4kg là 120ml)
– Tăng lượng sữa từ từ, từ 10-15ml để dạ dày bé kịp thích nghi
Để hạn chế sặc sữa ở trẻ vừa sinh, các bạn nên:
– Nên cho con bú nghiêng (Đầu bé nghiêng qua 1 bên, hoặc nghiêng vào trong người ), không cho con bú ngửa vì dễ bị sặc sữa, dễ bị tạo đờm ở cổ. Khi hết gần hết sữa thì để bình dốc thẳng
– Miệng bé ôm hết bình bú, van thoát khí hướng lên trên và núm vú luôn đầy sữa
– Núm ti phù hợp với em bé sơ sinh (Vì núm ti chảy nhanh quá thì em bé dễ bị sặc sữa)
– Lấy ngón tay gõ vào đít bình để bé bú liền, không ngủ quên và không ngừng bú
– Nếu bé bú bình nhưng bọt trong bình ra nhiều. Này là bọt từ van thoát khí đang đối lưu khí vào (Không có sữa chặn thì không có bọt, còn sữa chặn thì lên bọt, hiện trạng này là bình thường)
– Bé bị thắng lưỡi nhẹ thì chọn bình cổ hẹp sẽ đỡ bị trật khớp và hạn chế tràn khi bú.
Cách cho bú:
Bước 1: Bế bé nằm ở tư thế dốc
Bế bé đầu cao hơn thân, thả lỏng ngồi thoải mái ôm
Bước 2: Để khăn sữa dưới cằm bé và từ từ nghiêng đầu bé sang 1 bên
Bước 3: Cầm bình sữa lên (Chú ý và van thoát khí phải nằm ở phía trên, núm ti ở môi dưới của bé, khi bé há miệng to ra thì mình đút cái núm ti vào, để bình sữa hơi dốc để sữa luôn luôn đầy ở phần núm ti, sẽ hạn chế khí vào người bé gây đầy hơi)
