Lỗ hổng PHP2Shell: Doanh nghiệp cần làm gì để bảo vệ website?

Wecanadmin  /  Twitter 29.10.2026

Ngày 21/10/2026, nhóm phát triển PHP phát hành bản vá khẩn cấp cho hai lỗ hổng nghiêm trọng, được cộng đồng bảo mật gọi chung là PHP2Shell. Kẻ tấn công có thể chạy mã độc trên máy chủ chỉ bằng một yêu cầu gửi tới website, không cần tài khoản hay mật khẩu. Theo W3Techs, khoảng 69% website có ngôn ngữ phía máy chủ xác định được đang dùng PHP — trong đó có hầu hết website WordPress của doanh nghiệp Việt Nam.

Vấn đề là nhiều chủ doanh nghiệp không biết website của mình đang chạy PHP phiên bản nào, ai chịu trách nhiệm cập nhật, và đọc các bài phân tích kỹ thuật thì không biết bắt đầu từ đâu. Bài viết dưới đây của Wecan Group giải thích PHP2Shell bằng ngôn ngữ dễ hiểu, giúp bạn tự xác định website có bị ảnh hưởng hay không, nên yêu cầu nhà cung cấp hosting làm gì, và cần chuẩn bị gì trước mốc PHP 8.2 hết hỗ trợ ngày 31/12/2026.

Lưu ý: Thông tin trong bài cập nhật đến ngày 29/10/2026 và mang tính tham khảo. Tình hình lỗ hổng có thể thay đổi; hãy đối chiếu với thông báo chính thức trên php.net và nhà cung cấp hosting của bạn.

1. PHP2Shell là gì?

PHP là ngôn ngữ lập trình chạy trên máy chủ, đứng sau WordPress, WooCommerce và rất nhiều website tự xây dựng. Mỗi khi khách truy cập mở một trang, PHP xử lý yêu cầu đó trước khi website hiển thị nội dung.

PHP2Shell là tên gọi chung của hai lỗ hổng nằm ngay trong lõi PHP, không phải trong giao diện hay plugin:

Nói đơn giản: kẻ tấn công gửi một yêu cầu được tính toán sẵn tới website, khiến PHP rơi vào trạng thái lỗi và chạy đoạn mã của họ. Thao tác này diễn ra trước khi mã của website kịp chạy, nên các lớp bảo vệ trong WordPress như plugin bảo mật hay đăng nhập hai lớp không chặn được.

Các bản vá đã có trong PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35. Thông báo của nhóm PHP ghi rõ: không có biện pháp giảm thiểu hoàn chỉnh, cập nhật là lựa chọn an toàn duy nhất.

2. Vì sao doanh nghiệp không nên chủ quan?

Các mốc chính của sự cố PHP2Shell (nguồn: php.net, Help Net Security, Báo Pháp luật)

• Không cần đăng nhập: kẻ tấn công chỉ cần biết địa chỉ website. Website giới thiệu công ty, không có tính năng tải file, vẫn nằm trong phạm vi ảnh hưởng.
• Đã bị khai thác thực tế: Amazon Threat Intelligence ghi nhận một lần thử khai thác ngày 17/10/2026, bốn ngày trước khi lỗ hổng được công bố. Cloudflare cũng cho biết đã thấy lưu lượng tấn công nhắm vào khách hàng của họ.
• Cập nhật WordPress hay plugin không đủ: Cloudflare nhấn mạnh lỗ hổng nằm trong phần mềm PHP, nên chỉ cập nhật mã nguồn website hay plugin sẽ không khắc phục được. Phải nâng cấp chính PHP trên máy chủ.
• Phiên bản cũ rất phổ biến: theo W3Techs (28/10/2026), 26,6% website dùng PHP vẫn chạy PHP 7 và 7,7% chạy PHP 5. Các nhánh này đã hết hỗ trợ nên không có bản cài đặt sẵn; nhóm PHP chỉ công bố bản vá dạng mã nguồn cho 7.4, 8.0 và 8.1.
• Cơ quan chức năng đã lên tiếng: ngày 22/10, Cục An ninh mạng và Hiệp hội An ninh mạng quốc gia khuyến nghị doanh nghiệp kiểm kê toàn bộ hệ thống chạy PHP, ưu tiên cập nhật và yêu cầu nhà cung cấp hosting xác nhận trạng thái vá.

