PHP2Shell: bốn bản PHP đã vá và ưu tiên xử lý tại Việt Nam

Ngày 21/10/2026, dự án PHP công bố trong thông báo bảo mật bốn phiên bản sửa CVE-2026-109618 và CVE-2026-109619: PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35. Hai lỗ hổng có thể cho phép thực thi mã từ xa trên máy chủ mà không cần đăng nhập. Bản vá đã có sẵn; đơn vị vận hành website cần xác định phiên bản PHP đang phục vụ yêu cầu web và cập nhật theo nhánh tương ứng.

Tại Việt Nam, Cục An ninh mạng và Hiệp hội An ninh mạng quốc gia thông tin về hai lỗ hổng ngày 22/10. Trong thông tin đăng trên VOV, hai đơn vị nhấn mạnh việc “rà soát có hệ thống, vá lỗi đúng thứ tự ưu tiên và giám sát liên tục”. Khuyến cáo hướng tới tổ chức vận hành website dùng PHP; lỗ hổng nằm ở phía máy chủ, không trực tiếp tác động đến thiết bị hay trình duyệt của người truy cập thông thường.

Bốn mốc phiên bản áp dụng cho hệ thống nào?

Phạm vi cần kiểm tra là PHP xử lý yêu cầu web, bao gồm PHP-FPM, Apache với mod_php, php-cgi, FrankenPHP và LiteSpeed. PHP đánh giá rủi ro cao nhất ở mod_php vì đã có cách khai thác được chứng minh: yêu cầu không cần xác thực có thể kích hoạt lỗi trước khi mã ứng dụng chạy. Do đó, lớp đăng nhập do website tự xây dựng không đủ để loại một máy chủ dùng PHP chưa vá khỏi diện rà soát.

Đối với bản phát hành trực tiếp từ dự án PHP, đối chiếu phiên bản đang chạy với các mốc sau. Mỗi mốc sửa cả hai lỗ hổng trong nhánh tương ứng:

PHP 8.5: các bản trước 8.5.12 cần chuyển lên 8.5.12 hoặc bản mới hơn trong cùng nhánh.
PHP 8.4: các bản trước 8.4.27 cần chuyển lên ít nhất 8.4.27.
PHP 8.3: các bản trước 8.3.36 cần chuyển lên ít nhất 8.3.36.
PHP 8.2: các bản trước 8.2.35 cần chuyển lên ít nhất 8.2.35; đơn vị sử dụng nhánh này cũng cần tính đến việc nó sắp hết thời gian hỗ trợ.

Mốc trên không thể áp máy móc cho mọi gói do nhà phân phối hệ điều hành duy trì. Nhà cung cấp có thể đưa bản sửa lỗi vào gói cũ mà giữ nguyên số phiên bản PHP hiển thị; khi đó phải đối chiếu thông báo và số hiệu gói của chính nhà cung cấp. Với PHP 8.1 trở về trước, dự án PHP không phát hành bản cập nhật thông thường, dù đã cung cấp mã nguồn sửa lỗi tối thiểu cho các nhánh 7.4, 8.0 và 8.1. Hệ thống dùng nhánh cũ cần xác nhận gói vá từ nhà cung cấp hoặc chuyển sang nhánh còn được hỗ trợ.

Ưu tiên theo mức phơi lộ và cách vận hành

Trong danh sách máy chủ chưa vá, website công khai chạy mod_php là nhóm nên xử lý trước vì vừa nhận yêu cầu từ Internet vừa thuộc mô hình có rủi ro khai thác cao nhất mà PHP nêu. Tiếp đó là các dịch vụ công khai dùng PHP-FPM, php-cgi, FrankenPHP hoặc LiteSpeed. Hệ thống nội bộ có mức phơi lộ khác, nhưng môi trường thử nghiệm vẫn cần được xếp cùng nhóm công khai nếu người ngoài có thể gửi yêu cầu tới nó. Đây là thứ tự ưu tiên theo điều kiện triển khai, không phải kết luận rằng các mô hình ngoài mod_php đã an toàn.

