CLOUDX SECURITY REPORT  /  PHÂN TÍCH QUỐC TẾ

Sự cố an ninh mạng toàn cầu tháng 10/2026: sự thật về Nhật Bản, dữ liệu theo quốc gia và những bài học cho doanh nghiệp Việt Nam.

Cập nhật: 26/10/2026   •   Biên tập: CloudX Security Insights

Nhật Bản đồng loạt tạm ngừng nhiều dịch vụ trực tuyến trước nguy cơ PHP2Shell, từ cổng thông tin của cơ quan nhà nước đến những tính năng phục vụ người dân. Tuy nhiên, “tạm dừng phòng ngừa” không đồng nghĩa “bị hacker xâm nhập”. Những con số đo lường độc lập cho thấy vấn đề lan khắp thế giới, và ở một số thước đo châu Âu thậm chí đứng cao hơn Nhật. [1][2][3][7][8]

1. PHP2Shell là gì, tại sao được xem là nghiêm trọng?

PHP2Shell là tên gọi chung của hai lỗ hổng trong lõi PHP: CVE-2026-109618 (lỗi xử lý trạng thái khi hết bộ nhớ – OOM) và CVE-2026-109619 (trạng thái con trỏ tồn dư giữa các yêu cầu). Cả hai được đánh giá CVSS v4.0 9,2/10; trong điều kiện phù hợp, kẻ tấn công từ xa có thể thực thi mã mà không cần đăng nhập. Chúng tác động đến nền tảng xử lý PHP, không chỉ một plugin hay một website cụ thể. [1][2]

Điểm đáng lo là ngay cả một ứng dụng PHP viết đúng và được cập nhật cũng có thể chịu rủi ro nếu máy chủ vẫn chạy runtime PHP có lỗ hổng. Khai thác thực tế phụ thuộc phiên bản, kiến trúc triển khai và cấu hình; không có nghĩa mọi website PHP đều bị chiếm quyền tự động. [1][13]

Các mốc quan trọng trong tuần khủng hoảng

2. Nhật Bản thực sự đã xảy ra chuyện gì?

Các cơ quan Nhật Bản công khai triển khai biện pháp hạn chế rủi ro rất nhanh. Ngày 21/10, Bộ Tài chính Nhật thông báo tạm dừng một số nội dung và dịch vụ web dùng PHP để kiểm tra và triển khai cập nhật; đến 22/10, cơ quan này xác nhận khôi phục dần sau khi áp dụng biện pháp an toàn. [3][4]

Cơ quan Tiêu dùng Nhật Bản cho biết có 7 trang chuyên đề được tạm ngừng theo hướng phòng ngừa; tại thời điểm họp báo 22/10, cơ quan này nói chưa phát hiện việc truy cập trái phép vào hệ thống của mình và Trung tâm Quốc gia về các vấn đề tiêu dùng. Cơ quan Nội chính Hoàng gia cũng tạm dừng các biểu mẫu/giao diện đặt lịch tham quan, sau đó thông báo khôi phục trong ngày 22/10. [5][6]

Các bản tin Reuters còn ghi nhận việc kiểm tra khẩn cấp lan tới các ngành ngân hàng, hàng không, đường sắt, bảo hiểm và cơ quan công quyền. Tuy nhiên, dữ liệu công khai không cho phép cộng các lần “ngừng để vá” thành số vụ xâm nhập thành công. [11]

Vì sao cảm giác Nhật Bản chịu ảnh hưởng đặc biệt nặng?

• Tính hiển thị rất cao: khi cổng thông tin công vụ, biểu mẫu đăng ký hay hệ thống phục vụ dân sinh tạm ngừng, người dùng nhận thấy ngay, dù việc dừng có thể là biện pháp bảo vệ.
• Lượng dịch vụ PHP cũ đáng kể: theo Mallory/Shodan, Nhật có 180.514 dịch vụ công khai phiên bản PHP; 142.232 dịch vụ (79%) báo PHP 8.1 trở xuống. Đây là chỉ dấu nợ kỹ thuật và khó nâng cấp, không phải 142.232 website đã bị tấn công. [7]
• Áp lực vận hành và trách nhiệm cao: các đơn vị xử lý thông tin nhạy cảm có thể ưu tiên dừng tạm thời thay vì tiếp tục nhận kết nối trong khi đánh giá khả năng bị khai thác. Đây là cách diễn giải từ các thông báo chính thức, không phải thống kê sự cố thành công. [3][5][6]

