Amazon phát hiện lỗ hổng PHP2Shell bị khai thác trước khi công bố chính thức

Amazon mới đây công bố rằng hệ thống tình báo mối đe dọa của hãng (Amazon Threat Intelligence) đã phát hiện một nỗ lực khai thác lỗ hổng mang tên PHP2Shell từ ngày 17/10/2026 — sớm hơn bốn ngày so với thời điểm công bố công khai hai mã lỗi CVE-2026-109618 và CVE-2026-109619.

Lỗ hổng bị khai thác khi vẫn đang trong giai đoạn cấm công bố

Theo Amazon, nỗ lực khai thác nói trên xuất phát từ một địa chỉ IP thuộc mạng ẩn danh hóa thương mại và nhắm vào MadPot, mạng honeypot nội bộ của hãng. Thời điểm đó, lỗ hổng vẫn đang nằm trong giai đoạn embargo (cấm công bố thông tin) và dự kiến được gỡ bỏ vào 14h00 UTC ngày 21/10/2026.

Việc một honeypot bị nhắm tới từ IP ẩn danh cho thấy đây nhiều khả năng là hành vi của một tác nhân tấn công thực sự. Tuy vậy, Amazon cho biết vẫn chưa rõ tác nhân này có được thông tin khai thác bằng cách nào trước khi lỗ hổng được công bố.

Đến ngày gỡ embargo, đơn vị này ghi nhận nhiều bản khai thác thử nghiệm (proof-of-concept) xuất hiện, sớm nhất vào khoảng 02h00 UTC ngày 21/10. Từ 02h00 đến 08h00 UTC cùng ngày, thêm nhiều nỗ lực khai thác PHP2Shell nhắm vào MadPot được phát hiện, đến từ các hạ tầng ẩn danh khác nhau. Payload và cách thức ẩn danh khác biệt cho thấy đây là nhiều nhóm tấn công riêng biệt.

Bài học vượt ra ngoài một lỗ hổng cụ thể

Sau khi bản vá chính thức được phát hành lúc 14h00 UTC, các bản khai thác thử nghiệm mới tiếp tục xuất hiện chỉ trong vài giờ và nhanh chóng được dùng để tấn công hệ thống cảm biến của Amazon. Hiện PHP2Shell đã bị khai thác rộng rãi trên Internet.

Amazon rút ra hai bài học có giá trị với mọi lỗ hổng, không riêng gì PHP2Shell:

• Cơ chế embargo chỉ bảo vệ được đến khi có người khác tìm ra cùng lỗi. Công bố có phối hợp vẫn là mô hình đúng đắn, nhưng các đội phòng thủ không nên mặc định ngày công bố là ngày bị khai thác sớm nhất. Với PHP2Shell, hệ thống có thể đã bị xâm nhập từ trước khi có khuyến cáo.
• Khoảng thời gian từ lúc vá đến lúc có mã khai thác hoạt động đang ngày càng ngắn vì lý do mang tính cấu trúc. Trước đây, hầu hết các vụ khai thác chỉ xuất hiện sau khi có bản proof-of-concept công khai: một số ít nhóm có năng lực tự xây mã khai thác, số còn lại chờ. Sự phụ thuộc này đang yếu dần khi phân tích hỗ trợ bởi AI khiến việc biến một bản diff vá lỗi hay một khuyến cáo thành mã khai thác trở nên rẻ hơn nhiều.

Thời gian từ khi vá đến khi có mã khai thác hoạt động đang rút ngắn vì những lý do mang tính cấu trúc.

Điều này thay đổi giả định của lãnh đạo bảo mật

Amazon khuyến nghị các tổ chức điều chỉnh lại cách vận hành:

• Với lỗ hổng nghiêm trọng trên hệ thống hướng Internet, cần đo thời hạn vá và giảm thiểu theo giờ. Các cam kết SLA 7 ngày hay 30 ngày đang dựa trên một độ trễ không còn tồn tại.
• Bắt đầu điều tra từ thời điểm khai thác sớm nhất được biết, không phải từ ngày công bố. Với PHP2Shell, nên rà soát ít nhất từ ngày 17/10.
• Đầu tư vào các phương thức phát hiện không phụ thuộc chữ ký (signature) cho một CVE cụ thể, bởi lần khai thác đầu tiên thường đến trước khi chữ ký đó ra đời.

Cách AWS bảo vệ khách hàng

AWS triển khai nhiều lớp bảo vệ. Hệ thống tình báo mối đe dọa nội bộ tự động phát hiện và hạn chế các nỗ lực quét độc hại nhắm vào lỗ hổng này. Hãng phân tích hơn 200 tỷ sự kiện mỗi phút và tích hợp dữ liệu tình báo từ mạng honeypot MadPot để nhận diện, chặn các nỗ lực khai thác đã biết theo thời gian thực.

Hành động khuyến nghị ngay lập tức

1. Nâng cấp ngay lên phiên bản PHP đã được vá. Đây là biện pháp khắc phục triệt để duy nhất cho cả hai mã lỗi CVE-2026-109618 và CVE-2026-109619; không có cách xử lý nào chỉ bằng cấu hình đủ để giải quyết cả hai.
2. Với hệ thống chưa thể vá ngay, cân nhắc chặn tải tệp lên dạng multipart — nhưng phải đánh giá tác động với ứng dụng trước khi áp dụng.
3. Tìm các request POST chứa chuỗi PHP_SESSION_UPLOAD_PROGRESS trong phần tải tệp lên của form.
4. Rà soát log máy chủ web để tìm hoạt động đáng ngờ.
5. Kiểm tra hiện tượng chạy tiến trình hoặc sửa đổi tệp bất thường trên máy chủ ứng dụng web.

Chỉ dấu xâm nhập (IOC)

Các địa chỉ IP cần lưu ý:

• 103.216.220.92 — ghi nhận ngày 17/10/2026
• 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188, 95.217.98.37 — ghi nhận ngày 21/10/2026

Amazon lưu ý các IP trên thuộc hạ tầng ẩn danh dùng chung, không dành riêng cho chiến dịch này. Do đó, tổ chức nên điều tra mọi quan sát liên quan đến các địa chỉ này thay vì chặn cứng, tránh ảnh hưởng nhầm tới lưu lượng hợp lệ.

Với các đơn vị đang dùng dịch vụ cloud, việc kết hợp tường lửa ứng dụng web (WAF) để giảm thiểu rủi ro trong lúc chờ vá là hướng đi được AWS khuyến nghị. Trong bối cảnh mã khai thác xuất hiện chỉ vài giờ sau khi có bản vá, việc chủ động rà soát log và cập nhật hạ tầng PHP càng trở nên cấp thiết hơn bao giờ hết.