PHP2Shell: Website sử dụng PHP 7.4, 8.0 và 8.1 cần làm gì ngay? 

PHP2Shell là gì? Mức độ nguy hiểm ra sao? 

PHP2Shell bao gồm hai mã định danh CVE-2026-109618 và CVE-2026-109619, cả hai đều được xếp hạng cực kỳ nghiêm trọng với điểm CVSS v4.0 đạt 9.2/10. 

Khi người dùng truy cập website, bộ máy PHP sẽ xử lý mã ứng dụng để tạo nội dung trả về trình duyệt. Do lỗi nằm ngay trong khâu xử lý này, một website dù có bộ code ứng dụng sạch vẫn có thể bị tấn công. Cụ thể: 

• CVE-2026-109618 (RCE qua lỗi cạn kiệt bộ nhớ): Liên quan đến cách PHP xử lý tình huống hết bộ nhớ. Khi tiến trình bị dừng đột ngột, bước dọn dẹp dữ liệu của PHP sử dụng sai các vùng nhớ không hợp lệ, dẫn đến hỏng bộ nhớ. 

• CVE-2026-109619 (RCE qua trạng thái lưu đọng): Khi vùng nhớ bị giải phóng, các trạng thái lỗi không bị xóa đi. Các yêu cầu tiếp theo gửi đến cùng một tiến trình PHP có thể sử dụng lại trạng thái độc hại này, tạo điều kiện cho hacker chiếm quyền thực thi lệnh (RCE). 

Sự can thiệp của AI trong việc phát hiện lỗi: Theo Wiz, PHP từ 5.4 trở lên đã tồn tại tiềm ẩn ít nhất một điểm yếu trong nhóm này, nhưng đến tháng 8/2026, nhóm nghiên cứu tại Calif phối hợp cùng OpenAI và Wiz, mới sử dụng AI để phân tích mã và tạo ra các kịch bản khai thác thành công. 

Ngày 21/10/2026, PHP phát hành các bản cập nhật bảo mật cho PHP 8.2, 8.3, 8.4 và 8.5. PHP 7.4, 8.0 và 8.1 đã hết vòng đời hỗ trợ (End-of-Life – EOL) và không có bản sửa chính thức từ dự án PHP. Doanh nghiệp đang sử dụng các phiên bản này cần kiểm tra với nhà cung cấp hosting hoặc phần mềm để xác nhận có gói đã vá hoặc bản backport hay không, đồng thời lên kế hoạch nâng cấp lên phiên bản PHP còn được hỗ trợ. 

Những website nào có thể bị ảnh hưởng 

Bất kỳ hệ thống nào dùng PHP chưa được vá để xử lý web request đều có nguy cơ, bao gồm: 

• Các nền tảng phổ biến: WordPress, Drupal, Joomla, MediaWiki hoặc các web app tự phát triển. 

• Môi trường máy chủ: PHP-FPM, php-cgi, FrankenPHP, LiteSpeed và đặc biệt là Apache (mod_php) – cấu hình được PHP cảnh báo có rủi ro cao nhất. 

• Lưu ý: Ngay cả khi website của bạn không có form upload file vẫn cần được kiểm tra. Với Apache mod_php, CVE-2026-109618 có thể bị kích hoạt bởi một yêu cầu chưa xác thực, ngay trước khi mã ứng dụng kịp chạy. PHP-FPM, php-cgi, FrankenPHP và LiteSpeed cũng nằm trong diện bị ảnh hưởng, nên các cấu hình này vẫn cần được vá. 

Hậu quả nếu bị khai thác: Kẻ tấn công có thể chạy mã độc với quyền của tiến trình PHP, cho phép chúng: 

• Đánh cắp dữ liệu nhạy cảm (mật khẩu, token, khóa API) từ bộ nhớ tiến trình. 

• Sửa đổi nội dung website hoặc cấy mã độc (backdoor). 

• Gây gián đoạn giao dịch, ảnh hưởng nặng nề đến uy tín và tài chính của doanh nghiệp. 

Ba bước kiểm tra xem website có bị ảnh hưởng không 

Giao diện website hoạt động bình thường không đồng nghĩa với việc hệ thống của bạn an toàn. Hãy phối hợp với đội ngũ IT hoặc nhà cung cấp hosting thực hiện ngay 3 bước sau: 

Bước 1: Xác định chính xác phiên bản PHP đang sử dụng 

• Với WordPress: Vào Công cụ → Sức khỏe website → Thông tin → Máy chủ để xem nhanh phiên bản PHP. 

• Với Hosting/VPS: Kiểm tra qua bảng điều khiển (cPanel, DirectAdmin) hoặc dùng lệnh php -v (lưu ý lệnh này chỉ hiển thị bản CLI, cần đối chiếu thêm với dịch vụ web như PHP-FPM đang chạy). Đừng quên kiểm tra các subdomain hoặc môi trường test. 

Bước 2: Đối chiếu bản vá (Patch & Backport) 

Chỉ nhìn vào số phiên bản (ví dụ PHP 8.3) là chưa đủ. Bạn cần chắc chắn hệ thống đang chạy bản đã fix lỗi: 

• PHP 8.5: Cập nhật lên 8.5.12 

• PHP 8.4: Cập nhật lên 8.4.27 

• PHP 8.3: Cập nhật lên 8.3.36 

• PHP 8.2: Cập nhật lên 8.2.35 (Sắp hết hỗ trợ vào 31/12/2026). 

Nếu dùng các gói PHP do hệ điều hành phân phối (như Ubuntu, Debian, RHEL, AlmaLinux), hãy yêu cầu hosting xác nhận mã gói (package version) đã bao gồm bản vá ngược (backport) cho CVE-2026-109618 và CVE-2026-109619 chưa, đồng thời đảm bảo các dịch vụ đã được restart sau khi cập nhật. 

