PHP vá khẩn cấp hai lỗi RCE

Ngày 21/10/2026, PHP phát hành bản vá khẩn cấp cho hai lỗ hổng nghiêm trọng mang mã CVE-2026-109618 và CVE-2026-109619, thuộc nhóm lỗi được gọi là PHP2Shell. Cả hai được PHP Group đánh giá 9,2/10 theo CVSS 4.0, có thể cho phép kẻ tấn công thực thi mã từ xa mà không cần đăng nhập. Với người đang vận hành website như mình, đây là thông tin đáng chú ý vì vấn đề nằm trong chính PHP.

RCE là gì mà khiến người làm website phải quan tâm?

RCE có thể hiểu đơn giản là khả năng chạy mã từ xa trên hệ thống bị ảnh hưởng. Thay vì chỉ khiến website báo lỗi, người tấn công có thể lợi dụng lỗ hổng để thực hiện những hành động ngoài ý muốn của chủ website. Trong trường hợp này, việc khai thác không đòi hỏi tài khoản quản trị, và mã độc có thể chạy với quyền của tiến trình PHP. Điều đó không tự động đồng nghĩa chiếm được quyền cao nhất của máy chủ, nhưng vẫn có thể gây lộ dữ liệu, sửa nội dung hoặc làm gián đoạn dịch vụ.

Lỗi PHP2Shell hoạt động như thế nào?

Lỗi đầu tiên, CVE-2026-109618, liên quan đến cách PHP xử lý khi vượt giới hạn bộ nhớ, chẳng hạn trong quá trình tiếp nhận dữ liệu tải lên. Đây không nhất thiết là lúc máy chủ hết sạch RAM, mà có thể chỉ là yêu cầu vượt mức bộ nhớ PHP cho phép. Khi dừng xử lý giữa chừng, PHP có thể để lại dữ liệu chưa khởi tạo đầy đủ, nhưng bước dọn dẹp sau đó lại sử dụng nó như dữ liệu hợp lệ. Sai sót này mở đường cho việc làm hỏng bộ nhớ và thực thi mã ngoài ý muốn.

Lỗi thứ hai, CVE-2026-109619, xuất hiện khi trạng thái của yêu cầu trước vẫn còn sót lại dù vùng nhớ liên quan đã được giải phóng. Khi cùng một tiến trình PHP tiếp tục nhận yêu cầu mới, nó có thể sử dụng nhầm phần trạng thái cũ. Có thể hình dung nhân viên đã xử lý xong hồ sơ trước nhưng chưa dọn bàn, rồi lấy nhầm giấy tờ cũ để xử lý hồ sơ tiếp theo. Việc khai thác cần các yêu cầu liên quan đi vào cùng tiến trình, chứ không phải cứ truy cập website là lập tức chiếm được hệ thống.

Mọi website đều cần được kiểm tra

Điểm khiến mình quan tâm nhất là code ứng dụng viết tốt vẫn có thể bị ảnh hưởng nếu PHP bên dưới chưa được vá. Các nhà nghiên cứu đã chứng minh khả năng khai thác trên WordPress, Drupal và Joomla, nhưng lỗ hổng không giới hạn ở những nền tảng này. Ngay cả ứng dụng rất đơn giản cũng có thể gặp rủi ro khi chạy trên môi trường PHP bị ảnh hưởng. Vì vậy, cập nhật WordPress, theme và plugin vẫn cần thiết, nhưng không thay thế được việc cập nhật PHP.

Những môi trường cần rà soát gồm PHP-FPM, Apache dùng mod_php, php-cgi, FrankenPHP và LiteSpeed. Mức độ khai thác phụ thuộc phiên bản, cấu hình và cách triển khai. Với mod_php, đã có trường hợp thực thi mã trước khi code ứng dụng bắt đầu chạy; lỗi trạng thái cũ cũng đã được kiểm chứng có thể dẫn tới RCE trên PHP-FPM. Do đó, không nên cho rằng đổi cách chạy PHP là đủ để tránh đợt lỗi này.

Vì sao bản vá được phát hành sớm hơn kế hoạch?

Đợt cập nhật ban đầu dự kiến vào ngày 22/10, nhưng được đẩy lên 21/10/2026 sau khi mã CVE và thông tin về đợt vá xuất hiện trên mạng ngày 20/10. Quá trình nghiên cứu có sự tham gia của nhiều bên; Wiz báo cáo các phát hiện từ ngày 24/8 và sử dụng AI hỗ trợ phân tích, kiểm chứng. Với mình, đây cũng là ví dụ cho thấy AI đang tham gia sâu hơn vào bảo mật, không chỉ giúp viết code mà còn giúp tìm những vấn đề khó nhận ra trong code.

