PHP2Shell là tên gọi chung của hai lỗ hổng nghiêm trọng trong chính PHP: CVE-2026-109618 và CVE-2026-109619. Trong một số điều kiện nhất định, kẻ tấn công có thể gửi yêu cầu được tạo riêng để thực thi mã từ xa mà không cần tài khoản đăng nhập. PHP đã phát hành bản vá vào ngày 21/10/2026; trong lúc đánh giá rủi ro và chuẩn bị cập nhật, một số tổ chức tạm ngừng hoặc hạn chế dịch vụ. Tuy nhiên, cần phân biệt các lượt dò quét, nỗ lực khai thác với những trường hợp đã xác nhận bị xâm nhập.
4
7
18
Hai lỗ hổng này ảnh hưởng đến đâu?
PHP2Shell không phải lỗi của một tiện ích mở rộng hay ứng dụng website cụ thể, mà nằm trong chính PHP — môi trường chạy mã phía máy chủ. Một lỗ hổng liên quan đến cách xử lý tình trạng cạn bộ nhớ; lỗ hổng còn lại liên quan đến trạng thái toàn cục cũ còn sót lại. Trong một số tình huống, yêu cầu được tạo có chủ đích có thể dẫn đến thực thi mã từ xa; một trong hai lỗi cũng có thể làm lộ dữ liệu nhạy cảm trong bộ nhớ tiến trình.
4
11
Một số báo cáo ước tính PHP được dùng trên tới 70% website. Con số này cho thấy nền tảng có độ phổ biến lớn, nhưng không có nghĩa mọi website dùng PHP đều dễ bị tấn công như nhau. Mức độ rủi ro còn phụ thuộc vào phiên bản PHP, cấu hình máy chủ và khả năng tiếp cận đường xử lý có lỗi.
45
46
AI hỗ trợ phát hiện, còn quá trình công bố bị xáo trộn
Các báo cáo ghi nhận công việc phát hiện và xử lý lỗ hổng của các nhà nghiên cứu, cùng các nhóm tại Wiz, Calif và OpenAI; một số bài viết mô tả AI là một phần của quá trình nghiên cứu. Tuy nhiên, thông tin hiện có không xác nhận đầy đủ mọi chi tiết về diễn tiến phát hiện, chẳng hạn câu chuyện cụ thể về việc chuyển từ khai thác WordPress sang Drupal hay phần đóng góp chính xác của từng nhóm đối với mỗi CVE.
14
45
Theo các bài tường thuật, vấn đề xử lý bộ nhớ nền tảng đã được chú ý trước khi khả năng dẫn đến thực thi mã từ xa được chứng minh. Phát hiện một lỗi đáng ngờ không đồng nghĩa với việc đã tìm ra con đường tấn công khả thi — hai việc này cần được phân biệt.
22
38
Chi tiết về lỗ hổng bị rò rỉ trước thời điểm công bố dự kiến, khiến các bên phải đẩy nhanh ứng phó và vá lỗi.
6
23 Sự việc cho thấy khi thời gian công bố, kiểm chứng và triển khai bị rút ngắn, việc ứng phó an ninh có thể nhanh chóng trở thành bài toán vận hành đối với tổ chức.
Bản vá đã có, nhưng số lượt tấn công không cho biết số vụ xâm nhập
Các phiên bản PHP được nêu là đã sửa lỗi vào ngày 21/10 gồm 8.2.35, 8.3.36, 8.4.27 và 8.5.12. Quản trị viên cũng cần xem khuyến cáo của nhà cung cấp hệ điều hành hoặc dịch vụ lưu trữ: một số nhà cung cấp đưa bản sửa vào gói của họ mà không nhất thiết dùng trực tiếp số phiên bản PHP upstream.
4
39
Một số công ty an ninh ghi nhận hoạt động dò quét hoặc nỗ lực khai thác quanh thời điểm công bố; các bài tường thuật liên quan đến Cloudflare cũng cho biết lượng nỗ lực tăng mạnh. Những số liệu này phản ánh yêu cầu hoặc hành vi được một dịch vụ cụ thể quan sát, chứ không xác định có bao nhiêu máy chủ đã bị xâm nhập.
5
36
Các đánh giá về việc khai thác thành công không hoàn toàn giống nhau. BBC cho biết đến ngày 22/10 chưa có báo cáo về khai thác thành công; một khuyến cáo sau đó của Beazley nói đã ghi nhận nhiều nỗ lực nhưng chưa biết có tình trạng khai thác hàng loạt được xác nhận. Sansec cũng điều chỉnh đánh giá, cho rằng khai thác trên diện rộng có vẻ ít khả năng hơn dự đoán ban đầu. Đây đều là nhận định tại thời điểm được đưa ra, và không có nhận định nào khiến máy chủ chưa vá trở nên an toàn.
7
9
18
Vì sao một số dịch vụ phải tạm ngừng?
Một số tổ chức chủ động tắt hoặc hạn chế dịch vụ trong khi rà soát mức độ phơi nhiễm và chuẩn bị cập nhật. Theo tin tức, Chính phủ Anh đã đưa 32 dịch vụ xuống; một công cụ theo dõi trạng thái dịch vụ ghi nhận hơn 100 dịch vụ đăng thông báo gián đoạn, bảo trì hoặc cảnh báo PHP2Shell trước khi bản vá sẵn sàng. Những biện pháp này cho thấy việc vá khẩn cấp có thể gây gián đoạn vận hành, nhưng tự chúng không chứng minh dịch vụ đã bị tấn công.
22
34
Một số bài viết cũng đề cập phản ứng của chính phủ và tổ chức tại các nước khác. Tuy vậy, bằng chứng hiện có không tạo thành danh sách đầy đủ đã được kiểm chứng độc lập về các dịch vụ bị ảnh hưởng, cũng không xác nhận mọi trường hợp ngừng hoạt động được nêu tên đều liên quan đến sự cố này.
20
25
Quản trị viên website nên làm gì?
- Kiểm kê mọi nơi đang chạy PHP. Rà soát máy chủ chính, máy chủ phụ, container và hệ thống trên dịch vụ lưu trữ được quản lý; đừng chỉ kiểm tra website chính.
- Cài bản sửa phù hợp sớm nhất có thể. Dùng phiên bản đã vá hoặc bản backport được nhà cung cấp xác nhận. Sau đó khởi động lại tiến trình hay dịch vụ PHP nếu cần và kiểm tra phiên bản đang chạy. Chỉ cập nhật ứng dụng PHP hoặc tiện ích mở rộng không thay thế việc sửa môi trường PHP.
14
39
- Giảm mức phơi nhiễm nếu chưa thể vá ngay. Tùy mức độ công khai và ảnh hưởng đến hoạt động, cân nhắc giới hạn truy cập hoặc tạm tắt dịch vụ bị ảnh hưởng. Quy tắc mạng hay tường lửa chỉ nên là biện pháp tạm thời, không thay thế bản vá.
- Kiểm tra dấu hiệu xâm nhập. Rà soát nhật ký hệ thống và tìm tệp, tiến trình hoặc tài khoản quản trị bất thường. Nếu nghi ngờ bị xâm nhập, hãy bảo toàn chứng cứ và điều tra; không nên mặc định rằng cài bản vá sẽ xử lý được sự cố đã xảy ra.
- Xác nhận với nhà cung cấp. Doanh nghiệp nhỏ sử dụng dịch vụ lưu trữ hoặc nhà cung cấp dịch vụ quản lý nên yêu cầu xác nhận rõ mọi môi trường PHP mà mình phụ thuộc đã được xử lý.
NSA khuyến nghị ưu tiên cài các bản vá quan trọng và cho biết cơ quan này đang ưu tiên nhận diện những tác nhân có ý định khai thác PHP2Shell. FBI cũng kêu gọi các tổ chức cập nhật các bản cài PHP. Các nguồn hiện có không xác nhận một chỉ thị chung do FBI, NSA và CISA cùng ban hành, yêu cầu mọi tổ chức phải tắt hệ thống nếu chưa thể vá.
17
28
Người dùng cá nhân có thể làm gì?
Hãy cập nhật thiết bị cá nhân, ứng dụng và bộ định tuyến; đồng thời sử dụng xác thực đa yếu tố và mật khẩu riêng, khó đoán cho từng tài khoản. Đây là các biện pháp bảo mật hữu ích, nhưng không thể vá máy chủ PHP của một website — việc đó thuộc trách nhiệm của đơn vị vận hành website hoặc nhà cung cấp dịch vụ lưu trữ.
Bài học thực tế từ PHP2Shell là cần vá lỗi khẩn trương, xác minh bản sửa đã được triển khai và chuẩn bị cho những khoảng thời gian ứng phó ngày càng ngắn. Sự việc đáng lưu tâm vì quá trình nghiên cứu lỗ hổng và nỗ lực khai thác có thể diễn ra nhanh, nhưng không nên đánh đồng số lượt thử tấn công với xâm nhập hàng loạt đã được xác nhận, hay kết luận rằng an ninh web trên toàn cầu đã sụp đổ.