Cảnh Báo Bảo Mật PHP: 2 Lỗ Hổng RCE CVSS 9.2, Cập Nhật Ngay Lên 8.5.12, 8.4.27, 8.3.36, 8.2.35

Đội ngũ phát triển PHP vừa phát hành bản vá bảo mật khẩn cấp cho toàn bộ các nhánh PHP đang được hỗ trợ, vá hai lỗ hổng thực thi mã từ xa (RCE) nghiêm trọng cho phép kẻ tấn công chiếm quyền điều khiển máy chủ mà không cần đăng nhập. Cả hai lỗ hổng đều được chấm điểm CVSS v4.0 ở mức 9.2/10. Nếu website của bạn đang chạy PHP — và gần như mọi website WordPress đều chạy PHP — hãy đọc kỹ bài này và cập nhật ngay.

Chuyện gì đã xảy ra?

Ngày 20/10/2026, nhóm bảo mật PHP phát đi thông báo hiếm có: báo trước một bản vá bảo mật nghiêm trọng sẽ phát hành lúc 14:00 UTC ngày 21/10/2026. Đúng lịch hẹn, hôm nay các bản PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 và PHP 8.2.35 đã chính thức ra mắt, và cả bốn đều là bản vá bảo mật cho cùng hai lỗ hổng dưới đây. Nhóm PHP khuyến cáo toàn bộ người dùng cập nhật ngay lập tức, đồng thời nhấn mạnh: không có biện pháp giảm thiểu nào là hoàn toàn — cập nhật là lựa chọn an toàn duy nhất.

Hai lỗ hổng nghiêm trọng vừa được vá

CVE-2026-109618 — RCE thông qua lỗi xử lý hết bộ nhớ (OOM)

Khi PHP xử lý một request mà bị cạn bộ nhớ giữa chừng (out-of-memory), quá trình xử lý có thể bị ngắt trong lúc dữ liệu nội bộ của request mới chỉ được khởi tạo một phần. Lúc dọn dẹp request, PHP có thể coi phần dữ liệu chưa hoàn chỉnh đó là hợp lệ — và kẻ tấn công lợi dụng chính điểm này để thực thi mã tùy ý trên máy chủ.

CVE-2026-109619 — RCE thông qua trạng thái toàn cục cũ (stale global state)

Lỗ hổng thứ hai nằm ở trạng thái nội bộ gắn với request: trạng thái này có thể vẫn “sống sót” sau khi vùng nhớ chứa nó đã bị giải phóng. Một request tiếp theo được cùng worker xử lý có thể dùng phải trạng thái cũ đó trước khi quá trình khởi tạo bình thường kịp ghi đè — mở đường cho tấn công RCE.

Điểm đáng sợ chung của cả hai: chúng có thể bị kích hoạt bởi một request chưa xác thực, và với cấu hình mod_php, exploit mẫu đã chứng minh được tấn công xảy ra trước cả khi mã ứng dụng chạy.

Ai đang gặp rủi ro?

Tất cả các cài đặt PHP phục vụ request web đều nằm trong diện ảnh hưởng, bao gồm PHP-FPM, Apache với mod_php, php-cgi, FrankenPHP và LiteSpeed. Nhóm PHP đánh giá rủi ro cao nhất thuộc về mod_php. Ngoài ra cần lưu ý:

• PHP 8.1 trở xuống không còn nhận bản vá từ dự án PHP. Một số nhà phân phối Linux/LTS có bản vá backport — hãy liên hệ nhà cung cấp của bạn, hoặc nâng cấp lên bản được hỗ trợ. Riêng người build từ source, nhóm PHP đã cung cấp bản backport tối thiểu cho PHP 7.4, 8.0 và 8.1.
• PHP 8.2 sẽ kết thúc vòng đời (EOL) vào 31/12/2026 và không còn nhận vá bảo mật sau ngày đó — hãy lên kế hoạch nâng cấp ngay từ bây giờ.
• Nếu bạn đang dùng kho rpms.remirepo.net do tình nguyện viên duy trì: kho này không có bản vá hôm nay — hãy chuyển sang gói của nhà phân phối hoặc build từ source để áp dụng bản vá ngay.

