PHP phát hành bản vá khẩn cấp cho hai lỗ hổng RCE nghiêm trọng

Nhóm phát triển PHP vừa tung ra loạt bản cập nhật 8.5.12, 8.4.27, 8.3.36 và 8.2.35, khắc phục hai lỗ hổng nghiêm trọng có thể bị khai thác để thực thi mã từ xa (RCE) mà không cần xác thực. Đây là một trong những cảnh báo bảo mật nghiêm trọng nhất của ngôn ngữ lập trình phổ biến này trong thời gian gần đây, và mọi quản trị viên hệ thống chạy PHP đều nên ưu tiên xử lý ngay.

Ai đang gặp rủi ro?

Theo thông báo từ php.net, mọi cài đặt PHP có phục vụ các yêu cầu web đều nằm trong vùng nguy hiểm, bao gồm:

• PHP-FPM
• Apache với mod_php
• php-cgi
• FrankenPHP
• LiteSpeed

Nhóm phát triển đánh giá rủi ro cao nhất đối với mod_php, bởi đã có bằng chứng khai thác cụ thể: một yêu cầu chưa xác thực có thể kích hoạt cuộc tấn công trước khi bất kỳ dòng mã ứng dụng nào được chạy. Nói cách khác, kẻ tấn công không cần tài khoản, không cần lỗ hổng trong ứng dụng của bạn — chỉ cần máy chủ đang chạy PHP là đủ.

Hai lỗ hổng là gì?

RCE qua lỗi xử lý hết bộ nhớ — CVE-2026-109618 (GHSA-w8hw-w9fx-j79w)

Khi xử lý tình huống hết bộ nhớ (OOM), quá trình này có thể làm gián đoạn PHP trong lúc dữ liệu yêu cầu nội bộ mới chỉ được khởi tạo một phần. Bước dọn dẹp yêu cầu sau đó có thể nhầm tưởng dữ liệu không hợp lệ là hợp lệ và tiếp tục xử lý, mở đường cho kẻ tấn công chèn mã độc.

RCE qua trạng thái toàn cục cũ — CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp)

Trạng thái nội bộ thuộc về một yêu cầu có thể tồn tại sau khi vùng bộ nhớ nền của nó đã được giải phóng. Một yêu cầu tiếp theo được xử lý bởi cùng worker có thể sử dụng trạng thái cũ đó trước khi quá trình khởi tạo bình thường đặt lại nó — tạo ra đường dẫn khai thác nguy hiểm.

Cách cập nhật

• Nâng cấp lên PHP 8.5.12, 8.4.27, 8.3.36 hoặc 8.2.35. Bản mã nguồn có trên trang tải xuống chính thức của PHP, kể cả mã nguồn và bản biên dịch sẵn cho Windows.
• Các bản phân phối Linux và nhà cung cấp LTS đã nhận bản vá trước, nên hãy kiểm tra kho gói của bạn để lấy bản cập nhật mới nhất.
• PHP 8.1 trở về trước không còn được nhóm PHP hỗ trợ. Một số bản phân phối và nhà cung cấp LTS vẫn cung cấp bản vá backport — hãy liên hệ nhà cung cấp hoặc nâng cấp lên phiên bản được hỗ trợ.

Do mức độ nghiêm trọng của sự cố, nhóm bảo mật PHP đã cung cấp các bản backport mã nguồn tối thiểu cho PHP 7.4, 8.0 và 8.1, dành cho những ai tự biên dịch hoặc không có nhà cung cấp LTS.

Chỉ có cập nhật lên bản mới mới là giải pháp triệt để. Các biện pháp dưới đây chỉ giảm thiểu rủi ro theo từng đường tấn công cụ thể, không biến hệ thống thành an toàn.

Nếu chưa thể cập nhật ngay

Giảm thiểu rủi ro từ CVE-2026-109618

• Đặt memory_limit=-1, ưu tiên theo cách ứng dụng không thể ghi đè, ví dụ dùng php_admin_value trong pool FPM hoặc cấu hình Apache; đồng thời kiểm tra không có pool, thư mục hay thiết lập ứng dụng nào đặt lại giới hạn hữu hạn. Cách này loại bỏ khả năng gây lỗi bộ nhớ có thể kiểm soát, nhưng lỗi cấp phát bộ nhớ nền tảng vẫn có thể chạm tới đoạn mã nguy hiểm.
• Đặt post_max_size thấp. Với ứng dụng không cần tải tệp lên, đặt post_max_size = 8M; nếu bắt buộc phải có tải tệp, đặt 32M. Luôn giữ upload_max_filesize nhỏ hơn post_max_size.
• Cân nhắc áp đặt giới hạn ở tầng web server hoặc proxy cho kích thước yêu cầu sau giải mã, số trường đầu vào, số phần multipart, số header và độ sâu lồng nhau. Các giới hạn này phải bao phủ cả những yêu cầu không có Content-Length hợp lệ.
• Dùng giới hạn container hoặc cgroup làm ranh giới khả dụng, ưu tiên chính sách chỉ tiêu diệt worker bị ảnh hưởng. Không dùng RLIMIT_AS hay RLIMIT_DATA, vì chúng có thể gây ra chính lỗi cấp phát bộ nhớ nguy hiểm.

Giảm thiểu rủi ro từ CVE-2026-109619

• Đặt session.upload_progress.enabled=0 và khởi động lại toàn bộ worker. Nên đặt trong php.ini, cấu hình pool FPM hoặc cấu hình server áp dụng trước khi phân tích yêu cầu — không dựa vào ini_set() hay .user.ini của FPM.
• Trên PHP 8.5, đặt fatal_error_backtraces=0 và khởi động lại mọi worker.
• Loại bỏ các thiết lập không hợp lệ hoặc đã lỗi thời được áp dụng theo từng yêu cầu và có thể phát sinh chẩn đoán trước khi khởi tạo. Ẩn chẩn đoán bằng error_reporting, display_errors hay @ không có tác dụng.
• Sửa các lỗi fatal và tình trạng hết thời gian thực thi mà kẻ tấn công có thể chạm tới, kể cả lỗi trong callback, xử lý tải lên hoặc nhập dữ liệu, và bước dọn dẹp.

Lời khuyên cho người dùng tại Việt Nam

Với các doanh nghiệp và lập trình viên Việt Nam đang vận hành website, API hay hệ thống nội bộ trên PHP, đây là thời điểm cần rà soát ngay phiên bản đang chạy bằng lệnh php -v hoặc kiểm tra qua phpinfo(). Nhiều hệ thống dùng panel quản trị (cPanel, Plesk, aaPanel) hoặc container Docker thường bị bỏ quên cập nhật — cần kiểm tra cả môi trường staging lẫn production.

Nếu dùng dịch vụ hosting hoặc VPS có hỗ trợ, hãy liên hệ nhà cung cấp để xác nhận đã có bản vá, vì một số nhà cung cấp chậm cập nhật kho gói. Trong lúc chờ, áp dụng ngay các biện pháp giảm thiểu và tăng cường giám sát log để phát hiện dấu hiệu khai thác bất thường.

Lưu ý rằng cấu hình giảm thiểu chỉ là tấm khiên tạm thời — bản cập nhật chính thức vẫn là giải pháp duy nhất đảm bảo an toàn hoàn toàn.