Ngày 21/10/2026, nhóm phát triển PHP công bố bản vá cho hai lỗ hổng nghiêm trọng có thể dẫn đến thực thi mã từ xa trước khi xác thực (pre-authentication RCE): CVE-2026-109618 và CVE-2026-109619. Hai lỗ hổng này thường được cộng đồng gọi chung là PHP2Shell.
Điểm đáng chú ý là hai lỗ hổng phát sinh ngay trong quá trình PHP xử lý request, trước khi mã ứng dụng được thực thi, đặt ra yêu cầu rà soát và cập nhật kịp thời đối với đội ngũ vận hành.
Nhằm hỗ trợ đội ngũ vận hành rà soát nguy cơ, các chuyên gia VNCS Global đã phát triển hai script hỗ trợ kiểm tra phiên bản PHP và nhận diện một số dấu hiệu bất thường trên máy chủ.
Đồng thời, bài viết cũng trình bày cơ chế lỗ hổng ở cấp độ kiến trúc, kết quả thử nghiệm trong môi trường lab và thử nghiệm sử dụng script kiểm tra, giúp đội ngũ kỹ thuật có thêm cơ sở đánh giá và lên kế hoạch cập nhật bản vá. Lưu ý, đây không phải là PoC khai thác lỗ hổng PHP2Shell.
1. Hai lỗ hổng – Hai nguyên nhân – Một hậu quả
Hai lỗ hổng đều liên quan đến cách PHP quản lý bộ nhớ và trạng thái nội bộ trong quá trình xử lý request, nhưng phát sinh từ những nguyên nhân khác nhau.
CVE-2026-109618: Lỗ hổng này có thể dẫn đến thực thi mã từ xa (RCE) khi PHP hết bộ nhớ (Out of Memory – OOM). Cụ thể, nếu việc cấp phát bộ nhớ thất bại khi PHP đang khởi tạo dữ liệu để xử lý request, quá trình xử lý lỗi có thể để lại dữ liệu ở trạng thái chưa hoàn chỉnh hoặc không hợp lệ. Khi quy trình kết thúc request (shutdown) tiếp tục sử dụng dữ liệu đó, lỗi quản lý bộ nhớ có thể tạo điều kiện để kẻ tấn công can thiệp vào luồng thực thi của PHP và thực thi mã tùy ý.
CVE-2026-109619: Lỗ hổng này có thể dẫn đến thực thi mã từ xa (RCE) do PHP sử dụng lại trạng thái toàn cục đã cũ. Cụ thể, sau khi xử lý xong một request và giải phóng vùng nhớ tương ứng, worker – tiến trình xử lý request – vẫn có thể giữ tham chiếu đến dữ liệu trong vùng nhớ đó. Khi request tiếp theo được xử lý, một thao tác xảy ra trước khi quá trình khởi tạo hoàn tất có thể truy cập nhầm tham chiếu cũ này. Theo advisory, nếu bộ nhớ heap được bố trí phù hợp, kẻ tấn công có thể lợi dụng lỗi để thực thi mã tùy ý.
Cả hai CVE đều được chấm điểm CVSS là 9.2/10 và được đánh giá mức độ nguy hiểm nghiêm trọng (Critical). PHP đã phát hành bản sửa lỗi cho các nhánh được hỗ trợ, với các phiên bản gồm 8.2.35, 8.3.36, 8.4.27 và 8.5.12.
Khi rà soát, cần kiểm tra thông tin bản vá của gói PHP do nhà cung cấp hệ điều hành hoặc nền tảng phân phối. Một số nhà cung cấp áp dụng bản vá bằng cách backport – đưa bản sửa lỗi vào phiên bản PHP đang sử dụng mà không nâng lên phiên bản upstream mới. Vì vậy, hệ thống có thể đã được vá dù vẫn hiển thị số phiên bản cũ; cần đối chiếu thêm thông báo bảo mật và lịch sử cập nhật gói để xác định chính xác.
2. Vì sao SAPI và cấu hình worker ảnh hưởng đến khả năng khai thác?
SAPI (Server Application Programming Interface) là giao diện kết nối PHP với môi trường thực thi. Sự khác biệt giữa các SAPI ảnh hưởng đến cách PHP khởi tạo, xử lý và kết thúc request.
Theo khuyến nghị bảo mật chính thức, khả năng khai thác đã được xác nhận trên Apache mod_php. Với cấu hình này, Apache vẫn thực hiện quy trình kết thúc request ngay cả khi quá trình khởi tạo request thất bại. Khi xử lý dữ liệu multipart, chẳng hạn request tải tệp lên, PHP có thể chạm giới hạn bộ nhớ và rơi vào trạng thái hết bộ nhớ (OOM) ngay trong quá trình khởi tạo. Lúc này, quy trình shutdown có thể truy cập dữ liệu chưa được khởi tạo hoàn chỉnh, tạo điều kiện kích hoạt lỗ hổng trước khi mã ứng dụng bắt đầu chạy.
Tuy nhiên, điều đó không có nghĩa mọi hệ thống chạy PHP đều có mức độ phơi nhiễm hoặc khả năng khai thác như nhau.
Khuyến nghị bảo mật phân biệt rõ giữa mod_php và PHP-FPM. Với PHP-FPM, worker thường bị loại bỏ khi quá trình khởi tạo thất bại. Dù vậy, phân tích mã nguồn vẫn cho thấy một số đường xử lý OOM khác có thể khiến trạng thái không hợp lệ được xử lý trong giai đoạn shutdown. Tại thời điểm công bố khuyến nghị bảo mật, chưa có phương thức khai thác hoàn chỉnh nào được chứng minh trên PHP-FPM. Điều này không có nghĩa là hệ thống sử dụng PHP-FPM chắc chắn an toàn. Đội ngũ vận hành vẫn cần cập nhật bản vá từ nhà cung cấp gói PHP, đồng thời xác định chính xác ứng dụng đang chạy qua SAPI nào để đánh giá nguy cơ phù hợp.
Cấu hình “single worker” trong một số PoC có thể khiến người đọc hiểu nhầm rằng lỗ hổng chỉ xuất hiện khi Apache chạy một worker. Trong lab của bài viết, Apache prefork được giới hạn ở một worker để các request ở nhiều giai đoạn của PoC đều được xử lý trong cùng một tiến trình, giúp thử nghiệm dễ tái lập và cho kết quả ổn định hơn. Đây là cách thiết lập riêng của môi trường thử nghiệm, không phải điều kiện bắt buộc để lỗ hổng tồn tại.
Theo khuyến nghị bảo mật của PHP, khả năng khai thác qua HTTP đã được xác nhận trên mod_php với cấu hình prefork nhiều worker thông thường. Vì vậy, sử dụng nhiều worker có thể làm giảm độ ổn định của PoC hoặc tăng số lần thử cần thiết, nhưng không khắc phục lỗ hổng.
3. Thử nghiệm của VNCS Global trong môi trường lab độc lập
Các chuyên gia từ VNCS Global đã thử nghiệm PoC trên container php:8.4.26-apache, một bản thuộc nhánh bị ảnh hưởng theo bảng phiên bản chính thức. Kết quả phản ánh thử nghiệm với image và cấu hình cụ thể, không có nghĩa là mọi bản build PHP bị ảnh hưởng đều cho kết quả giống nhau.
Từ thử nghiệm này, một lưu ý quan trọng là cần kiểm tra đúng môi trường PHP đang phục vụ website. Lệnh php -v trong shell có thể chỉ hiển thị phiên bản PHP CLI, trong khi website chạy bằng Apache mod_php hoặc một pool PHP-FPM khác, sử dụng binary và tệp php.ini riêng. Vì vậy, để đánh giá chính xác, cần xác định phiên bản PHP, SAPI và cấu hình của tiến trình thực sự xử lý request, thay vì chỉ dựa vào kết quả kiểm tra từ CLI. Script kiểm tra được viết để không gửi bất kỳ request nào thăm dò website production hiện hữu. Nó chạy local trong server để kiểm tra phiên bản, điều này giảm thiểu false positive của cuộc tấn công có chủ đích thật sự nếu cùng xảy ra trong thời điểm quét.
4. Script hỗ trợ kiểm tra và rà soát do VNCS Global phát triển
Nhằm hỗ trợ đội ngũ vận hành đánh giá ban đầu, các chuyên gia VNCS Global đã phát triển hai script: php2shell-simple-check.sh và php2shell-advanced-check.sh. Hai công cụ phục vụ các mức độ rà soát khác nhau, từ kiểm tra phiên bản PHP đến tìm kiếm một số dấu hiệu bất thường trên máy chủ.
Script chạy trực tiếp trên máy chủ, lấy thông tin phiên bản từ lệnh php trong PATH và đối chiếu với các mốc phiên bản đã vá. Công cụ phù hợp để rà soát nhanh phiên bản PHP CLI đang được sử dụng.
php2shell-simple-check.sh: Kiểm tra nhanh phiên bản PHP
Tuy nhiên, PHP CLI có thể khác với phiên bản PHP thực sự phục vụ website qua Apache mod_php hoặc PHP-FPM. Script cũng không truy vấn website, không xác định SAPI đang xử lý request và không kiểm tra các bản vá backport của nhà cung cấp hệ điều hành. Vì vậy, kết quả cần được đối chiếu thêm với thông tin gói cài đặt và môi trường chạy ứng dụng trước khi kết luận hệ thống đã được vá hay chưa.
php2shell-advanced-check.sh: Rà soát thêm dấu hiệu bất thường
Bên cạnh kiểm tra phiên bản, script mở rộng phạm vi rà soát sang một số dấu hiệu vận hành, bao gồm tiến trình con đáng ngờ chạy dưới tài khoản web server, kết nối mạng, tệp PHP mới được chỉnh sửa, các mẫu webshell thường gặp và một số cơ chế duy trì truy cập (persistence).
Các kết quả này là đầu mối để điều tra thêm, chưa đủ để khẳng định hệ thống đã bị xâm nhập. Hoạt động hợp lệ có thể bị nhận diện nhầm, trong khi mã độc được làm rối (obfuscation) hoặc sử dụng kỹ thuật khác có thể không bị phát hiện. Tương tự, kết quả “không phát hiện” không đồng nghĩa với việc hệ thống chắc chắn an toàn. Đội ngũ vận hành cần đối chiếu các dấu hiệu được ghi nhận với hoạt động thông thường của máy chủ, từ đó xác định những điểm cần kiểm tra sâu hơn. Phần kiểm tra phiên bản của script này vẫn dựa trên PHP CLI và có cùng giới hạn như bản simple.
Cả hai script đều phục vụ sàng lọc ban đầu, không thực hiện thử nghiệm khai thác và không thay thế việc kiểm tra gói cài đặt, cấu hình web SAPI, log, EDR hay quy trình ứng phó sự cố. Với hệ thống production, nên ưu tiên các bước kiểm tra ít tác động, tránh thay đổi cấu hình chỉ để tái hiện lỗ hổng. Trước khi chạy, đặc biệt khi sử dụng quyền cao, cần đọc mã nguồn và điều chỉnh phạm vi rà soát phù hợp với môi trường thực tế.
Tải xuống công cụ rà soát PHP2Shell.
Video hướng dẫn sử dụng tool rà soát lỗ hổng PHP2Shell
Để được hỗ trợ kiểm tra chuyên sâu, đánh giá nguy cơ và tư vấn phương án xử lý phù hợp, vui lòng liên hệ đội ngũ chuyên gia VNCS Global.
5. Các bước ưu tiên xử lý
Kết quả từ script giúp xác định các hạng mục cần kiểm tra tiếp, nhưng việc xử lý vẫn cần tập trung vào cập nhật bản vá, xác minh môi trường đang chạy và điều tra nếu có dấu hiệu xâm nhập.
- Cập nhật PHP lên phiên bản đã vá. Sử dụng bản cập nhật do PHP hoặc nhà cung cấp hệ điều hành phân phối, sau đó khởi động lại các dịch vụ Apache, PHP-FPM và worker liên quan theo hướng dẫn cập nhật để bản vá có hiệu lực.
- Xác minh bản vá trên môi trường thực sự phục vụ ứng dụng. Kiểm tra để bảo đảm các tiến trình đang chạy đã sử dụng binary mới, đồng thời xác nhận phiên bản và cấu hình qua đúng SAPI xử lý request. Chỉ kiểm tra bằng php -v trong CLI là chưa đủ.
- Áp dụng biện pháp tạm thời nếu chưa thể cập nhật ngay. Giới hạn truy cập tới dịch vụ, thu hẹp các điểm tiếp nhận request không cần thiết và thực hiện biện pháp giảm thiểu theo khuyến nghị của nhà cung cấp. Theo advisory của PHP, các thay đổi cấu hình không phải biện pháp giảm thiểu hoàn chỉnh và không thay thế bản vá.
- Kích hoạt quy trình ứng phó nếu phát hiện dấu hiệu xâm nhập. Cô lập máy chủ theo quy trình của tổ chức, bảo toàn log và bằng chứng trước khi dọn dẹp; đồng thời rà soát tiến trình, tệp bất thường và thay đổi các thông tin xác thực có nguy cơ bị lộ.
Quá trình xử lý chỉ nên được coi là hoàn tất khi bản vá đã có hiệu lực trên các tiến trình phục vụ ứng dụng và những dấu hiệu bất thường, nếu có, đã được điều tra, xử lý.
Kết luận
PHP2Shell cho thấy bảo mật ứng dụng không chỉ phụ thuộc vào mã nguồn. Ngay cả khi không có lỗi injection, ứng dụng vẫn có thể đối mặt với rủi ro nghiêm trọng từ chính PHP runtime hoặc cách web server tích hợp, khởi tạo và kết thúc quá trình xử lý request. Vì vậy, việc đánh giá cần bao quát cả phiên bản PHP, SAPI, cấu hình vận hành và vòng đời của worker.
PoC giúp làm rõ khả năng khai thác và tác động của lỗ hổng trong môi trường thử nghiệm, còn các script kiểm tra hỗ trợ rà soát phiên bản và nhận diện một số dấu hiệu bất thường trên máy chủ. Để xử lý rủi ro, đội ngũ vận hành cần xác định đúng PHP runtime đang phục vụ ứng dụng, áp dụng bản vá phù hợp từ nhà cung cấp và xác minh bản vá đã có hiệu lực sau khi cập nhật, khởi động lại các dịch vụ liên quan.
