Tóm tắt khẩn cấp: Nếu website của bạn chạy PHP — WordPress, Laravel, WooCommerce hay code tự viết — hãy kiểm tra phiên bản PHP ngay hôm nay. Một chuỗi lỗ hổng nghiêm trọng tên PHP2Shell vừa được công bố, cho phép hacker chiếm quyền điều khiển server từ xa mà không cần tài khoản đăng nhập, không cần ai bấm vào bất cứ thứ gì. Nhóm phát triển PHP đã phát hành bản vá khẩn cấp ngày 21/10/2026. Nếu server chưa nâng cấp lên một trong các bản an toàn 8.2.35, 8.3.36, 8.4.27 hoặc 8.5.12 thì nó đang trong vùng nguy hiểm — hoạt động quét tìm máy chủ chưa vá đã bắt đầu.

  • Lỗ hổng: chuỗi khai thác 2 lỗi an toàn bộ nhớ trong engine PHP — CVE-2026-109618 và CVE-2026-109619, điểm CVSS v4 là 9.2/10.
  • Ảnh hưởng: mọi website PHP chưa vá, trên mọi cơ chế chạy (FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed).
  • Xử lý triệt để duy nhất: nâng cấp PHP lên bản đã vá và khởi động lại tiến trình PHP.
  • WAF, plugin bảo mật, tắt upload progress: chỉ giảm thiểu tạm thời, không thay thế được bản vá.

PHP2Shell là gì?

PHP2Shell là tên nhóm nghiên cứu bảo mật Calif đặt cho chuỗi khai thác gồm hai lỗ hổng an toàn bộ nhớ nằm trong chính mã nguồn PHP — ngôn ngữ chạy phía server của khoảng 70% website có ngôn ngữ server-side được biết tới, theo W3Techs. Quá trình phát hiện và báo cáo có sự tham gia của Calif, Wiz, OpenAI và Quarkslab, trong đó việc rà soát mã nguồn có sự hỗ trợ của các công cụ AI.

Đáng lo ở chỗ đoạn mã chứa lỗi đã tồn tại từ PHP 5.4.0 — tức từ năm 2012 — và chỉ mới bị phát hiện vào tháng 10/2026. Vì lỗi nằm ở tầng engine, lớp xử lý request trước cả khi mã nguồn website chạy, nên không theme hay plugin nào của website tự bảo vệ được. Đây là rủi ro phải xử lý ở cấp độ server, như các nguyên tắc nền tảng khi bảo mật website.

Hai CVE trong chuỗi PHP2Shell khác nhau thế nào?

Cả hai lỗ hổng đều thuộc dạng truy cập con trỏ chưa khởi tạo (CWE-824) và use-after-free, gắn với cơ chế longjmp mà PHP dùng khi gặp lỗi hết bộ nhớ (OOM) hoặc lỗi nghiêm trọng (fatal error). Nhóm an toàn của PHP chấm cả hai ở mức CVSS v4 9.2 — nhóm nghiêm trọng nhất (thông tin rò rỉ ban đầu từng ghi 10.0 trước khi hiệu chỉnh).

CVE-2026-109618 — lỗi qua cơ chế upload progress

Lỗ hổng thứ nhất (GHSA-w8hw-w9fx-j79w) nằm ở thành phần giải mã (unserializer) của cơ chế theo dõi tiến trình tải file (upload progress). Chỉ cần một HTTP request dạng multipart được chế tác khéo, kẻ tấn công đã kích hoạt được lỗi mà không cần đăng nhập hay tương tác từ người dùng. Ngoài thực thi mã từ xa (RCE) để chiếm server, lỗi này còn cho phép rò rỉ nội dung bộ nhớ server qua cookie PHPSESSID — được giới nghiên cứu ví như Heartbleed — với dữ liệu có thể lộ gồm mật khẩu database, token phiên đăng nhập và khóa riêng TLS.

CVE-2026-109619 — lỗi qua backtrace của fatal error

Lỗ hổng thứ hai (GHSA-6wmf-4rv5-p3rp) đi qua đường xử lý backtrace khi PHP gặp fatal error, kèm yếu tố nhầm lẫn kiểu dữ liệu (type confusion) liên quan đến OPcache. Kết hợp với cơ chế longjmp, kẻ tấn công có thể làm sai lệch luồng thực thi và chiếm quyền điều khiển tiến trình PHP.

Website nào bị ảnh hưởng bởi PHP2Shell?

Câu trả lời ngắn gọn: mọi website chạy PHP chưa được vá.

  • Mọi cơ chế chạy PHP (SAPI) đều bị ảnh hưởng: PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed.
  • Mọi nền tảng: WordPress, WooCommerce, Joomla, Drupal, Laravel, Magento hay PHP thuần — vì lỗi nằm ở tầng engine, trước khi ứng dụng chạy.
  • Cập nhật WordPress, theme, plugin KHÔNG sửa được lỗi này; plugin bảo mật cũng không chặn được khai thác ở tầng xử lý request.
  • PHP 8.1 trở xuống không có bản phát hành chính thức: chỉ có backport mã nguồn tối thiểu cho 7.4, 8.0, 8.1; bản 7.3 trở xuống không còn được hỗ trợ. Một số bản phân phối Linux LTS có gói vá riêng.

