Tóm tắt nhanh
- PHP thông báo hai lỗ hổng nghiêm trọng, cùng được chấm CVSS v4.0 ở mức 9,2/10; bản vá được lên lịch lúc 14:00 UTC ngày 21/10/2026.
- PHP 8.2, 8.3, 8.4 và 8.5 là các nhánh đang được hỗ trợ dự kiến nhận bản cập nhật; những nhánh cũ hơn như 8.1, 8.0 và 7.x đã hết vòng đời.
- Lỗ hổng ở runtime PHP không được xử lý bằng cách chỉ cập nhật WordPress, theme hay plugin. Quản trị viên cần kiểm tra phiên bản PHP ở hosting và hỏi nhà cung cấp về bản vá.
PHP dự kiến phát hành bản vá cho hai lỗ hổng nghiêm trọng vào ngày 21/10/2026, nhưng những website còn chạy các nhánh PHP đã hết hỗ trợ có thể không nhận được bản sửa lỗi chính thức từ nhóm phát triển.
Thông báo của PHP Group chấm cả hai lỗi ở mức 9,2/10 theo CVSS v4.0 và ấn định giờ phát hành là 14:00 UTC. Thông báo chưa nêu chi tiết kỹ thuật, phiên bản bị ảnh hưởng hay mã bản vá; nhóm phát triển cho biết sẽ công bố các thông tin này cùng bản cập nhật.
Rủi ro lớn nhất nằm ở máy chủ chưa được nâng cấp
PHP là runtime chạy mã phía máy chủ cho nhiều website. Vì vậy, một lỗi ở tầng này không thể được xử lý chỉ bằng thao tác cập nhật nội dung trong trang quản trị WordPress. Nếu máy chủ dùng phiên bản PHP dễ bị ảnh hưởng, quản trị viên phải cập nhật runtime qua hosting hoặc hệ thống máy chủ.
Điểm cần chú ý với các website đang vận hành lâu năm là vòng đời hỗ trợ. Các nhánh 8.1, 8.0 và 7.x đã hết hỗ trợ, trong khi nhóm PHP chỉ duy trì bản vá bảo mật cho những nhánh còn được hỗ trợ. Theo thông tin hiện có, bốn nhánh 8.2, 8.3, 8.4 và 8.5 nằm trong diện nhận bản sửa lỗi dự kiến.
Điều đó tạo ra hai việc khác nhau: cài bản cập nhật khi nhà cung cấp phát hành, và lập kế hoạch nâng cấp nếu website đang phụ thuộc vào nhánh EOL. Bản vá cho nhánh mới không tự khắc phục máy chủ vẫn chạy một phiên bản cũ, cũng không đảm bảo mã nguồn của website tương thích sau khi nâng cấp.
Cập nhật plugin WordPress không thay thế bản vá PHP
WordPress và các plugin chạy trên máy chủ PHP, nhưng bản thân chúng không thay thế runtime. Cập nhật WordPress, theme hay plugin vẫn cần thiết cho bảo mật ứng dụng, song không thể sửa lỗi nằm trong phiên bản PHP đang chạy ở tầng hạ tầng.
Quản trị viên nên xác định phiên bản PHP thực tế của từng website, gồm cả môi trường chạy tác vụ nền hoặc các site phụ trên cùng tài khoản hosting. Sau đó, kiểm tra thông báo từ nhà cung cấp về phiên bản đã vá, lịch triển khai và cách đổi phiên bản PHP. Với máy chủ tự quản, cần cập nhật gói PHP theo hướng dẫn của hệ điều hành hoặc nhà cung cấp bản phân phối, rồi kiểm tra ứng dụng trước khi đưa thay đổi lên hệ thống chính.
Không nên mặc định rằng hosting sẽ tự cập nhật mọi website. Một số nhà cung cấp cho phép chọn phiên bản PHP theo từng site; khi đó quản trị viên vẫn cần xác nhận phiên bản đang được chọn và liệu nó có nhận bản sửa lỗi hay không.
Website còn dùng PHP hết hỗ trợ cần phương án chuyển tiếp
Nếu website đang chạy nhánh EOL, việc chuyển sang nhánh được hỗ trợ là giải pháp lâu dài, nhưng nâng cấp có thể ảnh hưởng đến mã nguồn cũ. Trước khi đổi phiên bản, nên tạo bản sao lưu, thử trên môi trường staging và kiểm tra các chức năng quan trọng cùng plugin phụ thuộc.
Trong thời gian chưa thể nâng cấp, có thể hỏi đơn vị hosting về biện pháp giảm rủi ro ở tầng mạng như WAF hoặc quy tắc lọc yêu cầu. Một số biện pháp tạm thời có thể gồm chặn yêu cầu multipart/form-data; đây không phải bản vá thay thế và chỉ nên triển khai sau khi đánh giá tác động tới chức năng tải tệp của website.
PHP Group cho biết có thể phát hành sớm hơn lịch nếu thông tin lỗ hổng bị công khai hoặc xuất hiện bằng chứng khai thác thực tế. Khi bản cập nhật và danh sách phiên bản bị ảnh hưởng được công bố, quản trị viên cần đối chiếu trực tiếp với phiên bản máy chủ của mình thay vì suy rộng từ các tuyên bố về công cụ khai thác bị rò rỉ.
Nguồn tham khảo: PHP Group; The Hacker News; Sansec; The Verge