3. So sánh quốc gia: nơi nào có nhiều PHP cũ?

Một trong những phép đo đáng tin cậy nhất để so sánh là tỷ trọng dịch vụ PHP công khai phiên bản chạy nhánh 8.1 trở xuống. Mallory tổng hợp 2,6 triệu dịch vụ PHP trong dữ liệu Shodan ngày 21/10; khoảng 73,5% thuộc các nhánh không còn nhận bản phát hành sửa lỗi chính thức từ dự án PHP. Mỗi “dịch vụ” là một tổ hợp IP–cổng, không phải một website hay doanh nghiệp duy nhất. [7]

Biểu đồ 1 — So sánh tỷ lệ sử dụng PHP 8.1 trở xuống. Màu cam nhấn mạnh Nhật Bản. [7]

Đọc đúng: Mỹ có số dịch vụ quan sát được lớn nhất; Nhật xếp sau Mỹ và Trung Quốc trong nhóm số lượng này; tỷ lệ 79% ở Nhật cao nhưng không đứng đầu. Chẳng hạn, Trung Quốc đạt 88%, trong khi khảo sát còn cho biết Hàn Quốc 89% và Italy 90% trên nhóm dịch vụ có khai báo phiên bản. Các hệ thống được nhà phân phối backport bản vá có thể vẫn công bố số hiệu phiên bản cũ; vì vậy “bản cũ” không luôn đồng nghĩa “chưa vá”. [7]

4. So sánh nỗ lực tấn công thực tế theo khu vực và quốc gia

Check Point Research công bố ngày 22/10 rằng khoảng 10% tổ chức trong tập dữ liệu của hãng đã gặp nỗ lực khai thác PHP2Shell kể từ lúc thông tin lộ ra; châu Âu 14%, Bắc Mỹ 6%, Mỹ Latinh 6%, châu Á – Thái Bình Dương 6% và châu Phi 4%. Hãng nhấn mạnh “impact” là bị thử tấn công, không biết hoạt động có thành công hay không. [8]

Biểu đồ 2 — Một phần bảng tỷ lệ tổ chức gặp nỗ lực khai thác theo Check Point (mẫu đo riêng của hãng), không phải tỷ lệ bị chiếm quyền. [8]

Nhóm cao nhất theo Check Point gồm Hungary (38%), Đan Mạch (32%), Áo (28%), Thụy Điển và Romania (22%). Thái Lan đạt 17% và Ấn Độ đạt 14%; hai nước này là những trường hợp ngoài châu Âu trong nhóm 18 quốc gia được hãng nêu có tỷ lệ cao nhất. Check Point không công bố tỷ lệ tương ứng của Nhật Bản hoặc Việt Nam trong bài phân tích này, vì vậy không được tự điền số. [8]

Từ góc nhìn hệ thống WAF, Imperva ghi nhận 482.342 yêu cầu có dấu hiệu tấn công trong 24 giờ đầu, nhắm tới 21.998 website tại 103 quốc gia trong mạng khách hàng của hãng. Website tại Mỹ chiếm 64,5% số website bị nhắm trong mẫu Imperva; thứ tự tiếp theo là Indonesia, Australia, Đức và Brazil. Số lượng yêu cầu, phiên tấn công và website mục tiêu đều không phải số máy đã bị xâm nhập. [9]

Biểu đồ 3 — Ba cấp độ đo lường cần tách biệt khi đưa tin an ninh mạng.

5. Vì sao không thể nói “các nước khác ít ảnh hưởng”?

Mỗi hãng nhìn một phần Internet và sử dụng mẫu số khác nhau. Mallory/Shodan đếm dịch vụ tiết lộ phiên bản; Check Point đếm tỷ lệ tổ chức trong mạng khách hàng hứng nỗ lực khai thác; Imperva nhìn lưu lượng WAF của tập website được bảo vệ. Không thể gộp các chỉ số này thành một “bảng xếp hạng quốc gia bị hack”. [7][8][9]

