Lỗ hổng PHP2Shell bị khai thác trước khi công bố rộng rãi
Tin tặc đã nhắm vào các lỗ hổng PHP2Shell vài ngày trước khi bản vá chính thức được phát hành, lợi dụng một vụ rò rỉ buộc phải công bố sớm.
Được dịch tự động từ bản gốc tiếng Anh.
Đội ngũ tình báo mối đe dọa của Amazon đã phát hiện các nỗ lực khai thác đang diễn ra nhằm vào cơ sở hạ tầng honeypot của họ từ sớm nhất là ngày 17 tháng 10 năm 2026, nhắm vào các lỗ hổng nghiêm trọng trong lõi PHP được biết đến với tên gọi PHP2Shell. Hoạt động này xảy ra năm ngày trước khi các lỗ hổng được công bố phối hợp rộng rãi, cho thấy các nhóm đe dọa đã có quyền truy cập vào chi tiết khai thác trong khi các bản sửa lỗi vẫn đang trong giai đoạn cấm tiết lộ (embargo).
Chuyện gì đã xảy ra
Các lỗ hổng, được theo dõi dưới mã CVE-2026-109618 và CVE-2026-109619, mang điểm CVSS là 9.2 và cho phép thực thi mã từ xa mà không cần xác thực trước. Các nhà nghiên cứu từ Calif, OpenAI và Wiz đã phát hiện ra những vấn đề này, ảnh hưởng đến mọi phiên bản PHP trong dòng 7.x và 8.x. Quỹ PHP ban đầu dự kiến công bố phối hợp vào ngày 22 tháng 10 năm 2026, lúc 14:00 UTC nhưng đã đẩy lịch phát hành lên sớm hơn một ngày sau khi các bằng chứng khái niệm (proof-of-concept) và định danh CVE bị rò rỉ sớm.
Amazon ghi nhận cuộc thăm dò sớm nhất được biết đến từ một địa chỉ IP liên kết với mạng ẩn danh thương mại, được định vị tại Úc. CJ Moses, Giám đốc An ninh Thông tin (CISO) của Amazon Integrated Security, lưu ý rằng mặc dù chưa rõ cách thức kẻ tấn công thu thập thông tin, việc sử dụng cơ sở hạ tầng ẩn danh gợi ý hoạt động đe dọa có chủ đích thay vì quét vô tình. Sau vụ rò rỉ, nhiều nhóm khác đã tiến hành tấn công sử dụng các payload đa dạng từ các IP ẩn danh khác nhau trong vòng vài giờ sau khi bản vá được phát hành.
Việc phơi bày sớm càng trở nên trầm trọng hơn khi Chainguard công bố các hình ảnh container chứa bản sửa lỗi trước thông báo chính thức. Điều này cho phép tin tặc nghiên cứu sự khác biệt nhị phân (binary diff) và kỹ thuật ngược lại lỗ hổng trong khi hầu hết người dùng vẫn chưa nhận thức được rủi ro. Quỹ PHP đã chỉ trích động thái này, tuyên bố rằng nó phớt lờ nhiều tuần nỗ lực phối hợp và tạo điều kiện cho tin tặc có lợi thế trong việc phát triển các mã khai thác đáng tin cậy.
Cơ chế hoạt động
Những lỗ hổng này nằm trong các hệ thống con quản lý bộ nhớ và xử lý lỗi của PHP, những thành phần xử lý gần như mọi yêu cầu. Vì các lỗ hổng nằm sâu trong lõi runtime, chúng không phụ thuộc vào các hệ thống quản lý nội dung (CMS), framework hoặc plugin cụ thể. Kẻ tấn công có thể kích hoạt thực thi mã từ xa trên bất kỳ endpoint PHP nào có thể tiếp cận được, bao gồm các biểu mẫu tĩnh, trang đăng nhập và kiểm tra sức khỏe (health checks), mà không cần xác thực hoặc đánh cắp phiên.
CrowdStrike nhấn mạnh rằng các cuộc tấn công này để lại rất ít dấu vết kỹ thuật số. Vì khai thác xảy ra trước khi mã ứng dụng được thực thi, nhật ký máy chủ web thường hiển thị các phản hồi HTTP 200 bình thường và các quy trình worker ổn định. Chỉ số tiềm năng duy nhất là lỗi nghiêm trọng giới hạn bộ nhớ (memory-limit fatal error) trong nhật ký lỗi của máy chủ web, điều mà các quản trị viên thường bỏ qua như nhiễu thông thường. Sự thiếu hụt dữ liệu đo lường từ xa (telemetry) hữu ích khiến tường lửa ứng dụng web truyền thống và giám sát nhật ký trở nên kém hiệu quả trong việc phát hiện.
Chi tiết quan trọng
- Các lỗ hổng ảnh hưởng đến tất cả các phiên bản PHP 7.x và 8.x, gây rủi ro cho ước tính khoảng 4,38 triệu dịch vụ hướng ra internet.
- Các nỗ lực khai thác được phát hiện sớm nhất là vào ngày 17 tháng 10 năm 2026, năm ngày trước khi bản vá công khai được phát hành.
- Các cuộc tấn công hầu như không để lại dấu vết trong nhật ký ứng dụng, với chỉ các lỗi bộ nhớ phía máy chủ khó hiểu là chỉ số tiềm năng.
- Hơn 79% các dịch vụ PHP hướng ra internet được phát hiện chạy trên các nhánh không còn hỗ trợ, làm tăng bề mặt tấn công tổng thể.
- Nhiều nhóm đe dọa đã sử dụng các mạng ẩn danh và payload biến đổi để vượt qua các biện pháp bảo vệ an ninh ban đầu.
- Các cơ quan chính phủ bao gồm CISA, NCSC và NSA đã ban hành các cảnh báo khẩn cấp yêu cầu áp dụng bản vá hoặc đưa hệ thống ngoại tuyến.
Tại sao điều này quan trọng
Đối với các kỹ sư phần mềm và trưởng nhóm IT, PHP2Shell đại diện cho một thách thức nghiêm trọng vì nó vượt qua nhiều lớp phòng thủ tiêu chuẩn. Vì lỗ hổng tồn tại ngay trong runtime, việc cập nhật plugin CMS hoặc điều chỉnh cấu hình framework không mang lại sự bảo vệ. Mức độ phổ biến lớn của PHP, vốn cung cấp năng lượng cho gần 70% các trang web, có nghĩa là ngay cả những dịch vụ nhỏ, ít tên tuổi cũng có thể trở thành điểm xâm nhập cho sự xâm phạm mạng rộng hơn nếu chúng chạy các phiên bản PHP dễ bị tổn thương.
Sự cố này cũng làm nổi bật một động thái đang thay đổi trong việc công bố lỗ hổng. Như CJ Moses đã quan sát, phân tích hỗ trợ bởi AI đang rút ngắn thời gian giữa việc phát hành bản vá và mã khai thác hoạt động được. Tin tặc hiện nay có thể nhanh chóng phân tích các khác biệt nhị phân từ các bản phát hành sớm, chẳng hạn như từ Chainguard, để xây dựng vũ khí trước khi phần lớn người dùng áp dụng các bản cập nhật. Điều này làm giảm cửa sổ an toàn truyền thống do công bố phối hợp cung cấp và đòi hỏi các chu kỳ khắc phục nội bộ nhanh hơn.
Bạn có thể làm gì
- Ngay lập tức cập nhật tất cả các instance PHP lên các phiên bản đã vá mới nhất, ưu tiên các máy chủ hướng ra internet.
- Kiểm toán cơ sở hạ tầng của bạn để xác định bất kỳ dịch vụ PHP nào đang chạy trên các nhánh đã ngừng hỗ trợ (end-of-life) như 5.x, 7.4 hoặc 8.1.
- Triển khai các khả năng giám sát quy trình để phát hiện việc khởi chạy shell bất ngờ hoặc tải xuống tệp bởi các worker PHP.
- Xem xét nhật ký lỗi máy chủ web cụ thể tìm kiếm các lỗi nghiêm trọng giới hạn bộ nhớ có thể chỉ ra các nỗ lực khai thác.
- Sử dụng các công cụ như kỹ năng Codex của OpenAI hoặc trình quét đặc thù của nhà cung cấp để kiểm tra các binary cục bộ và trang web xem có lỗ hổng hay không.
- Cân nhắc đưa các dịch vụ PHP không quan trọng ngoại tuyến tạm thời nếu việc vá lỗi ngay lập tức không khả thi do các ràng buộc tương thích.



