Sanae Takaichi gọi đây là cuộc khủng hoảng PHP khẩn cấp, người dùng thông thường cần phòng bị những gì?

Bài viết này đến từ:Decrypt

Biên dịch｜Odaily（@OdailyChina）；Người dịch｜Moni

Lời tòa soạn: PHP vừa phát hiện hai lỗ hổng bảo mật nghiêm trọng, cả hai đều đạt điểm CVSS v4 là 9.2. Kẻ tấn công có thể thực thi mã độc trên máy chủ bị ảnh hưởng mà không cần đăng nhập, thậm chí chiếm toàn quyền kiểm soát máy chủ. Phần Lan, Pháp, Hà Lan và nhiều quốc gia khác đã áp dụng các biện pháp phòng ngừa như tạm thời đưa website ngừng hoạt động, và PHP chính thức cũng đã khẩn cấp phát hành phiên bản vá. Lỗ hổng lần này liên quan đến nhiều phiên bản PHP cũ, các tổ chức bảo mật cảnh báo rằng sau khi bản vá được công khai, có thể nhanh chóng kích hoạt các cuộc tấn công quy mô lớn.

Tối qua, Thủ tướng Nhật Bản Sanae Takaichi đã đăng trên X "một yêu cầu khẩn cấp cần mọi người ứng phó", cảnh báo về rủi ro liên quan đến PHP.

Bài viết này sẽ tổng hợp nguyên lý lỗ hổng, phạm vi ảnh hưởng và diễn biến sự việc, đồng thời phân tích các biện pháp ứng phó mà người vận hành website và người dùng tiền mã hóa thông thường nên áp dụng, do Odaily biên dịch.

Chỉ cần hai ngày qua bạn có lên mạng, rất có thể bạn đã bắt gặp cơn hoảng loạn mạng này:một lỗ hổng nghiêm trọng đang đe dọa gần như mọi website trên toàn cầu — Phần Lan tuyên bố đóng cửa website chính phủ, Cơ quan An ninh Quốc gia Hoa Kỳ (NSA) khuyến nghị tất cả tổ chức sử dụng PHP đóng website của họ, Hà Lan và Pháp cũng đã áp dụng biện pháp tương tự.

Tuy nhiên, đây không phải là một cuộc chiến tranh mạng, mà là việc PHP bị phát hiện hai lỗ hổng bảo mật lớn.

PHP là phần mềm phía máy chủ chạy nền các website. Bạn có thể hiểu máy chủ là một máy tính lưu trữ nội dung website và tạo ra trang web theo yêu cầu của người dùng. Theo công ty bảo mật WordPress Wordfence, đằng sau mỗi website WordPress đều có một máy chủ chạy PHP.

Nhân tiện, website của chính Wordfence cũng đã bị sập.

Tại sao lỗ hổng PHP lại khiến người ta lo ngại? Trên thực tế, lỗ hổng liên quan cho phép người lạ trực tiếp thực thi lệnh của riêng họ trên máy chủ mà không cần đăng nhập. Ngành bảo mật gọi loại lỗ hổng này là "Thực thi mã từ xa không cần xác thực" (Unauthenticated Remote Code Execution, RCE).

Nói một cách dễ hiểu hơn, đó là "bây giờ, người khác có thể điều khiển máy chủ thay bạn".

Nếu máy chủ lưu trữ thông tin tài khoản, địa chỉ hoặc lịch sử đơn hàng của bạn, thì những dữ liệu này cũng có thể rơi vào tay kẻ tấn công. Nhà cung cấp dịch vụ lưu trữ web GoDaddy cảnh báo rằng các lỗ hổng này có thể bị lợi dụng để đánh cắp dữ liệu, sửa đổi trang web, cho phép kẻ tấn công thực thi mã của riêng họ trên máy chủ bị ảnh hưởng thông qua internet, từ đó dẫn đến dữ liệu bị đánh cắp, thậm chí kiểm soát hoàn toàn máy chủ.

PHP chính thức đã công bố những gì?