Hậu quả khi bị khai thác không chỉ là website bị đổi giao diện. Kẻ tấn công có thể đọc cơ sở dữ liệu khách hàng, cài cửa hậu để quay lại sau, chèn link rác làm hỏng SEO, hoặc dùng máy chủ của bạn để tấn công nơi khác.

3. Website của bạn có bị ảnh hưởng không?

Trả lời 3 câu hỏi để biết bước tiếp theo

Trả lời ngắn: nếu website chạy PHP từ 5.4 trở lên và chưa được cập nhật sau ngày 21/10/2026, hãy coi là có. Cách xác định nhanh theo loại hạ tầng:

Bảng phiên bản an toàn tối thiểu:

Một bẫy thường gặp: một số hệ điều hành Linux đưa bản vá vào gói PHP mà không đổi số phiên bản. Vì vậy, số phiên bản thấp hơn bảng trên chưa chắc là chưa vá — nhưng cũng không được tự cho là đã vá. Hãy yêu cầu người quản trị máy chủ xác nhận cụ thể bản vá cho CVE-2026-109618 và CVE-2026-109619.

4. Việc cần làm ngay: quy trình 5 bước

1. Kiểm kê: liệt kê mọi website, landing page, trang con, hệ thống nội bộ chạy PHP (kể cả website cũ không còn dùng nhưng vẫn online). Ghi lại nơi đặt (hosting/VPS) và người quản lý.
2. Sao lưu trước khi đổi: sao lưu toàn bộ mã nguồn và cơ sở dữ liệu, lưu bản sao ra ngoài máy chủ. Nâng cấp PHP có thể làm lỗi plugin cũ.
3. Cập nhật PHP: lên tối thiểu phiên bản đã vá trong bảng ở mục 3, rồi khởi động lại dịch vụ PHP. Nếu đang ở 8.1 trở xuống, ưu tiên chuyển thẳng lên 8.3 hoặc 8.4 thay vì 8.2.
4. Kiểm tra sau cập nhật: mở trang chủ, form liên hệ, giỏ hàng, trang quản trị; xem nhật ký lỗi. Có thể dựa vào checklist test website trước khi vận hành của Wecan Group.
5. Thêm lớp bảo vệ tạm thời: bật tường lửa ứng dụng web (WAF) nếu có. Ngày 23/10/2026, nhóm PHP khuyến nghị thêm đặt upload_progress.enabled=0 đến bản cập nhật kế tiếp để chặn một hướng tấn công liên quan (CVE-2026-115560). Các biện pháp này chỉ giảm rủi ro, không thay thế việc cập nhật.

Mẫu tin nhắn gửi nhà cung cấp hosting hoặc đơn vị bảo trì (sao chép và gửi):

Chào anh/chị, liên quan đến lỗ hổng PHP2Shell (CVE-2026-109618, CVE-2026-109619), nhờ bên mình xác nhận giúp website [tên miền]: (1) đang chạy PHP phiên bản nào; (2) đã được vá hai lỗ hổng trên chưa, vá ngày nào; (3) dịch vụ PHP đã khởi động lại sau khi vá chưa; (4) có ghi nhận truy cập bất thường từ ngày 17/10/2026 đến nay không. Xin cảm ơn.

5. Nếu nghi website đã bị xâm nhập

Vá lỗ hổng chỉ đóng cửa lại; nếu kẻ tấn công đã vào trước đó, cửa hậu vẫn còn. Các dấu hiệu nên kiểm tra:

• File PHP lạ xuất hiện, nhất là trong thư mục tải lên (wp-content/uploads).
• Tài khoản quản trị mới mà không ai tạo.
• Website chuyển hướng sang trang lạ, Google hiển thị tiêu đề cờ bạc hoặc thuốc.
• Tiến trình PHP sập bất thường, lỗi hết bộ nhớ lặp lại trong nhật ký.

Khi nghi ngờ, hãy giữ nguyên nhật ký máy chủ, đổi toàn bộ mật khẩu (quản trị, cơ sở dữ liệu, FTP, khóa API), rồi nhờ chuyên gia rà soát. Một số mã độc trên WordPress có khả năng tự tái tạo từ nhiều vị trí, nên xóa lẻ từng file thường không đủ.

Về pháp lý, nếu website lưu dữ liệu khách hàng, Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 (hiệu lực từ 01/01/2026) yêu cầu thông báo cho cơ quan chuyên trách chậm nhất 72 giờ kể từ khi phát hiện vi phạm thuộc các trường hợp luật quy định. Xem thêm checklist bảo vệ dữ liệu cá nhân trên website. Nội dung pháp lý ở đây mang tính tham khảo; hãy hỏi ý kiến luật sư cho trường hợp cụ thể.

