Lỗ hổng bảo mật PHP2Shell là gì? Cách kiểm tra và khắc phục

PHP2Shell có thể cho phép kẻ tấn công chưa xác thực thực thi mã từ xa trên một số hệ thống chạy PHP bị ảnh hưởng. Lỗ hổng nằm trong lõi PHP, nên chỉ cập nhật WordPress, plugin hay mã nguồn ứng dụng là chưa đủ; quản trị viên cần kiểm tra và cập nhật đúng PHP runtime đang phục vụ website.

PHP2Shell là gì?

PHP2Shell là tên gọi được dùng cho một nhóm lỗ hổng nghiêm trọng trong lõi PHP, được theo dõi qua hai mã CVE: CVE-2026-109618 và CVE-2026-109619. Các lỗi liên quan đến xử lý bộ nhớ và trạng thái nội bộ của PHP khi xử lý request; trong một số điều kiện, chúng có thể dẫn đến thực thi mã từ xa (RCE). PHP xếp các lỗ hổng này ở mức nghiêm trọng, với điểm CVSS v4 là 9.2.

Điểm cần lưu ý là lỗi nằm trong runtime PHP, không nhất thiết xuất phát từ một plugin hay đoạn mã riêng của website. Do đó, một ứng dụng PHP không có lỗ hổng trong mã nguồn vẫn có thể gặp rủi ro nếu đang chạy phiên bản PHP chưa được vá.

CVE-2026-109618: Lỗi xử lý khi PHP cạn bộ nhớ

Lỗi này xảy ra trong một số tình huống PHP hết bộ nhớ khi đang xử lý request. Dữ liệu nội bộ có thể chưa được khởi tạo đầy đủ, nhưng quá trình dọn dẹp request vẫn tiếp tục đọc hoặc xử lý dữ liệu đó. Advisory của PHP mô tả các trường hợp như xử lý multipart request và dữ liệu đầu vào có thể dẫn đến tình trạng này.

CVE-2026-109619: Trạng thái cũ còn sót giữa các request

Một PHP worker có thể giữ lại trạng thái nội bộ thuộc về request trước sau khi vùng nhớ liên quan đã được giải phóng. Nếu request tiếp theo đi qua cùng worker và PHP sử dụng trạng thái cũ trước khi khởi tạo lại, lỗi use-after-free có thể xảy ra. Khả năng khai thác phụ thuộc vào luồng ứng dụng, cấu hình và extension được sử dụng.

PHP2Shell có thể gây ra hậu quả gì?

Trong trường hợp khai thác thành công, kẻ tấn công có thể thực thi mã với quyền của tiến trình web server hoặc PHP worker. Điều đó có thể dẫn đến đọc dữ liệu mà tiến trình được phép truy cập, sửa nội dung website hoặc tiếp cận thông tin nhạy cảm như thông tin xác thực lưu trong môi trường chạy ứng dụng.

Nhóm nghiên cứu Wiz đã công bố các thử nghiệm RCE trên WordPress, Drupal và Joomla. Tuy nhiên, đây là các ví dụ minh họa: nguyên nhân nằm trong PHP, nên rủi ro không chỉ giới hạn ở ba nền tảng này. Khả năng khai thác thực tế còn phụ thuộc vào phiên bản, SAPI, cấu hình, extension và cách hệ thống xử lý request.

RCE không đồng nghĩa kẻ tấn công tự động có quyền quản trị toàn bộ máy chủ. Mức độ ảnh hưởng còn tùy quyền của tiến trình PHP, quyền truy cập file, cách lưu secrets và mức độ phân tách giữa ứng dụng với các thành phần khác.

Phiên bản PHP nào bị ảnh hưởng?

PHP đã phát hành các bản cập nhật bảo mật cho những nhánh đang được duy trì. Nếu tự cài PHP, hãy đối chiếu phiên bản với bảng dưới đây. Với package do nhà cung cấp hệ điều hành hoặc hosting quản lý, cần kiểm tra advisory của chính nhà cung cấp vì họ có thể đưa bản vá ngược vào package mà không thay đổi số phiên bản theo cách dễ nhận biết.

PHP 8.1 và các nhánh cũ hơn không còn được dự án PHP hỗ trợ cập nhật bảo mật thường xuyên. Một số bản phân phối Linux hoặc nhà cung cấp dịch vụ dài hạn có thể cung cấp bản vá ngược; hãy xác nhận trạng thái package với họ. Nếu không có bản vá được hỗ trợ, nên lên kế hoạch chuyển sang nhánh PHP còn được duy trì.

Cách kiểm tra và khắc phục PHP2Shell

PHP cho biết các bản vá dành cho những hệ thống phục vụ request web, gồm PHP-FPM, Apache mod_php, php-cgi, FrankenPHP và LiteSpeed. Mức độ rủi ro khai thác thực tế có thể khác nhau giữa các SAPI, nhưng không nên bỏ qua việc kiểm tra chỉ vì website đang dùng một kiến trúc cụ thể.

1. Xác định PHP runtime đang chạy website

Kiểm tra phiên bản PHP tại đúng môi trường phục vụ website: PHP-FPM pool, Apache module, container, hosting panel hoặc package của nhà cung cấp. Kết quả từ lệnh php -v thường phản ánh PHP CLI; phiên bản này có thể khác runtime mà website đang sử dụng. Nếu có nhiều website hoặc nhiều container, hãy kiểm tra từng môi trường thay vì chỉ kiểm tra một máy chủ.

2. Cập nhật lên bản đã vá