Tổ chức phi lợi nhuận PHP Foundation, đơn vị chịu trách nhiệm tài trợ cho việc phát triển ngôn ngữ PHP, đã đưa ra cảnh báo:

Nhóm bảo mật PHP thông báo trước: dự kiến phát hành bản cập nhật bảo mật vào 14:00 UTC thứ Tư ngày 21 tháng 10 năm 2026, bao gồm hai lỗ hổng nghiêm trọng, cả hai đều có điểm CVSS v4 là 9.2. Khuyến nghị người dùng PHP chuẩn bị cập nhật trước. Nếu thông tin chi tiết được công khai trước hoặc có bằng chứng cho thấy lỗ hổng đang bị khai thác chủ động, bản cập nhật có thể được phát hành sớm hơn."

Điểm 9.2 ở đây đến từ Hệ thống Điểm số Lỗ hổng Phổ quát (CVSS), hệ thống này đánh giá mức độ nguy hiểm của lỗ hổng dựa trên các yếu tố như liệu lỗ hổng có thể dễ dàng tiếp cận qua internet hay không, mức độ thiệt hại có thể gây ra, v.v. Thang điểm từ 0 đến 10, từ 9.0 trở lên được phân loại là lỗ hổng nghiêm trọng. Do đó, dù chưa đạt điểm tối đa 10, hai lỗ hổng này đã có mức độ nguy hiểm khá cao.

Thứ Tư, PHP đã phát hành bản vá sớm vài phút, lần lượt là PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35, đồng thời xác nhận lỗ hổng lần này ảnh hưởng đến các môi trường PHP xử lý yêu cầu web như PHP-FPM, Apache mod_php, php-cgi, FrankenPHP và LiteSpeed, trong đó Apache mod_php có rủi ro đặc biệt nổi bật, cuộc tấn công có thể được kích hoạt trước khi mã ứng dụng chạy.

Tuy nhiên, thông báo bảo mật chính thức nhấn mạnh không úp mở: "Khuyến nghị mạnh mẽ tất cả người dùng PHP cập nhật ngay lập tức."

Nhưng việc phát hành bản vá không có nghĩa là tất cả người dùng đã hoàn tất việc vá, do đó vẫn cần giữ cảnh giác.

Các lỗ hổng này hoạt động như thế nào?

Lỗ hổng đầu tiên CVE-2026-109618 xuất hiện khi PHP xử lý yêu cầu trong tình trạng cạn kiệt bộ nhớ. Sau đó, PHP có thể xử lý dữ liệu chưa được xây dựng đầy đủ như thể dữ liệu đã hoàn chỉnh.

Lỗ hổng thứ hai CVE-2026-109619 khiến dữ liệu còn sót lại từ yêu cầu của một khách truy cập vẫn tồn tại trong bộ nhớ sau khi lẽ ra đã bị xóa, khiến các yêu cầu tiếp theo có thể bị ảnh hưởng bởi dữ liệu sót lại này.

Bạn có thể hình dung tình huống này như một đầu bếp luôn đọc phiếu gọi món đã bị ném vào thùng rác, nhưng nếu ai đó nhét một phiếu gọi món giả vào thùng rác, đầu bếp sẽ nấu món theo nội dung trên đó. Trong lỗ hổng lần này, "phiếu gọi món" chính là mã độc của kẻ tấn công, và máy chủ sẽ thực thi những mã này.

PHP cho biết các máy chủ sử dụng cách cấu hình Apache phổ biến mod_php có rủi ro cao nhất. Với cấu hình này, cuộc tấn công đã được trình diễn thậm chí có thể thực thi "trước khi bất kỳ mã ứng dụng nào chạy".

Nói cách khác, cơ chế phòng thủ của chính website, chẳng hạn như trang đăng nhập và plugin bảo mật WordPress, thậm chí chưa kịp khởi động.

Các nhà nghiên cứu của PHP Foundation chỉ ra rằng tính năng theo dõi tiến trình tải lên của PHP là một trong những điểm xâm nhập đã được xác nhận. Tính năng này dùng để theo dõi tiến trình tải tệp lên, được bật mặc định hơn mười năm nay, nhưng thực tế rất ít website thực sự sử dụng nó.