Đến 26/10/2026, CISA đưa cả hai lỗi vào danh mục lỗ hổng đã bị khai thác thực tế, tức KEV. Tuy nhiên, cần phân biệt giữa một lượt thử tấn công và một lần xâm nhập thành công: báo cáo của Wiz ngày 27/10 cho thấy nhiều công cụ khai thác công khai chưa hoàn thành được toàn bộ chuỗi tấn công trong môi trường họ theo dõi. Điều này không làm mất đi yêu cầu cập nhật, nhưng cũng không có nghĩa mọi website chưa vá đều đã bị chiếm quyền.

Cần nâng cấp lên phiên bản PHP nào?

Các phiên bản đầu tiên vá hai lỗi này là PHP 8.2.35, 8.3.36, 8.4.27 và 8.5.12, tương ứng với từng nhánh. Chẳng hạn, website đang dùng PHP 8.3 cần bản 8.3.36 hoặc bản mới hơn có chứa bản vá, không nhất thiết phải chuyển ngay sang PHP 8.5. Với gói PHP do hệ điều hành cung cấp, bản sửa có thể được đưa ngược về phiên bản đang duy trì, nên cần kiểm tra thông báo của nhà cung cấp thay vì chỉ nhìn số phiên bản chung.

Người dùng WordPress có thể xem phiên bản tại Công cụ → Sức khỏe website → Thông tin → Máy chủ. Nếu dùng shared hosting, mình sẽ gửi yêu cầu hỗ trợ với câu hỏi cụ thể: “PHP đang chạy website của mình đã được vá CVE-2026-109618 và CVE-2026-109619 chưa?”. Việc cập nhật diễn ra ở phía máy chủ, vì vậy không phải cứ bấm cập nhật trong WordPress là hoàn tất. Trước khi thay đổi môi trường PHP, nên có bản sao lưu và kiểm tra khả năng tương thích của website.

Với VPS hoặc máy chủ tự quản lý, cần kiểm tra toàn bộ môi trường PHP đang chạy, ưu tiên hệ thống tiếp nhận truy cập Internet, cập nhật rồi khởi động lại các dịch vụ và tiến trình PHP liên quan. PHP 8.1 trở xuống đã hết hỗ trợ phát hành chính thức; những hệ thống này cần bản vá phù hợp được nhà cung cấp xác nhận hoặc chuyển sang nhánh còn hỗ trợ. Không nên mặc định rằng một website dùng PHP cũ nhưng vẫn hoạt động bình thường thì không cần xử lý.

Có Cloudflare hay plugin bảo mật rồi vẫn phải vá

Cloudflare đã triển khai quy tắc bảo vệ trước các hướng khai thác PHP2Shell, nhưng chính hãng cũng yêu cầu khách hàng cập nhật PHP. Tường lửa có thể giúp giảm rủi ro trong lúc chờ xử lý, chứ không sửa được lỗi nằm bên trong PHP. Mình cũng không xem việc đã cài plugin bảo mật là lý do để trì hoãn: với đường tấn công xảy ra trước code ứng dụng, lớp bảo vệ bên trong website không phải lúc nào cũng có cơ hội can thiệp.

Một lưu ý bổ sung là ngày 23/10, PHP công bố lỗi riêng CVE-2026-115560, chưa được sửa trong đợt cập nhật 21/10 và chỉ xuất hiện với tổ hợp cấu hình đặc biệt. PHP khuyến nghị tạm tắt tính năng theo dõi tiến trình tải lên trên hệ thống liên quan. Khi nhờ hosting kiểm tra, nên yêu cầu họ rà soát cả cảnh báo này, không chỉ xác nhận đã cài bốn phiên bản vá ban đầu.

Vá xong chưa có nghĩa đã xử lý hết mọi chuyện

Bản vá ngăn đường khai thác, nhưng không tự gỡ mã độc đã được cài trước đó. Vì vậy, bên cạnh cập nhật, người quản trị cần kiểm tra nhật ký hoạt động và dấu hiệu xâm nhập, đặc biệt nếu máy chủ từng mở ra Internet trong thời gian chưa được bảo vệ. Những biểu hiện như tiến trình PHP chạy lệnh hệ thống bất thường hoặc tải công cụ lạ cần được kỹ thuật viên kiểm tra, thay vì chỉ quét một lần rồi kết luận an toàn.

Với mình, bài học từ PHP2Shell là bảo mật website không dừng ở phần nhìn thấy trong trang quản trị. Người mới không cần hiểu hết cách PHP quản lý bộ nhớ, nhưng nên biết ai đang chịu trách nhiệm cập nhật môi trường phía dưới. Hỏi hosting một câu cụ thể, xác nhận bản vá đã thực sự được áp dụng và kiểm tra dấu hiệu bất thường là hướng xử lý thiết thực hơn việc chỉ lo lắng hoặc chờ website gặp sự cố mới bắt đầu quan tâm.