6. Sau PHP2Shell: nâng cấp PHP trước ngày 31/12/2026

PHP 8.2 hết hỗ trợ bảo mật ngày 31/12/2026 (nguồn: php.net)

PHP 8.2.35 đã vá PHP2Shell, nhưng theo php.net, nhánh 8.2 hết hỗ trợ bảo mật ngày 31/12/2026. Sau mốc này, nếu xuất hiện lỗ hổng mới, website chạy 8.2 sẽ không có bản vá chính thức — đúng tình cảnh của các website PHP 7 hay 8.1 hôm nay.

Vì vậy, đợt vá khẩn là dịp tốt để lên kế hoạch nâng cấp:

• Kiểm tra giao diện và plugin có hỗ trợ PHP 8.3/8.4 không; thay plugin đã bị bỏ rơi.
• Thử nâng cấp trên bản sao (staging) trước, không thử trực tiếp trên website đang bán hàng.
• Chọn khung giờ ít truy cập để chuyển, chuẩn bị phương án quay lại nếu lỗi.
• Đưa việc theo dõi phiên bản PHP vào hợp đồng bảo trì website doanh nghiệp sau bàn giao, để không phải chạy theo từng sự cố.

Nếu website quá cũ (ví dụ còn chạy PHP 5 hoặc dùng mã nguồn không còn ai bảo trì), chi phí nâng cấp có thể gần bằng làm mới. Khi đó, hãy cân nhắc thiết kế lại trên nền tảng được hỗ trợ dài hạn.

7. Checklist bảo vệ website PHP cho doanh nghiệp

Lưu lại checklist để rà soát định kỳ

• Biết rõ mọi website của công ty đang đặt ở đâu, ai quản lý
• Biết phiên bản PHP đang chạy của từng website
• Đã có xác nhận bằng văn bản về bản vá PHP2Shell
• Có bản sao lưu mã nguồn và cơ sở dữ liệu lưu ngoài máy chủ, đã thử khôi phục
• WordPress, giao diện, plugin được cập nhật định kỳ; gỡ plugin không dùng
• Bật WAF và đăng nhập hai lớp cho tài khoản quản trị
• Kiểm tra tài khoản quản trị và file lạ trong thư mục tải lên
• Có kế hoạch rời PHP 8.2 trước 31/12/2026
• Có quy trình xử lý sự cố và đầu mối liên hệ khẩn

Một số câu hỏi thường gặp

Website WordPress của tôi đã cập nhật hết plugin, có còn bị ảnh hưởng không? Có, nếu PHP trên máy chủ chưa được vá. Lỗ hổng nằm trong PHP, không nằm trong WordPress hay plugin.

Website không có chức năng tải file lên thì có an toàn không? Không. Kẻ tấn công chỉ cần gửi yêu cầu tới website; tính năng tải file không phải điều kiện.

Dùng Cloudflare hoặc WAF rồi có cần vá không? Vẫn cần. Cloudflare đã triển khai luật chặn nhưng chính họ khuyến nghị vá PHP càng sớm càng tốt; WAF chỉ là lớp bổ sung.

Website đang chạy PHP 7.4 thì sao? Nhánh 7.4 không còn bản cài đặt chính thức. Cách an toàn là nâng cấp lên 8.3 trở lên sau khi kiểm tra tương thích; trong lúc chờ, hỏi nhà cung cấp hosting về bản vá họ tự đưa vào (backport).

Nếu dữ liệu khách hàng bị lộ thì doanh nghiệp có trách nhiệm gì? Theo Luật Bảo vệ dữ liệu cá nhân 2025, một số vi phạm phải được thông báo cho cơ quan chuyên trách trong 72 giờ. Tham khảo thêm bài website chuẩn Luật Bảo vệ Dữ liệu Cá nhân.

Wecan Group – Dịch vụ bảo trì và chăm sóc website doanh nghiệp

PHP2Shell cho thấy website không phải làm xong là xong: nền tảng bên dưới cần được theo dõi và cập nhật liên tục. Wecan Group cung cấp dịch vụ chăm sóc website doanh nghiệp, hỗ trợ kiểm tra phiên bản PHP, sao lưu, nâng cấp và rà soát bảo mật cho website WordPress.

Nếu bạn chưa chắc website của mình đã an toàn trước PHP2Shell, hoặc cần kế hoạch rời PHP 8.2 trước cuối năm, hãy liên hệ Wecan Group để được tư vấn.