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.
AWS Local Zone Hà Nội chính thức đi vào hoạt động với mã định danh ap-southeast-1-han-1a, mang đến khả năng triển khai workload độ trễ thấp ngay tại Việt Nam. Đây được xem là một bước tiến quan trọng giúp doanh nghiệp tối ưu hiệu năng ứng dụng, đáp ứng yêu cầu lưu trữ dữ liệu và thúc đẩy chiến lược chuyển đổi số trên nền tảng điện toán đám mây AWS.
AWS Local Zone Hà Nội Là Gì?
Amazon Web Services (AWS) vừa công bố trạng thái General Availability (GA) cho AWS Local Zone tại Hà Nội. Đây là Local Zone đầu tiên của AWS được triển khai tại Việt Nam, cho phép doanh nghiệp đưa tài nguyên điện toán đến gần người dùng cuối hơn mà vẫn duy trì mô hình vận hành và quản trị thống nhất với AWS.
AWS Local Zone hoạt động như một phần mở rộng của AWS Region Singapore (ap-southeast-1), giúp các ứng dụng yêu cầu độ trễ thấp có thể xử lý dữ liệu ngay tại Việt Nam thay vì phải truyền tải toàn bộ về Singapore như trước đây.
Những Dịch Vụ Được Hỗ Trợ Tại AWS Local Zone Hà Nội
Khác với nhiều mô hình Edge Computing chỉ cung cấp tài nguyên tính toán cơ bản, AWS Local Zone Hà Nội hỗ trợ đồng thời nhiều thành phần hạ tầng quan trọng bao gồm:
Compute
Amazon EC2
Auto Scaling
Elastic Load Balancing
Storage
Amazon EBS (Block Storage)
Amazon S3 (Object Storage)
Container
Amazon ECS
Amazon EKS
Networking
VPC
Direct Connect
Elastic IP
Security Group
Điều này cho phép doanh nghiệp triển khai hoàn chỉnh các hệ thống ứng dụng ngay tại Local Zone mà không cần phụ thuộc hoàn toàn vào Region chính.
Lợi Ích Khi Sử Dụng AWS Local Zone Tại Việt Nam
Giảm Độ Trễ Truy Cập
Đối với các ứng dụng yêu cầu phản hồi theo thời gian thực, việc triển khai workload tại Hà Nội giúp giảm đáng kể độ trễ so với việc xử lý hoàn toàn tại Singapore.
Các lĩnh vực hưởng lợi bao gồm:
Trò chơi trực tuyến (Gaming)
Livestream
Video Processing
AI Inference
Thương mại điện tử
Fintech
Hệ thống giao dịch thời gian thực
Hỗ Trợ Data Residency
Nhiều doanh nghiệp hiện nay có nhu cầu lưu trữ và xử lý dữ liệu gần với khu vực hoạt động để đáp ứng các yêu cầu về tuân thủ và quản trị dữ liệu.
AWS Local Zone Hà Nội giúp doanh nghiệp xây dựng các mô hình lưu trữ dữ liệu linh hoạt hơn trong khi vẫn tận dụng được hệ sinh thái dịch vụ toàn cầu của AWS.
Đơn Giản Hóa Mô Hình Hybrid Cloud
Thay vì đầu tư và vận hành toàn bộ hệ thống máy chủ tại Data Center riêng, doanh nghiệp có thể kết hợp:
Hạ tầng On-Premises
Private Cloud
AWS Region Singapore
AWS Local Zone Hà Nội
Mô hình Hybrid Cloud này giúp tối ưu chi phí đầu tư, tăng khả năng mở rộng và giảm áp lực vận hành.
AWS Local Zone Hà Nội Mang Ý Nghĩa Gì Với Doanh Nghiệp Việt Nam?
Sự xuất hiện của AWS Local Zone tại Hà Nội cho thấy thị trường điện toán đám mây Việt Nam đang ngày càng được các nhà cung cấp hạ tầng lớn quan tâm.
Đối với doanh nghiệp trong nước, đây là cơ hội để:
Tăng hiệu năng ứng dụng
Nâng cao trải nghiệm người dùng
Tối ưu chi phí hạ tầng CNTT
Đẩy nhanh quá trình chuyển đổi số
Triển khai các nền tảng AI và dữ liệu lớn hiệu quả hơn
Đặc biệt, các doanh nghiệp công nghệ, startup SaaS, ngân hàng, fintech, thương mại điện tử và truyền thông số sẽ là những nhóm được hưởng lợi rõ rệt từ hạ tầng mới này.
Việc AWS chính thức đưa AWS Local Zone Hà Nội (ap-southeast-1-han-1a) vào hoạt động đánh dấu một cột mốc quan trọng đối với hệ sinh thái cloud tại Việt Nam. Không chỉ giúp giảm độ trễ và cải thiện hiệu năng ứng dụng, Local Zone còn mở ra nhiều cơ hội mới cho doanh nghiệp trong việc xây dựng kiến trúc Hybrid Cloud, AI, dữ liệu lớn và các dịch vụ số hiện đại.
Trong bối cảnh nhu cầu chuyển đổi số ngày càng tăng, AWS Local Zone Hà Nội được kỳ vọng sẽ trở thành nền tảng hạ tầng quan trọng giúp doanh nghiệp Việt Nam tiếp cận các công nghệ cloud tiên tiến với hiệu quả cao hơn.