Cách cập nhật lên bản vá mới nhất

Kiểm tra phiên bản hiện tại: nếu có SSH, chạy lệnh php -v. Nếu dùng hosting chia sẻ, vào cPanel/DirectAdmin mục “Select PHP Version” để xem và đổi phiên bản. Với website WordPress, bạn cũng có thể vào Công cụ → Sức khỏe trang (Site Health) để xem phiên bản PHP đang chạy, rồi nhắn nhà cung cấp hosting yêu cầu cập nhật lên bản vá tương ứng. Sau khi cập nhật, nhớ kiểm tra lại website, đặc biệt là các form, giỏ hàng và tính năng upload.

Chưa cập nhật ngay được? Các biện pháp giảm thiểu tạm thời

Nhóm PHP khẳng định chỉ có cập nhật mới là giải pháp trọn vẹn. Tuy nhiên nếu chưa thể cập nhật ngay, các biện pháp sau giúp giảm bề mặt tấn công cho từng lỗ hổng cụ thể:

Giảm thiểu CVE-2026-109618 (lỗi OOM)

• Đặt memory_limit=-1 ở cấp mà ứng dụng không ghi đè được, ví dụ php_admin_value trong cấu hình FPM pool hoặc Apache, và kiểm tra không còn pool/thư mục/ứng dụng nào đặt lại giới hạn hữu hạn.
• Đặt post_max_size thấp: 8M nếu site không cần upload file, tối đa 32M nếu có upload; giữ upload_max_filesize nhỏ hơn post_max_size.
• Áp giới hạn ở tầng web server/proxy cho kích thước request, số trường input, số phần multipart và độ sâu lồng nhau.
• Dùng giới hạn container/cgroup làm “hàng rào sống còn”, ưu tiên chính sách chỉ kill đúng worker bị ảnh hưởng. Không dùng RLIMIT_AS/RLIMIT_DATA thay thế vì chúng có thể tự gây ra lỗi cấp phát — chính là đường vào của lỗ hổng.

Giảm thiểu CVE-2026-109619 (trạng thái cũ)

• Đặt session.upload_progress.enabled=0 trong php.ini hoặc cấu hình FPM/server (áp dụng trước khi parse request, không dùng ini_set() hay .user.ini) rồi restart toàn bộ worker.
• Trên PHP 8.5: đặt fatal_error_backtraces=0 và restart worker.
• Gỡ các cài đặt không hợp lệ/bị deprecated áp dụng theo request mà phát sinh thông báo chẩn đoán trước lúc khởi tạo — việc ẩn lỗi bằng error_reporting hay display_errors không có tác dụng.
• Sửa các lỗi fatal/timeout mà kẻ tấn công có thể chạm tới, nhất là trong callback, xử lý upload/import và bước dọn dẹp.

Kết luận

Đây là một trong những đợt vá bảo mật nghiêm trọng nhất của PHP trong nhiều năm: hai lỗ hổng RCE không cần xác thực, điểm CVSS 9.2, ảnh hưởng mọi mô hình triển khai PHP phổ biến. Việc cần làm ngay hôm nay rất rõ ràng: kiểm tra phiên bản PHP của website, cập nhật lên 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 (hoặc nâng cấp khỏi các nhánh đã hết hỗ trợ), và chỉ dùng các biện pháp giảm thiểu phía trên như giải pháp tạm thời trong lúc chờ cập nhật. Theo dõi thêm các thủ thuật WordPress và bảo mật website tại FLATSOME.XYZ và đọc lại chi tiết bài cảnh báo này tại bài viết cảnh báo lỗ hổng PHP.

Nguồn tham khảo: thông báo bảo mật chính thức trên php.net, advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618) và GHSA-6wmf-4rv5-p3rp (CVE-2026-109619); tải bản vá tại trang downloads của PHP.