Bước 3: Rà soát dấu hiệu bị xâm nhập 

Nếu website từng chạy bản PHP dính lỗi, hãy rà soát log máy chủ (access log, error log), kiểm tra các file bị thay đổi bất thường và rà soát tài khoản quản trị mới. Việc vá lỗi chỉ giúp chặn lỗ hổng, chứ không tự động xóa mã độc nếu server đã bị hacker “ghé thăm” trước đó. 

Các website sử dụng phiên bản PHP (7.4, 8.0, 8.1) cần làm gì ngay lúc này? 

Các nhánh PHP 7.4, 8.0 và 8.1 đã chính thức bị khai tử (End-of-Life) và không còn thường xuyên nhận được các bản vá bảo mật chính thức từ dự án PHP. Nếu hệ thống của bạn đang kẹt ở các phiên bản này, rủi ro là rất lớn. 

Xử lý rủi ro trước mắt 

1. Hỏi nhà cung cấp OS/Hosting về Backport: Một số nhà phân phối Linux (như Ubuntu, Debian) có thể cung cấp các gói vá ngược tự biên dịch cho PHP cũ. Hãy yêu cầu họ xác nhận. 

2. Giảm bề mặt tấn công: Cấu hình lại tường lửa ứng dụng (WAF), chặn các request bất thường, giới hạn IP truy cập vào trang quản trị, hoặc sử dụng VPN nếu đó là hệ thống nội bộ. 

3. Tùy chỉnh thông số: Tạm thời tinh chỉnh giới hạn bộ nhớ và vô hiệu hóa các tính năng không cần thiết theo khuyến cáo khẩn cấp của cộng đồng (Tuyệt đối không tự sửa thông số nếu không hiểu rõ kiến trúc server). 

Lập lộ trình nâng cấp toàn diện (Giải pháp dài hạn) 

Để đảm bảo an toàn và hiệu suất, doanh nghiệp nên lập kế hoạch “chuyển nhà” sang PHP 8.3, 8.4 hoặc 8.5. Quá trình này cần sự cẩn trọng để không làm sập hệ thống: 

1. Kiểm kê & Sao lưu: Đánh giá toàn bộ mã nguồn, plugin, thư viện bên thứ 3 (như cổng thanh toán, CRM). Backup toàn bộ database và source code. 

2. Tạo môi trường Staging: Dựng một môi trường thử nghiệm độc lập. Nâng cấp PHP lên bản đích và sửa các đoạn code không tương thích (Deprecations/Fatal Errors). 

3. Kiểm thử toàn diện (Testing): Test kỹ các luồng sinh doanh thu (đặt hàng, thanh toán, gửi email, đăng nhập) để đảm bảo không có gián đoạn. 

4. Deploy thực tế: Triển khai bản đã sửa lên môi trường thật trong khung giờ thấp điểm, khởi động lại dịch vụ và giám sát chặt chẽ. 

Trường hợp hệ thống dùng một CMS quá cũ, các plugin đã bị bỏ rơi không tương thích với PHP 8.x, doanh nghiệp nên cân nhắc chuyển sang các công nghệ mới hơn. 

Đồng hành cùng Luvina Software – Chuyển đổi và nâng cấp hệ thống an toàn 

Bạn đang lo lắng vì hệ thống của doanh nghiệp vẫn kẹt lại ở PHP 7.4, hay không chắc chắn server của mình đã được vá lỗi PHP2Shell chưa? Việc tự tay can thiệp vào máy chủ hoặc nâng cấp PHP mù quáng có thể làm hỏng toàn bộ tính năng website. 

Đừng để hệ thống trở thành con mồi của tội phạm mạng. Hãy liên hệ với đội ngũ kỹ sư giàu kinh nghiệm tại Luvina Software. Chúng tôi cung cấp dịch vụ đánh giá bảo mật tổng thể, rà soát lỗ hổng, và thiết kế lộ trình nâng cấp (migration) hoặc chuyển đổi kiến trúc hệ thống một cách trơn tru, không gây gián đoạn hoạt động kinh doanh của bạn. 

👉 [Liên hệ Luvina Software ngay hôm nay để được tư vấn nâng cấp website an toàn!] 

Nguồn tham khảo 

Các số trong bài tương ứng với nguồn dưới đây. Thông tin được đối chiếu đến ngày 27/10/2026; cần kiểm tra lại các bản phát hành và khuyến cáo mới trước khi xuất bản hoặc triển khai. 

[1] PHP. Thông báo bảo mật và cập nhật ngày 21, 23 và 26/10/2026 

[2] Wiz Research. PHP2Shell và kết quả thử nghiệm trên ứng dụng PHP 

[3] PHP Security Advisory. CVE-2026-109618 — RCE via OOM corruption 

[4] PHP Security Advisory. CVE-2026-109619 — RCE via stale global state 

[5] Calif Research. PHP2Shell và dòng thời gian phát hiện 

[6] CERT-EU. Security Advisory 2026-018 — Critical Vulnerabilities in PHP 

[7] Canonical Ubuntu. Gói PHP đã vá và hướng dẫn xác minh bản phân phối 

[8] PHP. Vòng đời các phiên bản được hỗ trợ 

[9] WordPress Documentation. Site Health screen 

[10] PHP Manual. Tùy chọn dòng lệnh PHP 

[11] PHP Manual. Các thay đổi không tương thích khi chuyển từ PHP 7.4 lên PHP 8.0 

[12] The PHP Foundation. Quá trình phát hiện và xử lý hai lỗ hổng PHP 

[13] PHP2Shell Research. Phạm vi ảnh hưởng và hướng dẫn cập nhật