Ngoài Nhật, Reuters ghi nhận các cơ quan và doanh nghiệp ở châu Âu cũng dừng dịch vụ khi khẩn cấp vá PHP; Phần Lan, Pháp, Hà Lan và những hệ thống công quyền khác có phản ứng phòng ngừa. Tại Mỹ, lượng máy chủ quan sát được và lưu lượng đích trong các mẫu độc lập đều rất lớn. Việc một nước ít xuất hiện trên báo chí không đồng nghĩa ít rủi ro kỹ thuật hoặc ít bị quét. [8][9][11][12]

Vì thiếu dữ liệu công khai chuẩn hóa về nạn nhân bị xâm nhập đã kiểm chứng, bài viết này không công bố “số doanh nghiệp thiệt hại” hay “tổng tổn thất tiền” theo từng nước. Đó là giới hạn cần minh bạch với độc giả.

6. Các doanh nghiệp tại Việt Nam nên ứng phó thế nào?

Đối với doanh nghiệp vận hành website, hosting, VPS, máy chủ Linux hoặc hệ thống nội bộ có PHP, điều quan trọng nhất là kiểm kê chính xác runtime đang phục vụ HTTP và trạng thái bản vá của nhà cung cấp. Đừng chỉ nhìn số hiệu php -v của CLI vì web có thể dùng phiên bản khác (PHP-FPM, mod_php, lsphp, container hoặc PHP nhúng trong thiết bị). [1][2][13]

Checklist vận hành khuyến nghị

• Lập danh sách từng tên miền, vhost, ứng dụng, container, PHP-FPM pool và máy chủ thực thi PHP qua HTTP; không bỏ quên subdomain, trang quản trị, API hay ứng dụng cũ.
• Cập nhật qua kênh cung cấp gói phần mềm chính thống (Ubuntu/Red Hat/Plesk/cPanel/CyberPanel/aaPanel/LiteSpeed hoặc nhà cung cấp cloud), rồi khởi động lại Apache/Nginx/PHP-FPM/LiteSpeed worker theo thiết kế.
• Dùng WAF và giới hạn truy cập quản trị như lớp bảo vệ bổ sung, không thay thế nâng cấp PHP; kiểm tra log HTTP và dấu hiệu tiến trình bất thường kể từ ít nhất 17/10/2026.
• Với PHP 5.x/7.x/8.0/8.1, kiểm tra gói backport của nhà phân phối nếu có và lập kế hoạch chuyển nhánh được hỗ trợ; không chỉ sửa WordPress/plugin rồi cho rằng runtime đã an toàn.
• Sao lưu, thử trên staging, đánh giá tương thích ứng dụng; nếu chưa thể khắc phục an toàn, cân nhắc giới hạn truy cập hoặc dừng phần dịch vụ có rủi ro theo mức độ thiết yếu.

Lưu ý bổ sung ngày 23/10: CVE-2026-115560

PHP công bố cảnh báo thông tin về một nhánh rủi ro riêng trong session upload progress; nó chỉ hình thành dưới kết hợp cấu hình và thay đổi bộ tuần tự hóa session rất đặc thù. Bản vá PHP2Shell ngày 21/10 không tự xử lý vấn đề này. Khuyến nghị tạm thời của dự án PHP: cân nhắc đặt session.upload_progress.enabled=0 cho tới bản sửa tiếp theo, sau khi kiểm tra ứng dụng có cần tính năng đó không. Không đánh đồng CVE bổ sung này với mức ảnh hưởng của hai CVE gốc. [14]

7. Kết luận: một cuộc khủng hoảng vận hành, không phải bảng xếp hạng nạn nhân

Nhật Bản nổi bật bởi quy mô ứng phó có thể nhìn thấy, nhiều hệ thống công vụ và dịch vụ liên quan dân sinh đã chủ động dừng để hạn chế rủi ro. Nhưng xét số lượng dịch vụ PHP cũ và tỷ lệ tổ chức hứng thử khai thác, Nhật không đứng đầu mọi chỉ số; châu Âu đang ghi nhận tỷ lệ gặp nỗ lực tấn công cao hơn mức trung bình châu Á – Thái Bình Dương trong mẫu Check Point. [3][5][7][8]