Đơn vị tự vận hành cần kiểm kê theo từng website và ứng dụng, thay vì chỉ theo tên máy chủ. Danh sách nên ghi cả container, môi trường thử nghiệm và ứng dụng đóng gói sẵn trình thông dịch PHP, cùng phiên bản đang chạy và người chịu trách nhiệm cập nhật. Một máy chủ có thể phục vụ nhiều website bằng các nhánh PHP khác nhau. Phiên bản trả về từ PHP trên dòng lệnh cũng có thể khác phiên bản của tiến trình nhận yêu cầu web, nên không đủ để xác nhận trạng thái vá.

Với dịch vụ hosting thuê ngoài, chủ website cần hỏi nhà cung cấp phiên bản hoặc gói PHP thực sự đang phục vụ website của mình, thời điểm triển khai bản sửa lỗi và việc khởi động lại tiến trình. Thông báo rằng hạ tầng dùng chung đã được cập nhật chưa tự nó xác nhận một container riêng hay ứng dụng dùng PHP đóng gói đã chuyển sang mã mới. Nếu chưa có câu trả lời cho môi trường đang phục vụ lưu lượng, trạng thái vá của website vẫn chưa rõ.

Vì sao cập nhật gói chưa phải là hoàn tất vá lỗi?

Sau khi cài gói mới, tiến trình PHP còn chạy có thể vẫn giữ mã cũ trong bộ nhớ. Container dùng ảnh cũ cũng không tự thay đổi chỉ vì PHP trên máy chủ nền đã được cập nhật. Vì vậy, đơn vị vận hành cần dựng và triển khai lại ảnh bị ảnh hưởng, khởi động lại hoặc thay thế các tiến trình liên quan, rồi xác nhận phiên bản hoặc gói vá trên chính môi trường xử lý yêu cầu web.

Khi chưa thể cập nhật ngay, giới hạn yêu cầu tại web server hoặc proxy, quy tắc tường lửa ứng dụng web và một số điều chỉnh cấu hình PHP có thể giảm các đường khai thác cụ thể. Chẳng hạn, hướng dẫn của PHP nêu việc tắt session.upload_progress.enabled và khởi động lại các tiến trình để chặn những đường tấn công đã xác nhận liên quan đến chức năng này. Các thay đổi về giới hạn bộ nhớ hay kích thước yêu cầu phải được thử với chức năng tải tệp và biểu mẫu của website. Những biện pháp này chỉ giảm phơi lộ tạm thời; cập nhật mã đã sửa lỗi mới là cách khắc phục đầy đủ cho hai CVE.

Nhật ký cần được xem cùng trạng thái bản vá

Việc cập nhật không cho biết máy chủ trước đó có bị khai thác hay không. Trong phân tích của Datadog Security Labs, nhóm nghiên cứu cho biết đã tái hiện việc thực thi lệnh từ một yêu cầu HTTP không cần xác thực trên PHP 8.5.11; yêu cầu đó không đi tới mã ứng dụng. Kết quả này làm rõ vì sao nhật ký của máy chủ web và tiến trình PHP cần được xem cùng nhau, kể cả khi ứng dụng có trang đăng nhập.

Những dấu hiệu đáng đối chiếu gồm yêu cầu biểu mẫu có cấu trúc hoặc dung lượng bất thường, lỗi cạn bộ nhớ khi khởi tạo yêu cầu, tiến trình web dừng đột ngột, tiến trình lệnh xuất hiện dưới quyền máy chủ web hoặc tệp lạ trên máy chủ. Lỗi cạn bộ nhớ riêng lẻ có thể phát sinh từ hoạt động hợp lệ, còn một cuộc tấn công thành công không nhất thiết làm tiến trình bị sập. Vì thế, cần ghép thời điểm của yêu cầu HTTP, lỗi PHP và hoạt động tiến trình trước khi kết luận có xâm nhập.

Đối với người truy cập website, phạm vi ảnh hưởng trực tiếp vẫn nằm ở hệ thống phía máy chủ. Đối với đơn vị vận hành tại Việt Nam, thông tin quyết định sau đợt cập nhật là website công khai nào đã thực sự chạy mã được vá và liệu nhật ký trong thời gian dùng bản cũ có dấu hiệu cần điều tra thêm.

Đọc thêm: