Lỗ hổng PHP2Shell khiến quản trị viên phải vá máy chủ ngay

Hai lỗi trong lõi PHP có thể cho phép kẻ tấn công thực thi mã từ xa mà không cần đăng nhập. PHP Group phát hành bản sửa ngày 21/10/2026 và khuyến nghị người quản trị cập nhật ngay, bởi một yêu cầu web có thể chạm tới lỗi trước khi ứng dụng như WordPress hay framework kịp xử lý.

Lỗi nằm ở vòng đời bộ nhớ, không riêng WordPress

CVE-2026-109618 liên quan cách PHP xử lý tình huống cạn bộ nhớ: trạng thái yêu cầu có thể chưa được khởi tạo đầy đủ nhưng quy trình dọn dẹp lại coi dữ liệu đó là hợp lệ. CVE-2026-109619 bắt nguồn từ trạng thái toàn cục cũ còn sót lại sau khi vùng nhớ của yêu cầu trước đã được giải phóng; worker xử lý yêu cầu tiếp theo có thể dùng lại trạng thái đó trước khi khởi tạo bình thường.

Điểm đáng lưu ý là lỗi nằm trong chính bộ máy PHP, nên việc đổi CMS hoặc framework không loại bỏ nguy cơ. PHP Group liệt kê PHP-FPM, Apache mod_php, php-cgi, FrankenPHP và LiteSpeed trong nhóm cần rà soát; mức rủi ro cao nhất là mod_php, nơi yêu cầu chưa xác thực đã có thể kích hoạt đường khai thác trước khi mã ứng dụng chạy.

AI giúp tìm ra đường khai thác, nhưng không thay thế cập nhật

Vụ việc còn cho thấy khoảng cách giữa phát hiện một lỗi bộ nhớ và biến nó thành khai thác thực tế đang thu hẹp. Các nhóm nghiên cứu đã dùng công cụ AI để lần ra vấn đề; chuỗi khai thác trước đây đòi hỏi nhiều bước phức tạp, khó đạt được trong thực tế bởi nhà nghiên cứu con người. AI ở đây là công cụ hỗ trợ phân tích mã và tìm đường đi qua các trạng thái lỗi, chứ không phải nguyên nhân tạo ra lỗ hổng.

PHP vẫn hiện diện trên quy mô lớn: W3Techs ước tính ngôn ngữ này chiếm 69,3% website có ngôn ngữ phía máy chủ được xác định. Con số đó không có nghĩa mọi website đều dễ bị khai thác, nhưng lý giải vì sao lỗi ở tầng PHP có thể kéo theo phạm vi ứng phó rộng hơn một CMS cụ thể.

Điều này làm thay đổi cách đội vận hành đánh giá rủi ro: lỗi tồn tại lâu trong mã nguồn không đồng nghĩa nó sẽ mãi khó khai thác. Khi một đường đi khả thi được công bố, thời gian giữa phát hiện, phát hành bản vá và đối thủ tìm cách lợi dụng có thể rất ngắn. Vì vậy, các website doanh nghiệp, cửa hàng trực tuyến hay hệ thống nội bộ chạy PHP cần xác định phiên bản và cách triển khai trước, thay vì chỉ kiểm tra tên CMS.

Cập nhật đúng nhánh và kiểm tra cả worker lẫn container

PHP Group đã phát hành PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35. Quản trị viên nên nâng cấp lên bản tương ứng với nhánh đang sử dụng qua kho gói của hệ điều hành hoặc nhà cung cấp LTS, sau đó khởi động lại các tiến trình PHP và dựng lại image container nếu hệ thống triển khai bằng container. Chỉ thay file cài đặt mà để worker cũ tiếp tục chạy có thể khiến phiên bản vá chưa thực sự được áp dụng.

PHP 8.1 trở xuống không còn nhận bản cập nhật trực tiếp từ dự án PHP. Một số bản phân phối vẫn có thể backport bản sửa; cần xác nhận với nhà cung cấp thay vì mặc định rằng phiên bản cũ đã được bảo vệ. Nhóm bảo mật PHP cũng phát hành bản vá nguồn tối thiểu cho PHP 7.4, 8.0 và 8.1 dành cho trường hợp tự biên dịch hoặc không có nhà cung cấp LTS, nhưng đây không phải lý do để trì hoãn lộ trình nâng cấp.

Cấu hình tạm thời chỉ giảm một số đường tấn công

Nếu chưa thể cập nhật tức thì, hướng dẫn của PHP Group nêu một số biện pháp giảm thiểu. Với CVE-2026-109618, có thể đặt memory_limit=-1 ở cấu hình pool PHP-FPM hoặc Apache theo cách ứng dụng không thể ghi đè, đồng thời kiểm tra không có cấu hình cấp thư mục hay ứng dụng đặt lại giới hạn hữu hạn. Cách này giảm khả năng đi vào đường lỗi do giới hạn bộ nhớ có thể kiểm soát, nhưng không loại trừ lỗi phân bổ bộ nhớ bên dưới.

Giới hạn kích thước phần thân yêu cầu bằng post_max_size cũng giúp giảm một số đầu vào rủi ro: PHP Group gợi ý 8M nếu ứng dụng không cần tải tệp, hoặc 32M nếu có; upload_max_filesize cần thấp hơn mức này. Với CVE-2026-109619, có thể tắt session.upload_progress.enabled trong cấu hình áp dụng trước khi phân tích yêu cầu và khởi động lại toàn bộ worker. Trên PHP 8.5, hướng dẫn còn nêu fatal_error_backtraces=0 để chặn đường backtrace đã được xác nhận.

Các thiết lập trên chỉ chặn hoặc giảm những đường khai thác cụ thể. Tắt hiển thị lỗi bằng display_errors, error_reporting hay toán tử @ không giải quyết được vấn đề; còn cập nhật lên bản đã vá mới là cách khắc phục đầy đủ. Với hệ thống chạy mod_php hoặc máy chủ công khai, ưu tiên cần làm là xác định phiên bản đang chạy, áp bản vá từ nguồn đáng tin cậy và xác nhận các tiến trình đã khởi động lại.

Nguồn tham khảo: PHP Group; Aikido Security; The Verge