Nếu website vẫn chạy PHP 7.x hoặc 8.0/8.1 "vì đang ổn định", PHP2Shell là lý do đủ mạnh để nâng cấp lên ưu tiên số một.

Mức độ nguy hiểm và diễn biến khai thác thực tế

Đây là kịch bản xấu nhất cho một lỗ hổng web: điểm 9.2, khai thác từ xa, không cần xác thực, không cần tương tác. Diễn biến thực tế đang leo thang nhanh:

  • Theo Amazon, hoạt động thăm dò và khai thác thử đã xuất hiện từ 17/10/2026 — trước cả ngày có bản vá — và tăng lên quanh 21/10.
  • Nhóm watchTowr cho biết đã tái hiện thành công CVE-2026-109618 trong môi trường kiểm chứng.
  • Đã ghi nhận dấu vết quét tự động với User-Agent chứa "php2shell-scan", "php2shell-poc"; từng có video PoC xuất hiện rồi bị gỡ.
  • Tính đến 22/10/2026, CISA chưa đưa hai CVE này vào danh mục lỗ hổng bị khai thác tích cực (KEV).

Đánh giá cân bằng: đã có dấu hiệu quét và khai thác thử, cửa sổ an toàn còn lại rất ngắn. Vá ngay ở giai đoạn "thăm dò" là cách rẻ nhất để tránh thành nạn nhân khi đợt quét diện rộng bắt đầu.

Kiểm tra phiên bản PHP trên server để biết có bị ảnh hưởng bởi PHP2Shell

Cách kiểm tra server của bạn có bị ảnh hưởng không

Kiểm tra chỉ mất vài phút, nhưng cần rà mọi nơi có PHP đang chạy, không chỉ website chính:

  1. Bằng dòng lệnh (chính xác nhất): SSH vào server, chạy php -v. Nếu phiên bản thấp hơn bản an toàn của nhánh đang dùng (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12) thì server chưa an toàn. Server chạy nhiều phiên bản PHP song song cần kiểm tra từng phiên bản.
  2. Bằng file phpinfo: tạo file PHP chứa hàm phpinfo, tải lên hosting, mở qua trình duyệt để xem phiên bản — và xóa ngay sau khi xem, vì để quên file này là phơi bày toàn bộ cấu hình server. Có thể tra cứu thêm bằng công cụ PHP trực tuyến.
  3. Trong panel hosting: với cPanel/DirectAdmin, vào mục "PHP Version" hoặc "Select PHP Version" để xem phiên bản của từng tên miền.
  4. Rà toàn hệ thống: subdomain, môi trường staging, script chạy qua cron và cả thiết bị nhúng hay máy nội bộ có chạy PHP — hacker chỉ cần một điểm chưa vá.

Cách vá lỗ hổng PHP2Shell theo từng môi trường

Nhóm PHP khẳng định nâng cấp lên bản đã vá là cách xử lý triệt để duy nhất. Các bản an toàn phát hành khẩn cấp ngày 21/10/2026: PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12.

Shared hosting

Bạn không tự nâng cấp được engine — việc này thuộc nhà cung cấp. Hãy kiểm tra trong panel: nếu đã có bản an toàn, chuyển website sang bản đó rồi kiểm tra lại tính năng. Nếu nhà cung cấp chưa có bản vá, gửi yêu cầu hỗ trợ hỏi rõ lịch cập nhật; phản ứng chậm với lỗ hổng mức 9.2 cũng là tín hiệu để cân nhắc chuyển hosting.

VPS và máy chủ cloud

Nâng cấp qua trình quản lý gói của hệ điều hành hoặc kho phần mềm đang dùng (kho chính thức của distro, ondrej/php trên Ubuntu, Remi trên RHEL/CentOS...). Điểm hay bị quên nhất: sau khi nâng cấp phải khởi động lại PHP-FPM hoặc các worker. Không restart, tiến trình cũ vẫn chạy mã chưa vá trong bộ nhớ và server vẫn bị khai thác như chưa từng cập nhật. Xong xuôi, chạy lại php -v và mở thử website để xác nhận.

Môi trường Docker

Cập nhật image nền lên tag chứa bản PHP đã vá, build lại và triển khai lại container. Rà cả các image cũ trong pipeline CI/CD và môi trường staging để không nơi nào tiếp tục chạy bản lỗi.

Server chạy distro cũ hoặc PHP đời cũ

Trước tiên kiểm tra gói vá riêng của bản phân phối LTS — nhiều distro backport bản vá cho cả PHP 7.4/8.0/8.1. Nếu không có, lựa chọn còn lại là áp backport mã nguồn tối thiểu của nhóm PHP (cần người có chuyên môn) hoặc tốt nhất là nâng cấp thẳng lên PHP 8.2 trở lên. Với PHP 7.3 trở xuống, không còn bất kỳ hỗ trợ nào. Đây cũng là lúc nên cân nhắc dịch vụ quản trị server chuyên nghiệp để việc vá lỗi định kỳ bài bản hơn.

Nếu chưa vá ngay được thì làm gì?

Trong lúc chờ kiểm thử tương thích để nâng cấp, các biện pháp sau chỉ giảm thiểu tạm thời:

  • Bật WAF: Cloudflare đã kích hoạt sẵn rule chặn cho lỗ hổng này trên mọi gói, kể cả miễn phí. Tuy vậy payload biến thể có thể lách qua — WAF không thay thế bản vá. Hệ thống hay bị nhắm tới nên kết hợp thêm lớp chống DDoS và bảo vệ tầng mạng.
  • Tắt session.upload_progress: theo cảnh báo của nhóm PHP, cách này không vá triệt để — đừng coi là giải pháp thay thế nâng cấp.
  • Thu hẹp bề mặt tấn công: giới hạn truy cập khu vực không cần thiết, theo dõi log sát hơn và đặt lịch vá cụ thể trong 24–72 giờ thay vì trì hoãn vô hạn.

Nâng cấp PHP lên bản đã vá và khởi động lại PHP-FPM để xử lý PHP2Shell

Kiểm tra dấu hiệu đã bị xâm nhập và quy trình xử lý

Vì hoạt động quét xuất hiện từ trước ngày có bản vá, hãy kiểm tra thêm dấu hiệu xâm nhập (IoC):

  • File .php lạ trong thư mục uploads, webroot hoặc thư mục vốn chỉ chứa ảnh/tài liệu.
  • File tên dạng php2shell-probe-*.php hoặc php2shell-probe-*.txt.
  • Log truy cập có POST dạng multipart bất thường tới index.php, hoặc User-Agent chứa "php2shell".
  • Tiến trình lạ, cron job lạ, tài khoản quản trị mới không rõ nguồn gốc.

Nếu nghi đã bị chiếm, đừng vội xóa file lạ rồi vá như không có chuyện gì. Quy trình đúng thứ tự:

  1. Cách ly server, giữ nguyên trạng thái để điều tra.
  2. Chụp snapshot và sao lưu toàn bộ log trước khi dọn dẹp.
  3. Dựng lại từ bản sạch đã kiểm chứng, thay vì cố quét sạch trên nền đã bị chiếm.
  4. Đổi toàn bộ mật khẩu database, khóa API và chứng chỉ TLS — vì lỗ hổng có khả năng rò rỉ bộ nhớ, mọi bí mật từng nằm trong bộ nhớ đều phải coi như đã lộ.
  5. Cuối cùng mới nâng cấp PHP lên bản đã vá trên hệ thống sạch và vận hành trở lại.

Các bước dọn dẹp và phục hồi chi tiết có thể tham khảo thêm ở hướng dẫn khắc phục website bị hack.

Câu hỏi thường gặp về PHP2Shell

Website WordPress của tôi có bị ảnh hưởng không?

Có. WordPress chạy bằng PHP nên thừa hưởng toàn bộ rủi ro của engine — việc cần làm nằm ở phiên bản PHP của hosting/server.

Đã bật Cloudflare và plugin bảo mật thì an toàn chưa?

Chưa hoàn toàn. Cloudflare đã có rule chặn ở mọi gói, nhưng payload biến thể vẫn có thể lách WAF, còn plugin không can thiệp được vào tầng engine. Cả hai chỉ là giảm thiểu tạm thời.

Tắt session.upload_progress có vá được không?

Không. Theo nhóm PHP, cách này không xử lý triệt để chuỗi lỗ hổng, nhất là CVE-2026-109619 đi qua đường khác. Đừng để cảm giác "đã làm gì đó" khiến bạn trì hoãn nâng cấp thật.

Tôi vẫn dùng PHP 8.1 thì phải làm sao?

PHP 8.1 không có bản vá chính thức — chỉ có backport mã nguồn tối thiểu và gói vá riêng của vài distro LTS. Phương án bền vững là nâng cấp lên 8.2.35 trở lên, sau khi kiểm thử trên staging.

Vá xong có bắt buộc restart PHP không?

Có. PHP-FPM và các worker vẫn giữ mã cũ trong bộ nhớ cho tới khi khởi động lại. Nhiều trường hợp "đã cập nhật vẫn bị khai thác" bắt nguồn từ việc quên bước này.

Kết luận

PHP2Shell là một trong những lỗ hổng PHP nghiêm trọng nhất nhiều năm qua, nhưng cách xử lý lại rất rõ ràng: kiểm tra phiên bản, nâng cấp lên 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, restart tiến trình PHP, rồi rà dấu hiệu xâm nhập. Làm hôm nay là đóng cửa trước đợt quét diện rộng; trì hoãn có thể đổi lấy cả một cuộc điều tra và dựng lại hệ thống.

Nếu không có đội ngũ kỹ thuật riêng, hãy để Dũng Virgo hỗ trợ qua dịch vụ quản trị server và bảo mật — kiểm tra phiên bản, nâng cấp, vá lỗi khẩn cấp và giám sát định kỳ. Liên hệ tư vấn miễn phí qua Zalo/điện thoại 0352 638 636 hoặc trang liên hệ.