Tóm tắt nhanh
- PHP phát hành bản vá khẩn ngày 21/10/2026 cho hai lỗ hổng thực thi mã từ xa không cần xác thực, được gọi chung là PHP2Shell.
- Apache mod_php có mức rủi ro cao nhất; PHP-FPM, LiteSpeed, FrankenPHP và php-cgi cũng nằm trong phạm vi cảnh báo.
- Các bản đã vá là PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35; bản phân phối Linux có thể cung cấp bản vá ngược qua gói riêng.
- Sửa cấu hình chỉ giảm một số đường khai thác. Cần cập nhật PHP và kiểm tra dịch vụ thực sự phục vụ website.
Nhóm phát triển PHP phát hành bản vá bảo mật khẩn ngày 21/10/2026, xử lý hai lỗ hổng có thể cho phép kẻ tấn công thực thi mã từ xa mà không cần đăng nhập. Điểm đáng lo với người quản trị website là lỗi nằm dưới lớp ứng dụng: riêng Apache mod_php đã có cách khai thác được chứng minh có thể kích hoạt trước khi mã ứng dụng chạy.
Vì vậy, website vừa cập nhật WordPress hoặc Laravel vẫn chưa thể xem là đã xử lý PHP2Shell. Việc cần làm nằm ở PHP đang phục vụ website, thường thuộc phạm vi quản lý của đội vận hành máy chủ hoặc nhà cung cấp hosting.
Lỗi nằm dưới ứng dụng, mod_php cần được ưu tiên vá
Bộ lọc đặt trong mã ứng dụng không phải chỗ có thể dựa vào để chặn một cuộc tấn công xảy ra trước chính mã đó. Đây là lý do cần tách rõ cập nhật CMS với cập nhật bộ thực thi PHP, thay vì thấy bảng điều khiển WordPress báo phiên bản mới nhất rồi dừng kiểm tra.
Thông cáo PHP liệt kê toàn bộ các kiểu cài đặt phục vụ request web trong diện rủi ro, gồm PHP-FPM, Apache mod_php, php-cgi, FrankenPHP và LiteSpeed. mod_php được đánh giá nguy hiểm nhất, nhưng điều đó không có nghĩa chuyển sang PHP-FPM là hết ảnh hưởng.
Hai lỗi phá vỡ vòng đời dữ liệu của request theo những cách khác nhau. Với CVE-2026-109618, tình huống hết bộ nhớ có thể ngắt quá trình khởi tạo dữ liệu nội bộ; đến lúc dọn dẹp, PHP lại có thể xử lý phần dữ liệu chưa hợp lệ như dữ liệu bình thường. CVE-2026-109619 liên quan đến trạng thái nội bộ còn sót lại sau khi vùng nhớ tương ứng đã được giải phóng; request sau do cùng worker xử lý có thể sử dụng trạng thái cũ ấy trước khi quá trình khởi tạo đặt lại nó.
PHP công bố cả hai lỗ hổng có điểm CVSS v4.0 là 9,2. Mức điểm này thể hiện độ nghiêm trọng, không phải tỷ lệ website đã bị xâm nhập. Tương tự, việc website tạm ngừng truy cập để bảo trì cũng không tự nó chứng minh có rò rỉ dữ liệu.
Vá đúng nhánh PHP, đừng bỏ sót gói của nhà phân phối
Ưu tiên thực tế là đưa môi trường đang chạy lên bản đã vá, không nhất thiết chuyển vội toàn bộ ứng dụng sang một nhánh PHP mới. Các mốc PHP công bố cho từng nhánh đang được hỗ trợ như sau:
| Nhánh PHP đang dùng | Phiên bản đã vá do PHP phát hành |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Số liệu: PHP.net.
Nhà phân phối Linux và đơn vị hỗ trợ dài hạn đã nhận bản vá trước thời điểm công bố. Với máy chủ dùng gói từ kho của hệ điều hành, cần kiểm tra thông báo bảo mật và bản cập nhật của chính đơn vị cung cấp gói; không nên chỉ đối chiếu vài chữ số đầu của phiên bản rồi kết luận chưa được vá, bởi bản sửa có thể được đưa ngược vào nhánh cũ.
PHP 8.1 trở về trước không còn nhận cập nhật thông thường từ dự án PHP. Lần này nhóm bảo mật vẫn cung cấp các bản sửa tối thiểu ở dạng mã nguồn cho PHP 7.4, 8.0 và 8.1, nhưng đó không phải việc khôi phục hỗ trợ dài hạn cho những nhánh đã hết vòng đời. Người dùng hosting cần hỏi nhà cung cấp về gói đã vá, còn đội tự biên dịch phải kiểm tra việc tích hợp bản sửa vào bản đang triển khai.
Với website kinh doanh, tách nhiệm vụ vá khẩn khỏi kế hoạch nâng nhánh lớn sẽ dễ kiểm soát hơn: trước mắt đóng lỗ hổng trên môi trường hiện có, sau đó kiểm thử tương thích để rời nhánh hết hỗ trợ. Chờ hoàn tất một đợt nâng cấp ứng dụng dài ngày mới vá PHP là đánh đổi không hợp lý.
Chỉnh php.ini chỉ là giảm thiểu tạm thời
Thay đổi cấu hình không tạo ra một bản PHP an toàn hoàn chỉnh. Thông cáo bảo mật nhấn mạnh chỉ cập nhật mới xử lý đầy đủ; các biện pháp tạm thời chỉ làm giảm khả năng tiếp cận một số đường khai thác đã biết.
Với lỗi trạng thái cũ, PHP hướng dẫn tắt session.upload_progress.enabled từ cấu hình áp dụng trước khi phân tích request và khởi động lại mọi worker. Đặt cấu hình bằng ini_set() trong ứng dụng hoặc dựa vào .user.ini của FPM không đáp ứng yêu cầu đó. Trên PHP 8.5 còn có biện pháp tắt fatal_error_backtraces, nhưng nó cũng chỉ chặn một đường khai thác đã xác nhận.
Với lỗi hết bộ nhớ, hướng dẫn đặt memory_limit=-1 có điều kiện đi kèm: nó loại bỏ lỗi phát sinh từ giới hạn bộ nhớ do PHP kiểm soát, trong khi lỗi cấp phát ở tầng bên dưới vẫn có thể đi tới đoạn mã có lỗ hổng. Không nên sao chép riêng dòng cấu hình này rồi bỏ qua giới hạn tài nguyên bên ngoài tiến trình và tác động tới khả năng phục vụ của máy chủ.
Những khác biệt ấy khiến một danh sách chỉnh nhanh php.ini dễ tạo cảm giác an toàn sai. Nếu chưa triển khai được gói mới, đội vận hành nên áp dụng biện pháp giảm thiểu theo đầy đủ thông cáo, ghi rõ phần rủi ro còn lại và tiếp tục ưu tiên bản vá.
Hosting Việt Nam cần xác nhận runtime của từng website
Điểm dễ sót khi vận hành là kiểm tra đúng một bản PHP nhưng website lại dùng bản khác. Với hệ thống có nhiều nhánh PHP, kết quả php -v ở dòng lệnh chỉ xác nhận chương trình vừa được gọi, không đủ để khẳng định mọi website đều đã chạy bản vá.
Người dùng hosting nên yêu cầu nhà cung cấp xác nhận nhánh PHP và tình trạng vá của môi trường gắn với tên miền của mình. Đội quản trị VPS cần đối chiếu cấu hình web server với dịch vụ PHP tương ứng, kiểm tra cả các pool hoặc container còn hoạt động rồi xác nhận worker cũ đã được thay thế theo quy trình cập nhật. Đây là kiểm tra ở lớp vận hành, không phải thay plugin bảo mật.
Sau khi cập nhật, cần kiểm tra website còn phục vụ bình thường và theo dõi lỗi phát sinh, nhất là luồng đăng nhập, tải tệp và xử lý biểu mẫu. Nếu hệ thống phải tạm ngừng để triển khai an toàn, một khoảng bảo trì có kiểm soát vẫn hợp lý hơn việc giữ nguyên runtime dễ bị tấn công chỉ để tránh gián đoạn trước mắt.
Việc cần xác nhận cuối cùng không phải là “đã chạy lệnh cập nhật”, mà là request của website đang được xử lý bởi PHP có bản vá. Với đơn vị thuê hosting, câu trả lời đó phải đến từ nhà cung cấp; với đội tự quản máy chủ, nó cần được kiểm chứng trên từng môi trường đang phục vụ người dùng.
Nguồn tham khảo: PHP.net — thông cáo bảo mật ngày 21/10/2026; BleepingComputer; Qualys; TechRadar.
