Lỗ hổng PHP2Shell bị khai thác hàng triệu lần, AWS phát hiện tấn công trước cả khi công bố

Hai lỗ hổng nghiêm trọng mang tên PHP2Shell đang trở thành tâm điểm của một làn sóng tấn công quy mô lớn, khi kẻ xấu liên tục dội hàng triệu yêu cầu khai thác vào các máy chủ trên toàn cầu. Đặc biệt, dữ liệu từ Amazon cho thấy ai đó đã bắt đầu tấn công từ bốn ngày trước khi thông tin về lỗ hổng được công bố.

Số lượng tấn công tăng vọt sau khi công bố

Cloudflare cho biết đã ghi nhận mức gia tăng chóng mặt của các cuộc tấn công nhắm vào hai lỗ hổng, được theo dõi với mã CVE-2026-109618 và CVE-2026-109619, kể từ khi thông tin chi tiết bắt đầu lan truyền vào đầu tuần này.

Theo Giám đốc điều hành Cloudflare Matthew Prince, công ty đã phát hiện hàng nghìn lần thử khai thác chỉ trong 10 giờ trước khi lỗ hổng được công bố chính thức. Con số này vọt lên hàng chục nghìn chỉ trong vòng 45 phút sau khi công bố, hàng trăm nghìn sau hai giờ, và hiện đã vượt ngưỡng hàng triệu.

Đáng lo ngại hơn, kẻ tấn công không chỉ dùng lại một cách khai thác duy nhất. Cloudflare cho biết đã chứng kiến chúng liên tục điều chỉnh payload để lách qua lớp bảo vệ tường lửa ứng dụng web (WAF), dường như dựa vào phản hồi từ các yêu cầu bị chặn để tìm ra cách vượt qua.

"Hầu hết các cuộc tấn công chúng tôi quan sát được đều lợi dụng đường dẫn xử lý tiến trình tải lên phiên (session upload-progress) của PHP, và chúng tôi dự báo sẽ còn xuất hiện thêm nhiều cách khai thác khác trước và sau khi bản vá được phát hành."

Công ty bảo mật Hadrian cũng đưa ra cảnh báo vào ngày 21/10, khẳng định PHP2Shell đang "bị khai thác trong thực tế với quy mô lớn".

Dấu hiệu tấn công xuất hiện trước khi lỗ hổng được biết đến

Điều khiến giới bảo mật lo ngại nhất là một số kẻ tấn công dường như đã ra tay trước cả khi lỗ hổng được công khai.

Theo Amazon Threat Intelligence, nền tảng này đã phát hiện một nỗ lực khai thác PHP2Shell vào ngày 17/10, tức bốn ngày trước khi bản vá được phát hành. Hoạt động này được ghi nhận bởi MadPot, mạng lưới honeypot của Amazon được thiết kế để thu hút và ghi lại hành vi của kẻ tấn công.

"Trong khi lỗ hổng còn đang trong giai đoạn cấm công bố (embargo), việc một honeypot bị nhắm tới từ một địa chỉ IP ẩn danh cho thấy hành vi đến từ một tác nhân đe dọa, dù vẫn chưa rõ cách tác nhân này có được thông tin khai thác trước khi công bố."

Gã khổng lồ thương mại điện tử và điện toán đám mây cho biết đã phát hiện nhiều bản khai thác thử nghiệm (proof-of-concept) vào ngày 21/10, với bản sớm nhất xuất hiện khoảng 02:00 UTC, tức khoảng 12 giờ trước khi bản vá được phát hành. Trong sáu giờ tiếp theo, nhiều nỗ lực khác tiếp tục đến từ các hạ tầng ẩn danh khác nhau với đa dạng payload. Amazon đánh giá điều này cho thấy có nhiều tác nhân tấn công thay vì chỉ một nhóm duy nhất.

Hiện vẫn chưa rõ liệu những nỗ lực này có thành công trên các hệ thống thực tế hay không.

Bê bối xoay quanh quá trình công bố

Những phát hiện trên càng làm phức tạp thêm một quá trình công bố vốn đã lộn xộn. PHP Foundation đã cáo buộc nhà cung cấp bảo mật chuỗi cung ứng Chainguard đưa các trang web vào vòng nguy hiểm khi công bố bản dựng PHP đã vá trước thời hạn công bố đã thỏa thuận.

Tuy nhiên, việc Amazon phát hiện tấn công từ ngày 17/10 cho thấy ít nhất một kẻ tấn công đã cố khai thác lỗ hổng nhiều ngày trước sự cố đó.

Mức độ nguy hiểm của lỗ hổng

Bản thân hai lỗ hổng này đặc biệt nguy hiểm. Cả hai đều có điểm nghiêm trọng 9,2 và liên quan đến cách PHP xử lý bộ nhớ, có khả năng cho phép kẻ tấn công chưa xác thực thực thi mã độc trên máy chủ bị ảnh hưởng.

Khác với các lỗ hổng trong plugin hay ứng dụng riêng lẻ, những lỗi này ảnh hưởng trực tiếp đến bộ thực thi PHP (runtime), đặt vô số trang web vào vòng nguy hiểm bất kể họ dùng hệ quản trị nội dung nào. Với các doanh nghiệp và nhà phát triển Việt Nam đang vận hành website trên nền PHP, đây là lời cảnh báo cần được xử lý ngay lập tức.

Cloudflare cho biết đã triển khai bảo vệ WAF trên cả gói miễn phí và trả phí, nhưng nhấn mạnh rằng biện pháp này không thể thay thế cho việc vá lỗi.

Khuyến nghị cho quản trị viên

Khi kẻ tấn công đã ra tay trước cả khi bản vá xuất hiện, quản trị viên có thể phải đối mặt với nhiều vấn đề hơn là chỉ chạy đua vá lỗi. Amazon khuyến nghị các tổ chức nên điều tra các hoạt động đáng ngờ từ ít nhất ngày 17/10, thay vì mặc định hệ thống của mình an toàn cho đến khi lỗ hổng được công khai.

• Cập nhật PHP lên phiên bản đã vá ngay khi có thể
• Rà soát log máy chủ từ ngày 17/10 để tìm dấu hiệu bất thường
• Kích hoạt bảo vệ WAF như một lớp phòng thủ bổ sung, không phải thay thế
• Theo dõi các nguồn tin bảo mật để cập nhật diễn biến mới