Thông tin lỗ hổng bị rò rỉ, các cuộc tấn công xuất hiện sau đó

Thông tin liên quan đến các lỗ hổng này lẽ ra không nên được công khai sớm như vậy. Trên thực tế, vào thứ Ba tuần này, đã có người đăng bài trên diễn đàn Hacker News cho biết hai lỗ hổng PHP dự kiến được công bố vào thứ Năm cùng tuần, đồng thời thừa nhận mình "không có bằng chứng nào ngoài 'nguồn tin: tin tôi đi, anh bạn'".

Thực tế đã chứng minh, người dùng mạng này đã nói đúng.

Công ty bảo mật watchTowr xác nhận rằng hai lỗ hổng này thực sự tồn tại, và vào thời điểm đó vẫn đang trong thời gian cấm công bố (embargo), tức là trước khi giải pháp vá được chuẩn bị sẵn sàng, các bên đã thỏa thuận tạm thời không công khai chi tiết lỗ hổng. Sau đó, PHP đã đẩy thời gian phát hành bản cập nhật lên sớm hơn một ngày.

Giám đốc công nghệ của Cloudflare, Dane Knecht, đã đăng trên nền tảng X vào rạng sáng thứ Tư: "Chúng tôi đã quan sát thấy các cuộc tấn công sớm bắt đầu xuất hiện, và đang liên tục cập nhật các biện pháp giảm thiểu khi các con đường tấn công mới xuất hiện."

Vào thời điểm thông báo này được đăng, còn gần sáu giờ nữa mới đến thời điểm bản vá chính thức được phát hành.

Cloudflare ngay lập tức đẩy quy tắc tường lửa khẩn cấp đến tất cả khách hàng, chặn các mẫu tấn công đã biết thông qua bộ lọc. Tuy nhiên, Dane Knecht nhấn mạnh rằng các biện pháp này "chỉ có thể được coi là biện pháp ứng phó tạm thời".

Các chính phủ khẩn cấp nhấn nút đóng cửa

Theo đài phát thanh công cộng Phần Lan Yle, Trung tâm CNTT quốc gia Phần Lan Valtori đã bắt đầu đưa các dịch vụ mạng công cộng ngừng hoạt động vì mục đích phòng ngừa. Cơ quan an ninh mạng quốc gia Hà Lan cũng đã đóng cửa website của mình.

Về phía Pháp, Bộ Nội vụ cho biết trước khi bên phát hành khuôn khổ liên quan phát hành bản vá bảo mật, website của chính quyền các tỉnh đã "tạm thời ngừng hoạt động".

Nhóm ứng phó khẩn cấp mạng của EU CERT-EU khuyến nghị rằng đối với các tổ chức tạm thời chưa thể cài đặt bản vá, nên "xem xét cách ly các ứng dụng hướng internet khỏi mạng công cộng cho đến khi có giải pháp khắc phục".

Sau đó, các cơ quan liên quan của Úc, Nhật Bản và Vương quốc Anh cũng đưa ra khuyến nghị tương tự.

Nói một cách dễ hiểu, đó là "rút dây mạng".

Một số bài đăng phổ biến trên nền tảng X tuyên bố rằng PHP "tất cả các phiên bản từ năm 2004" đều có lỗ hổng.

Tuyên bố này bắt nguồn từ ước tính ban đầu rằng tất cả các phiên bản từ PHP 5 trở đi đều bị ảnh hưởng. Nhưng CERT-EU thừa nhận rằng ước tính này dựa trên các bài đăng trên mạng xã hội.

Công ty bảo mật thương mại điện tử Sansec cho rằng phạm vi phiên bản bị ảnh hưởng bắt đầu từ PHP 5.4, bao gồm các phiên bản sau đó. Điều này có nghĩa là phạm vi ảnh hưởng của lỗ hổng có thể truy ngược về sớm nhất là năm 2012, chứ không phải năm 2004. Tuy nhiên, điều này vẫn liên quan đến các phiên bản phần mềm khá cũ.

PHP ch