Cài bản cập nhật từ trang phát hành PHP, package chính thức của hệ điều hành hoặc nhà cung cấp hosting. Với container, cần cập nhật image nền, build lại và triển khai container mới; nâng cấp PHP trên máy host không tự cập nhật PHP nằm bên trong image. Với CMS như WordPress, việc cập nhật core, theme và plugin vẫn cần thiết nhưng không thay thế việc cập nhật PHP runtime.

3. Khởi động lại worker và xác minh

Sau khi cập nhật, khởi động lại dịch vụ PHP hoặc triển khai lại workload để worker mới nạp runtime đã vá. Sau đó xác nhận lại phiên bản tại đúng SAPI đang phục vụ website, đồng thời kiểm tra log để phát hiện lỗi tương thích sau nâng cấp.

4. Kiểm tra dấu hiệu khai thác trước khi vá

Nếu máy chủ đã chạy phiên bản bị ảnh hưởng, việc nâng cấp không tự xác nhận rằng hệ thống chưa từng bị xâm nhập. Hãy rà soát log PHP, web server và reverse proxy quanh thời điểm có request bất thường, lỗi bộ nhớ, HTTP 500 lặp lại hoặc hoạt động bất thường của PHP worker.

Nếu phát hiện dấu hiệu xâm nhập, nên cô lập máy chủ khỏi các hệ thống không liên quan, giữ lại log để điều tra, thay đổi thông tin xác thực có thể đã bị lộ và khôi phục ứng dụng từ nguồn sạch sau khi đã xử lý nguyên nhân.

Có thể làm gì nếu chưa cập nhật được ngay?

Các cấu hình giảm thiểu chỉ giúp hạn chế một số đường khai thác, không thay thế bản vá. Với CVE-2026-109618, advisory PHP đề cập đến việc giới hạn request và kiểm soát kích thước dữ liệu ở lớp frontend; một số biện pháp cấu hình PHP chỉ giảm rủi ro của những tình huống cụ thể. Với CVE-2026-109619, PHP lưu ý không có cấu hình chung nào thay thế được bản vá đầy đủ.

Ngày 23/10/2026, PHP cũng công bố thông tin về CVE-2026-115560, một lỗi RCE riêng liên quan đến session upload progress. Theo PHP, lỗi này chỉ có thể xảy ra khi ứng dụng kết hợp một số cấu hình session cụ thể với việc thay đổi session.serialize_handler trong lúc chạy. Trong thời gian chờ bản sửa chính thức, PHP khuyến nghị tắt session.upload_progress.enabled nếu hệ thống có thể chịu ảnh hưởng; ứng dụng không thay đổi serialize handler trong lúc chạy không thuộc điều kiện được mô tả. Đây là lỗi riêng, không nên gộp với hai CVE thường được gọi là PHP2Shell.

Lớp bảo vệ hạ tầng có thay thế bản vá PHP không?

Không. Firewall, phân đoạn mạng, giới hạn cổng truy cập và giám sát log giúp giảm bề mặt tấn công hoặc hỗ trợ phát hiện hoạt động bất thường, nhưng không sửa lỗi trong PHP runtime.

Nếu website chạy trên Bizfly Cloud Server, đội ngũ quản trị vẫn cần cập nhật PHP tại máy chủ hoặc container đang chạy ứng dụng. Có thể kết hợp với Firewall của Bizfly Cloud để kiểm soát luồng truy cập ở lớp mạng; biện pháp này cần được xem là một lớp bảo vệ bổ sung, không phải phương án xử lý PHP2Shell.

Câu hỏi thường gặp về PHP2Shell

PHP2Shell có chỉ ảnh hưởng WordPress không?

Không. WordPress, Drupal và Joomla là những nền tảng được dùng trong các thử nghiệm công khai. Lỗ hổng nằm trong lõi PHP nên các ứng dụng khác chạy trên phiên bản bị ảnh hưởng cũng cần được kiểm tra.

Cập nhật WordPress hoặc plugin có khắc phục PHP2Shell không?

Không. Cần cập nhật đúng PHP runtime đang phục vụ website. Việc cập nhật CMS và plugin vẫn cần thiết để xử lý các rủi ro khác.

PHP-FPM có cần kiểm tra không?

Có. PHP nêu PHP-FPM trong phạm vi các hệ thống phục vụ request web cần cập nhật. Hãy kiểm tra advisory của PHP hoặc nhà cung cấp package và xác minh bản vá trong môi trường đang chạy thực tế.

Dùng WAF hoặc Firewall có đủ an toàn không?

Không. Các lớp lọc lưu lượng có thể hỗ trợ giảm rủi ro, nhưng không bảo đảm chặn mọi đường khai thác và không thay thế bản PHP đã vá.

Cập nhật lên PHP 8.5.12 có xử lý luôn CVE-2026-115560 không?

Không thể mặc định như vậy. Tính đến ngày 24/10/2026, PHP mô tả CVE-2026-115560 là lỗi riêng và khuyến nghị tắt session upload progress trong trường hợp cần giảm thiểu trước khi có bản sửa chính thức.

Kết luận

PHP2Shell là nhóm lỗi trong lõi PHP có thể dẫn đến thực thi mã từ xa, vì vậy quản trị viên cần xác định đúng PHP runtime đang phục vụ website và cập nhật lên bản đã vá. Sau khi nâng cấp, hãy khởi động lại worker, xác minh phiên bản thực tế và rà soát log nếu hệ thống từng chạy bản bị ảnh hưởng.