Wiz: Chưa ghi nhận khai thác PHP2Shell thành công, mức độ phơi nhiễm giảm 67%

Tuần trước, đội ngũ Wiz Research đã công bố báo cáo về hai lỗ hổng nghiêm trọng trong PHP (CVE-2026-109618 và CVE-2026-109619), được cộng đồng bảo mật gọi chung là PHP2Shell. Kể từ đó, nhóm nghiên cứu đã theo dõi hoạt động khai thác trên thực tế và rà soát các mã khai thác được công bố công khai.

Báo cáo cập nhật mới nhất đưa ra một kết luận đáng chú ý: chưa có bằng chứng công khai nào về một chuỗi khai thác hoàn chỉnh, hoạt động ổn định trên mục tiêu tùy ý. Dù vậy, một số đối tác đã chia sẻ riêng với Wiz những mã khai thác thành công trên nhiều loại mục tiêu khác nhau, và nhóm nghiên cứu vẫn đang tiếp tục thử nghiệm nội bộ.

Mức độ phơi nhiễm giảm mạnh sau một tuần

Dữ liệu từ hệ thống giám sát của Wiz cho thấy các tổ chức đã phản ứng khá nhanh. Cụ thể:

• Số lượng máy tính kết nối Internet có khả năng bị ảnh hưởng giảm khoảng 67% chỉ trong vài ngày sau khi lỗ hổng được công bố ngày 21/10/2026.
• Tỷ lệ máy chủ còn chạy PHP 7.3 trở về trước — phiên bản không nhận được bản vá chính thức — giảm từ 8,3% xuống 5,7% trong vòng 5 ngày.
• Số tổ chức bị ảnh hưởng nghiêm trọng (có ít nhất một máy chủ vừa phơi nhiễm vừa có lỗ hổng) giảm khoảng 47,9%.

Đáng lưu ý, PHP đang được sử dụng bởi khoảng 65% tổ chức trong tập dữ liệu mà Wiz thu thập. Điều này giải thích vì sao một lỗ hổng trong PHP lại thu hút sự chú ý lớn đến vậy.

Một tuần sau khi công bố, chưa đến 53% số tổ chức ban đầu vẫn còn tồn tại lỗ hổng PHP2Shell.

Wiz lưu ý rằng xu hướng giảm này phản ánh tổng hợp nhiều biện pháp: vá lỗi, nâng cấp phiên bản, loại bỏ máy chủ bị ảnh hưởng và chặn truy cập từ Internet. Báo cáo chưa phân tách được đóng góp của từng biện pháp.

Những gì kẻ tấn công thực sự làm được

Wiz đã dựng honeypot (máy chủ "mồi") để quan sát các cuộc tấn công. Kết quả cho thấy nhiều nhóm đã sao chép các bộ công cụ khai thác mã nguồn mở, nhưng phần lớn thất bại vì lý do kỹ thuật.

Biến thể cũ: chết vì giới hạn kích thước yêu cầu

Một nỗ lực từ địa chỉ 3.37.227[.]134 gửi yêu cầu multipart với 1.005 phần, trong đó có một trường chứa khoảng 12 MB dữ liệu đệm. Mục tiêu là làm cạn kiệt bộ nhớ trong quá trình xử lý session.

Tuy nhiên, yêu cầu đã bị chặn ngay từ đầu vì vượt giới hạn post_max_size 8 MB được cấu hình trên honeypot. Máy chủ ghi log: "POST Content-Length of 12655437 bytes exceeds the limit of 8388608 bytes".

Biến thể mới: cạn kiệt bộ nhớ được, rò rỉ bộ nhớ thì không

Phần lớn địa chỉ IP bị ghi nhận sử dụng chuỗi khai thác mới hơn. Biến thể này tiến xa hơn một bước: giai đoạn đầu liên tục gây cạn kiệt bộ nhớ của PHP, đúng như thiết kế.

Nhưng giai đoạn tiếp theo — rò rỉ bộ nhớ tiến trình để lấy địa chỉ heap và thư viện — đã thất bại trong mọi lần chạy mà Wiz ghi nhận. Trong hầu hết trường hợp, kết nối bị đóng mà không có phản hồi; lần còn lại chỉ trả về một cookie session 32 ký tự bình thường. Không nguồn tấn công nào gửi được giai đoạn khai thác cuối cùng.

Vì sao khai thác thực tế khó hơn tưởng tượng

