PHP2Shell: Từ dò quét đến vỏ lệnh thực sự — bằng chứng khai thác thành công đầu tiên

Các lỗ hổng nghiêm trọng PHP2Shell (CVE-2026-109618 và CVE-2026-109619) cho phép thực thi mã từ xa không cần xác thực đã chính thức bị khai thác thành công trên các máy chủ honeypot. Ngày 24/10, một nhà nghiên cứu ghi nhận 35 vỏ lệnh (shell) được khởi chạy từ hai địa chỉ IP. Đây là lần đầu tiên giới bảo mật xác nhận được thực thi mã trong thực tế, chứ không chỉ là các nỗ lực dò quét hay làm sập tiến trình.

Mã khai thác PHP2Shell

Bối cảnh: Lỗ hổng và cuộc đua vá lỗi

PHP đã phát hành bản vá cho PHP2Shell vào ngày 21/10, sau khi một phần thông tin về lỗ hổng bị rò rỉ trực tuyến. Thế nhưng, các nỗ lực khai thác đã bắt đầu từ trước đó, và số lượng ghi nhận được lên tới hàng triệu lượt kể từ thời điểm rò rỉ.

Trước báo cáo mới nhất, các công ty bảo mật mới chỉ xác nhận được việc kẻ tấn công gây lỗi tràn bộ nhớ (out-of-memory) và làm sập tiến trình xử lý. Một số nhóm nghiên cứu đã phát triển được mã khai thác vượt qua cơ chế bảo vệ ASLR (ngẫu nhiên hóa bố cục bộ nhớ), nhưng chưa ai chứng minh được khả năng chạy lệnh thực sự trên hệ thống mục tiêu.

Chuỗi khai thác bốn giai đoạn

Nhà nghiên cứu Adel Karimi của Perplexity vận hành các honeypot giả lập trang PHP thông thường, chạy PHP 8.4.26 trên Apache mod_php với cấu hình một worker duy nhất. Báo cáo đầu tiên của ông, bao phủ hơn 26 giờ hoạt động, ghi nhận 30 lỗi tràn bộ nhớ và 11 lần tiến trình bị sập — nhưng chưa có thực thi mã.

Bước ngoặt đến vào ngày 24/10, khi các cảm biến ghi nhận 35 vỏ lệnh được khởi chạy trên ba honeypot. Một địa chỉ IP tạo ra 3 shell trên một honeypot, trong khi địa chỉ còn lại tạo ra 32 shell trên cả ba máy.

Kẻ tấn công sử dụng một chuỗi bốn giai đoạn gồm các yêu cầu HTTP:

• Giai đoạn đầu: các yêu cầu làm cạn kiệt bộ nhớ của PHP
• Giai đoạn hai: rò rỉ nội dung bộ nhớ để thu thập thông tin
• Giai đoạn ba: tinh chỉnh dữ liệu rò rỉ cho phù hợp
• Giai đoạn cuối: thực thi lệnh shell

Lưu lượng này khớp chặt chẽ với một mã khai thác PoC công khai, và hoạt động được cho là tương ứng với việc khai thác CVE-2026-109618. Karimi viết trên X: "Đây giờ đã là RCE được xác nhận, kèm theo khả năng rò rỉ bộ nhớ dùng được — không chỉ là một lần sập tiến trình rồi xuất hiện một tiến trình đáng ngờ."

Đáng chú ý, không có tải trọng (payload) giai đoạn hai nào được tải xuống — tức là kẻ tấn công chưa triển khai mã độc tiếp theo sau khi có shell.

Cần đọc kết quả một cách thận trọng

Chính Karimi cũng cảnh báo không nên suy diễn quá xa từ kết quả này:

"Bằng chứng thể hiện chuỗi khai thác này trên một cấu hình mod_php một worker vốn được thiết lập có lợi cho việc khai thác; đây không phải là thước đo độ tin cậy của khai thác trên các mức worker khác, các bản dựng PHP khác hay các ứng dụng khác."

Marcus Hutchins, nhà nghiên cứu mối đe dọa chính của Expel, đánh giá đây là "bằng chứng có chất lượng cao nhất về việc khai thác PHP2Shell trong thực tế mà tôi từng thấy cho đến nay."

Nhà nghiên cứu bảo mật

CISA vẫn chưa đưa vào danh mục KEV

Ngày 23/10, CISA cập nhật cảnh báo về PHP2Shell, bổ sung quy tắc phát hiện Sigma, nhưng cho biết vẫn chưa quan sát được khai thác thành công. Tính đến sáng ngày 26/10, cơ quan này vẫn chưa thêm các lỗ hổng vào danh mục Known Exploited Vulnerabilities (KEV).

Trước đó, nhóm vận hành botnet Mirai cũng đã tham gia vào các cuộc tấn công PHP2Shell, song hành cùng sự xuất hiện của các mã khai thác vượt ASLR.

Ý nghĩa với doanh nghiệp và quản trị viên Việt Nam

Với các tổ chức và cá nhân vận hành website, API hay hệ thống nội bộ dùng PHP, đây là lời nhắc nhở rõ ràng:

• Ưu tiên nâng cấp PHP phiên bản mới nhất ngay khi có thể, đặc biệt với các hệ thống dùng mod_php trên Apache
• Rà soát log HTTP để tìm các mẫu yêu cầu bất thường gây tràn bộ nhớ hoặc rò rỉ dữ liệu, đặc biệt là các chuỗi bốn giai đoạn giống PoC công khai
• Thiết lập giám sát tiến trình để phát hiện các shell lạ được khởi chạy từ tiến trình web server
• Cân nhắc giảm cấu hình worker hoặc phân tách môi trường nếu đang vận hành các dịch vụ nhạy cảm — cấu hình một worker là điều kiện lý tưởng cho kiểu khai thác này
• Không nên chờ đợi danh mục KEV của CISA; bằng chứng khai thác thực tế đã có đủ để coi đây là rủi ro cấp cao

Sự việc một lần nữa cho thấy khoảng cách ngắn ngủi giữa công bố lỗ hổng và khai thác thực tế. Với các lỗ hổng có sẵn PoC công khai và mô tả kỹ thuật bị rò rỉ từ trước khi vá, việc chậm trễ cập nhật không còn là sự lựa chọn an toàn.