PHP2Shell bị thử khai thác: cập nhật WordPress thôi chưa đủ

PHP đã phát hành bản vá khẩn cấp cho hai lỗ hổng PHP2Shell ngày 21/10/2026, trong khi Cloudflare ghi nhận lưu lượng thử khai thác nhắm vào khách hàng. Điểm đáng lo với người quản lý website là bản WordPress mới nhất vẫn có thể chạy trên một bộ PHP còn lỗi: nút cập nhật trong trang quản trị không sửa được tầng phần mềm bên dưới.

The PHP Foundation công bố các bản đã vá gồm PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35. Hai lỗ hổng có điểm CVSS 9.2, không phải mức 10.0 từng lan truyền trước thời điểm công bố. Với chủ website thuê hosting, việc cần làm là yêu cầu nhà cung cấp xác nhận PHP phục vụ website đã nhận bản vá, thay vì chỉ kiểm tra phiên bản CMS.

Lỗi ở bộ nhớ PHP nên mã website sạch vẫn chưa đủ

PHP2Shell nguy hiểm vì lỗi nằm ở cách PHP quản lý bộ nhớ và xử lý sự cố trong một yêu cầu web, chứ không phụ thuộc vào việc website có cài một plugin dễ bị tấn công hay không. Bộ máy thực thi này là lớp chạy mã PHP của WordPress và nhiều ứng dụng khác; bảo vệ riêng mã ứng dụng không loại bỏ được lỗi bên trong nó.

Với CVE-2026-109618, một yêu cầu chạm giới hạn bộ nhớ ở thời điểm bất lợi có thể khiến PHP bỏ dở việc khởi tạo dữ liệu nội bộ, rồi dùng dữ liệu chưa hoàn chỉnh như thể nó hợp lệ. Hậu quả vượt ra ngoài việc website báo hết bộ nhớ: dữ liệu bên trong tiến trình có thể bị hỏng, tạo điều kiện cho kẻ tấn công thực thi mã.

CVE-2026-109619 có cơ chế khác. Một lỗi nghiêm trọng có thể để lại trạng thái nội bộ trỏ vào vùng nhớ của yêu cầu trước đó; khi cùng tiến trình phục vụ yêu cầu tiếp theo, PHP có thể truy cập vùng nhớ đã được giải phóng. Đây là lỗi use-after-free, có thể làm tiến trình sập và trong điều kiện phù hợp dẫn tới thực thi mã từ xa.

The PHP Foundation xác nhận đã có trình diễn thực thi mã trên Apache dùng mod_php với cấu hình mặc định, trong đó yêu cầu không cần đăng nhập có thể kích hoạt lỗi trước khi mã ứng dụng chạy. Với PHP-FPM, thực thi mã cũng được xác nhận qua đường xử lý bên trong ứng dụng. Khác biệt đó quan trọng khi đánh giá mức phơi nhiễm, nhưng không phải lý do để trì hoãn cập nhật nếu máy chủ dùng FPM.

Điều này cũng giải thích vì sao một website ít chức năng vẫn cần vá. Bớt plugin có thể giảm rủi ro ở tầng ứng dụng, nhưng không thay thế việc sửa bộ máy thực thi đang nhận yêu cầu HTTP. Ngược lại, thấy máy chủ báo lỗi bộ nhớ cũng chưa đủ để kết luận đã có kẻ xâm nhập: lỗi vận hành và dấu hiệu tấn công cần được đối chiếu bằng nhật ký.

Vá đúng PHP đang phục vụ website, đừng dừng ở lớp WAF

Ưu tiên của chủ website tại Việt Nam là xác định ai đang quản lý PHP và yêu cầu bằng chứng bản vá ở đúng môi trường chạy web. Với hosting chia sẻ, đó thường là nhà cung cấp; với VPS tự quản hoặc ứng dụng chạy trong container, trách nhiệm nằm ở người cập nhật gói hệ thống hoặc ảnh triển khai. Chờ một bản cập nhật WordPress sẽ làm chậm việc sửa đúng chỗ.

Các bản vá đầu tiên ở những nhánh còn hỗ trợ là PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35. Tuy nhiên, số phiên bản không phải bằng chứng duy nhất: nhà phân phối Linux có thể đưa bản vá ngược vào gói mang số phiên bản cũ. Khi đó cần kiểm tra changelog hoặc thông báo bảo mật của nhà cung cấp có nêu hai mã CVE, thay vì kết luận chỉ dựa trên chuỗi phiên bản.

Sau khi cập nhật, cần khởi động lại Apache, PHP-FPM và các tiến trình PHP chạy lâu tương ứng với hệ thống. Thay gói trên đĩa nhưng để tiến trình cũ tiếp tục chạy có thể khiến dịch vụ chưa thực sự sử dụng bản đã sửa. Website dùng container cũng cần được triển khai lại từ ảnh đã vá, không chỉ sửa thẻ phiên bản trong tệp cấu hình rồi để nguyên phiên đang chạy.

Cloudflare cho biết đã bật bảo vệ mặc định cho khách hàng dùng WAF miễn phí và trả phí từ 03:02 UTC ngày 21/10. Lớp bảo vệ này kết hợp tín hiệu của yêu cầu với phản hồi máy chủ, thay vì chỉ xét dữ liệu gửi lên. Hãng cũng ghi nhận kẻ tấn công thay đổi dữ liệu khai thác để tìm cách vượt quy tắc chặn.

WAF vì thế là lớp giảm rủi ro trong lúc vá, không phải giấy bảo đảm rằng PHP cũ có thể tiếp tục chạy lâu dài. Với gói trả phí, quản trị viên nên kiểm tra Managed Ruleset đã được triển khai ở chế độ chặn; đồng thời giữ bảo vệ hoạt động khi cập nhật máy chủ. Hạn chế tải lên không cần thiết và giới hạn kích thước yêu cầu có thể giảm một phần phơi nhiễm, nhưng không sửa nguyên nhân lỗi.

Cần tách rõ mức độ khẩn cấp với kết luận thiệt hại. Các nguồn công bố đã ghi nhận lượt thử khai thác, nhưng bản cập nhật của The Hacker News chưa nêu một máy chủ cụ thể được xác nhận đã bị xâm nhập. Chủ website không nên đợi có tên nạn nhân mới vá, cũng không nên coi số yêu cầu bị chặn là số website đã bị chiếm quyền.

Tiêu chí hoàn tất nên là PHP thực sự phục vụ website đã có bản vá và các tiến trình đã được khởi động lại. Nếu hệ thống có dấu hiệu bất thường trước khi cập nhật, cần kiểm tra tiếp nhật ký lỗi và thay đổi trên máy chủ; vá phần mềm ngăn đường tấn công còn tồn tại, nhưng không tự chứng minh rằng trước đó chưa từng có xâm nhập.

Nguồn tham khảo: The PHP Foundation, Cloudflare, The Hacker News