Bài học PHP2Shell dành cho các tổ chức Việt Nam là cần quản trị vòng đời PHP, cập nhật các thành phần nằm bên dưới website, kiểm tra cấu hình thực tế, duy trì giám sát và sẵn sàng ứng phó gián đoạn. Công bố số liệu đúng ngữ cảnh quan trọng không kém việc vá nhanh.

Nguồn tham khảo và phương pháp đọc số liệu

Bản tin chốt dữ liệu đến 26/10/2026. Thống kê thay đổi nhanh; mọi mốc dưới đây ghi theo ngày công bố/mẫu khảo sát và không phải điều tra toàn bộ Internet.

[1] PHP Foundation — bản phát hành bảo mật và giải thích lỗ hổng (21/10/2026)

https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/

[2] IPA Nhật Bản — cảnh báo PHP2Shell (22/10/2026)

https://www.ipa.go.jp/security/security-alert/2026/alert20261022.html

[3] Bộ Tài chính Nhật Bản — tạm dừng nội dung để xử lý (21/10/2026)

https://www.mof.go.jp/public_relations/ohter/20261021231537.html

[4] Bộ Tài chính Nhật Bản — thông báo khôi phục (22/10/2026)

https://www.mof.go.jp/public_relations/ohter/20261022184327.html

[5] Cơ quan Tiêu dùng Nhật Bản — họp báo, 7 site chuyên đề (22/10/2026)

https://www.caa.go.jp/notice/statement/horii/047903.html

[6] Cơ quan Nội chính Hoàng gia — khôi phục nội dung ngừng (22/10/2026)

https://www.kunaicho.go.jp/info/systemmainte-r081022.html

[7] Mallory — số liệu PHP công khai phiên bản theo quốc gia, Shodan (21/10/2026)

https://mallory.ai/blog/php-rce-rapid-response

[8] Check Point Research — tỷ lệ tổ chức gặp nỗ lực khai thác (22/10/2026)

https://blog.checkpoint.com/ai-security/php2shell-one-in-ten-organizations-impacted-as-europe-bears-the-brunt/

[9] Imperva Threat Research — lưu lượng tấn công 24 giờ đầu (22/10/2026)

https://www.imperva.com/blog/php2shell-early-attack-activity-through-impervas-lens/

[10] Amazon Threat Intelligence — dấu hiệu khai thác từ 17/10 (21/10/2026)

https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/

[11] Reuters — phản ứng tại Nhật và các ngành thiết yếu (23/10/2026)

https://www.reuters.com/business/media-telecom/japan-simulate-cyberattacks-php-flaws-roil-global-internet-2026-10-23/

[12] SecuSeek — khảo sát 18 triệu website và 22.000 tổ chức (22/10/2026)

https://secuseek.com/reports/php2shell/

[13] Bitdefender — điều kiện khai thác, khuyến nghị cập nhật (22/10/2026)

https://www.bitdefender.com/en-us/blog/businessinsights/technical-advisory-php2shell-pre-auth-rce

[14] PHP Project advisory — CVE-2026-115560 (23/10/2026)

https://www.php.net/archive/2026.php#2026-10-23-1

Quốc gia/vùng lãnh thổ

Dịch vụ lộ phiên bản

PHP ≤ 8.1

Tỷ lệ

Mỹ

699.282

494.910

71%

Trung Quốc

196.192

172.422

88%

Nhật Bản

180.514

142.232

79%

Đức

175.443

100.805

57%

Hà Lan

83.275

38.683

46%

Pháp

78.086

53.871

69%

Indonesia

73.735

49.902

68%

Hong Kong

72.081

59.725

83%

Ấn Độ

64.429

45.672

71%

Anh

62.339

43.331

70%

Nhánh PHP

Phiên bản upstream đã sửa 2 CVE

Ghi chú

8.2

8.2.35

Hết hỗ trợ upstream cuối 2026: cần kế hoạch nâng cấp.

8.3

8.3.36

Kiểm tra cả tiến trình PHP đang chạy.

8.4

8.4.27

Áp dụng bản vá và khởi động lại worker.

8.5

8.5.12

Áp dụng bản vá và khởi động lại worker.

≤ 8.1

Không có bản phát hành upstream mới

Ưu tiên nâng cấp; nếu dùng bản vá backport, phải xác minh thông báo nhà cung cấp.