Báo cáo chỉ ra hai rào cản kỹ thuật lớn khiến việc "sao chép PoC rồi chạy hàng loạt" không đủ để tấn công thành công:

Thứ nhất, bố cục bộ nhớ phụ thuộc vào từng bản build. Bộ công cụ của kẻ tấn công được tính toán cho image chính thức php:8.4.26-apache với giới hạn bộ nhớ 128 MB. Nhưng honeypot Roundcube của Wiz chạy cùng phiên bản PHP từ một bản build khác, có thêm extension và giới hạn 64 MB. Những khác biệt này làm thay đổi cách bộ nhớ được cấp phát và tái sử dụng, khiến bước rò rỉ thất bại.

Thứ hai, việc "ghim" các yêu cầu vào cùng một tiến trình Apache con rất khó. Chuỗi khai thác phụ thuộc vào việc các yêu cầu liên tiếp phải đến đúng cùng một worker trong khi trạng thái session cũ vẫn còn. Timeout, độ trễ mạng và số worker khả dụng đều có thể phá vỡ chuỗi này. Theo Wiz, chính timeout kết hợp độ trễ mạng đã đủ để ngăn chuỗi hoàn tất qua kết nối Internet.

Công cụ mang nhãn PHP2Shell nhưng không liên quan

Wiz cũng phát hiện nhiều công cụ được gắn mác PHP2Shell nhưng thực chất không khai thác hai lỗ hổng trên. Ví dụ, một bản port viết bằng Go nhắm vào "Chain A" sử dụng kỹ thuật đầu độc session lâu đời để ghi mã PHP vào file session, rồi cố gắng thực thi nó thông qua một endpoint có lỗ hổng local file inclusion (LFI).

Vấn đề là endpoint đó — lfi_sink.php — chỉ tồn tại trong môi trường lab của PoC. Nếu mục tiêu không có endpoint tương đương, toàn bộ chuỗi vô hiệu. Wiz không ghi nhận trường hợp thực thi mã thành công nào từ các công cụ này.

Kết luận: rủi ro vẫn còn, đừng chủ quan

Wiz khẳng định họ chưa quan sát được vụ khai thác PHP2Shell end-to-end thành công nào trong dữ liệu của mình. Tuy nhiên, báo cáo công khai của nhà nghiên cứu Adel Karimi — người ghi nhận khai thác, rò rỉ bộ nhớ và thực thi mã trên honeypot của mình — là bằng chứng công khai mạnh nhất cho đến nay. Đáng chú ý, các mục tiêu đó chạy cấu hình Apache mod_php một worker, vốn thuận lợi cho khai thác, nên chưa thể khẳng định độ tin cậy trên các môi trường khác.

Chỉ gây cạn kiệt bộ nhớ là chưa đủ để hoàn tất chuỗi khai thác. Khác biệt về bản build PHP, giới hạn bộ nhớ và hành vi worker đều có thể chặn các giai đoạn tiếp theo.

Theo Wiz, rào cản này sẽ giảm dần theo thời gian khi các nhóm tấn công có chuyên môn xây dựng công cụ ổn định hơn. PHP2Shell vẫn là rủi ro cả ngắn hạn lẫn dài hạn, và việc cập nhật bản vá bảo mật PHP hoặc xử lý theo cách khác vẫn là yêu cầu bắt buộc.

Chỉ dấu xâm nhập (IOC) đáng chú ý

Dưới đây là một số địa chỉ IP mà Wiz ghi nhận có hoạt động liên quan:

• 85.11.187[.]35 — nỗ lực khai thác (21/10)
• 3.37.227[.]134 — nỗ lực khai thác, dùng chuỗi cũ (21/10)
• 103.151.172[.]95 — nỗ lực khai thác (25/10)
• 178.249.214[.]6 — nỗ lực khai thác qua VPN (24/10)
• 31.56.197[.]72 — máy chủ C2 chứa payload (21/10)
• 15.204.59[.]70 và 162.35.99[.]94 — nỗ lực khai thác thất bại (24/10)

Đối với các quản trị viên hệ thống tại Việt Nam đang vận hành ứng dụng PHP, đây là lời nhắc nhở quen thuộc nhưng quan trọng: không nên trì hoãn việc vá lỗi. Kể cả khi chưa có mã khai thác phổ quát, các nhóm có năng lực vẫn có thể tấn công những cấu hình cụ thể, và thời gian chờ đợi càng lâu thì rủi ro càng lớn.