Bỏ qua đến nội dung chính
Thứ 2 – Thứ 6: 8:00 – 17:30
Tin tức công nghệ

Cảnh báo PHP2Shell: Hướng dẫn vá CVE-2026-109618 và CVE-2026-109619 trên cPanel, Plesk, DirectAdmin, Webuzo

Hai lỗ hổng PHP2Shell CVE-2026-109618 và CVE-2026-109619 có thể dẫn đến thực thi mã từ xa. Hướng dẫn cập nhật, kiểm tra PHP và xử lý trên cPanel, Plesk, DirectAdmin, Webuzo.

22/10/2026 9 phút đọc Kim Trien
Cảnh báo PHP2Shell: Hướng dẫn vá CVE-2026-109618 và CVE-2026-109619 trên cPanel, Plesk, DirectAdmin, Webuzo
Nội dung bài viết
  1. PHP2Shell là gì và ảnh hưởng đến hệ thống nào?
  2. Phiên bản PHP nào đã có bản vá?
  3. Hướng dẫn cập nhật theo từng control panel
  4. 1. cPanel & WHM / EasyApache 4
  5. 2. Plesk
  6. 3. DirectAdmin
  7. 4. Webuzo
  8. 5. Máy chủ Linux tự quản lý hoặc hosting không có panel
  9. Cách kiểm tra PHP CLI và PHP thực tế của website
  10. Nếu chưa thể vá ngay: biện pháp giảm thiểu tạm thời
  11. Kiểm tra dấu hiệu xâm nhập sau khi cập nhật
  12. Checklist dành cho quản trị viên
  13. Nguồn tham khảo chính thức

Hai lỗ hổng PHP2Shell CVE-2026-109618 và CVE-2026-109619 được đánh giá nghiêm trọng, có thể cho phép kẻ tấn công thực thi mã từ xa mà không cần đăng nhập. Bản vá đã được phát hành cho các nhánh PHP được hỗ trợ; quản trị viên cần cập nhật đúng PHP runtime mà website đang sử dụng, kể cả khi máy chủ được quản lý qua cPanel, Plesk, DirectAdmin hoặc Webuzo.

Tóm tắt nhanh

  • Phiên bản đã vá: PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35 trở lên trong từng nhánh.
  • cPanel/WHM: cập nhật hệ thống và gói EasyApache 4; có thể chạy /scripts/rpmup bằng root theo hướng dẫn cPanel.
  • Plesk, DirectAdmin, Webuzo: cập nhật qua công cụ quản lý PHP của panel và xác minh gói/runtime thực tế; không tự thay binary PHP.
  • PHP 8.1 trở xuống cần kiểm tra bản vá backport của nhà cung cấp hoặc lên kế hoạch nâng cấp.
  • Nếu nghi ngờ máy chủ đã bị xâm nhập, chỉ cập nhật PHP là chưa đủ: cần điều tra log, tiến trình, tài khoản và bí mật truy cập.
Minh họa cảnh báo bảo mật PHP2Shell trên máy chủ web
PHP2Shell là cảnh báo bảo mật cần được xử lý ở lớp PHP runtime, không chỉ ở mã nguồn website.

PHP2Shell là gì và ảnh hưởng đến hệ thống nào?

Ngày 21/10/2026, nhóm phát triển PHP phát hành các bản cập nhật khẩn cấp cho hai lỗ hổng CVE-2026-109618 và CVE-2026-109619, mỗi lỗ hổng được đánh giá CVSS v4.0 là 9.2. Theo thông báo chính thức của PHP, các cấu hình phục vụ request web đều cần được xem xét, bao gồm PHP-FPM, Apache mod_php, php-cgi, FrankenPHP và LiteSpeed. Rủi ro được đánh giá cao nhất với mod_php do đường khai thác được chứng minh có thể xảy ra trước khi mã ứng dụng chạy.

  • CVE-2026-109618: lỗi xử lý tình trạng hết bộ nhớ (out-of-memory) trong lúc dữ liệu nội bộ của request chưa được khởi tạo đầy đủ.
  • CVE-2026-109619: trạng thái nội bộ cũ có thể còn được tham chiếu sau khi vùng nhớ của request đã được giải phóng.

Đây là vấn đề trong PHP runtime, không chỉ nằm ở WordPress, Laravel, Drupal hay một plugin cụ thể. Một website đã cập nhật framework vẫn có thể gặp rủi ro nếu PHP đang chạy phía dưới chưa được vá.

Phiên bản PHP nào đã có bản vá?

Nhánh PHPPhiên bản vá đầu tiênHướng xử lý
PHP 8.58.5.12Cập nhật lên 8.5.12 hoặc mới hơn trong nhánh
PHP 8.48.4.27Cập nhật lên 8.4.27 hoặc mới hơn trong nhánh
PHP 8.38.3.36Cập nhật lên 8.3.36 hoặc mới hơn trong nhánh
PHP 8.28.2.35Cập nhật ngay; nhánh 8.2 dự kiến hết hỗ trợ ngày 31/12/2026
PHP 8.1 trở xuốngPhụ thuộc nhà cung cấpKiểm tra bản vá backport được xác nhận hoặc nâng cấp lên nhánh còn hỗ trợ

Lưu ý quan trọng

Số phiên bản có thể được nhà cung cấp hệ điều hành hoặc hosting đóng gói và backport bản vá mà không thay đổi đúng số phiên bản upstream. Với các nhánh PHP cũ, đừng kết luận chỉ dựa trên số phiên bản; hãy kiểm tra thông báo bảo mật của nhà cung cấp và mã gói đã cài.

Hướng dẫn cập nhật theo từng control panel

1. cPanel & WHM / EasyApache 4

  1. Cập nhật cPanel & WHM
    Đăng nhập WHM bằng tài khoản quản trị và chạy cập nhật hệ thống theo quy trình chuẩn của máy chủ.
  2. Cập nhật các gói PHP EasyApache 4
    Với quyền root qua SSH, tài liệu cPanel nêu lệnh cập nhật gói RPM sau:
/scripts/rpmup

Lệnh trên cập nhật các gói RPM do hệ thống quản lý; không chạy nếu chưa kiểm tra chính sách cập nhật của máy chủ. Sau khi hoàn tất, kiểm tra lại các phiên bản ea-php đang được cài và cập nhật mọi nhánh đang phục vụ website.

  1. Kiểm tra trong WHM
    Mở khu vực EasyApache 4 để kiểm tra các phiên bản PHP và gói đã cài. Đảm bảo từng nhánh mà website sử dụng đã nhận bản vá, không chỉ phiên bản CLI mặc định.
  2. Kiểm tra PHP-FPM và website
    Kiểm tra cấu hình PHP-FPM, khởi động lại dịch vụ liên quan nếu bản cập nhật yêu cầu, sau đó xác minh qua HTTP theo mục kiểm tra bên dưới.

Nguồn hướng dẫn nhà cung cấp: Thông báo bảo mật PHP2Shell của cPanel. Phiên bản vá của cPanel/WHM và EasyApache 4 có thể khác nhau; nên theo dõi thông báo chính thức thay vì chỉ cập nhật một gói PHP đơn lẻ.

2. Plesk

  1. Kiểm tra thông báo của Plesk
    Mở Tools & Settings → Updates and Upgrades để kiểm tra cập nhật của Plesk và các thành phần PHP do Plesk cung cấp.
  2. Cập nhật các PHP handler đang sử dụng
    Kiểm tra cả PHP của hệ điều hành lẫn các phiên bản PHP riêng do Plesk quản lý. Mỗi domain có thể được gán handler khác nhau.
  3. Xác minh trước khi kết thúc
    Đối chiếu thông báo bảo mật Plesk để xác nhận gói đã có bản vá. Không giả định rằng cập nhật panel đồng nghĩa tất cả PHP handler đều đã được vá.

Tại thời điểm thông báo Plesk được kiểm tra cho bài viết này, nhà cung cấp cho biết bản sửa lỗi đang được phát triển và sẽ cập nhật hướng dẫn khi gói vá sẵn sàng. Vì trạng thái có thể thay đổi, hãy kiểm tra thông báo mới nhất trước khi thao tác: Thông báo chính thức của Plesk. Nếu chưa có gói vá, hãy liên hệ hỗ trợ Plesk/nhà cung cấp hosting và cân nhắc tạm cô lập website có nguy cơ cao.

3. DirectAdmin

  1. Xác định cách cài PHP
    DirectAdmin thường quản lý PHP thông qua CustomBuild, nhưng cấu hình thực tế có thể khác giữa các máy chủ.
  2. Kiểm tra cập nhật CustomBuild
    Đăng nhập DirectAdmin và mở khu vực CustomBuild/phiên bản phần mềm nếu được cấp quyền. Kiểm tra thông báo từ DirectAdmin và nhà cung cấp hệ điều hành để xác nhận gói PHP có bản vá cho hai CVE này.
  3. Cập nhật và xác minh từng phiên bản
    Áp dụng quy trình cập nhật PHP được tài liệu DirectAdmin/hosting của bạn hướng dẫn; sau đó kiểm tra tất cả PHP version và handler được gán cho domain.

Không dùng lệnh build tùy ý

Không chạy lệnh CustomBuild lấy từ bài hướng dẫn không rõ phiên bản hoặc nhà cung cấp. Tên lệnh và cách cập nhật phụ thuộc cấu hình; nếu chưa chắc, yêu cầu quản trị viên/hosting xác nhận gói đã được vá trước khi build lại PHP.

4. Webuzo

  1. Mở Webuzo Admin Panel
    Đăng nhập bằng tài khoản quản trị và tìm khu vực quản lý PHP/phiên bản PHP (tên mục có thể khác theo phiên bản Webuzo).
  2. Cập nhật PHP qua cơ chế của Webuzo
    Chọn nhánh PHP mà các website đang sử dụng và áp dụng bản cập nhật được Webuzo cung cấp. Nếu phiên bản vá chưa xuất hiện, kiểm tra cập nhật Webuzo hoặc gửi yêu cầu tới nhà cung cấp; không chép đè binary PHP thủ công.
  3. Kiểm tra đường dẫn PHP thực tế
    Nếu máy chủ dùng các đường dẫn như /usr/local/apps/php85/bin/php, hãy kiểm tra đúng binary đó và xác minh PHP handler thực tế của website. Lệnh chạy cron của Webuzo không phải lệnh chuyên biệt để vá PHP.
  4. Khởi động lại đúng dịch vụ nếu cần
    Xác định PHP-FPM/service tương ứng trước khi restart. Không đoán tên service, vì nó có thể khác giữa các bản cài đặt.

Với Webuzo, nếu panel chưa cung cấp bản vá cho nhánh đang chạy, hãy liên hệ nhà cung cấp Webuzo/hosting để hỏi rõ trạng thái bản vá cho CVE-2026-109618 và CVE-2026-109619. Cần xác nhận cả PHP CLI lẫn PHP phục vụ request web.

5. Máy chủ Linux tự quản lý hoặc hosting không có panel

Cập nhật PHP từ kho gói chính thức của bản phân phối hoặc repository mà máy chủ đang sử dụng. Ví dụ, trên hệ thống dùng gói RPM, kiểm tra thông báo bảo mật của nhà cung cấp và cập nhật đúng gói PHP; trên hệ thống dùng APT, áp dụng bản cập nhật từ repository đáng tin cậy. Không trộn repository tùy tiện hoặc tải binary PHP không rõ nguồn gốc.

Nếu dùng shared hosting và không có quyền root, khách hàng thường không thể tự vá PHP lõi. Hãy gửi mã CVE cho nhà cung cấp, yêu cầu xác nhận phiên bản/gói đã vá và thời điểm triển khai. Trong thời gian chờ, giảm mức phơi nhiễm theo hướng dẫn của hosting; không coi việc đổi phiên bản PHP trong giao diện là đủ nếu nhà cung cấp chưa có bản vá.

Cách kiểm tra PHP CLI và PHP thực tế của website

Đầu tiên, qua SSH, kiểm tra PHP mặc định:

php -v
command -v php
php --ini

Nếu có nhiều bản PHP, kiểm tra đúng binary mà panel quản lý, ví dụ với một đường dẫn cụ thể:

/usr/local/apps/php85/bin/php -v

Đây chỉ là kiểm tra CLI. Website có thể chạy một PHP-FPM pool hoặc handler khác. Để xác minh qua HTTP, tạo tạm một file PHP trong document root với nội dung sau:

<?php
header('Content-Type: text/plain; charset=utf-8');
echo 'PHP_VERSION=', PHP_VERSION, PHP_EOL;
echo 'PHP_SAPI=', PHP_SAPI, PHP_EOL;

Truy cập file bằng trình duyệt hoặc curl, đối chiếu phiên bản và SAPI với bản vá tương ứng, rồi xóa file ngay sau khi kiểm tra. Không để lại file chẩn đoán công khai vì nó tiết lộ thông tin môi trường máy chủ. Nếu dùng PHP-FPM, hãy xác minh worker đã chạy lại sau khi cập nhật và cấu hình domain trỏ đến đúng handler.

Nếu chưa thể vá ngay: biện pháp giảm thiểu tạm thời

PHP nhấn mạnh không có biện pháp giảm thiểu nào thay thế hoàn toàn cho cập nhật. Một số cấu hình có thể chặn các đường khai thác đã được xác nhận, nhưng không bảo đảm máy chủ an toàn:

  • Trên PHP 8.5, nhà cung cấp đề cập đặt fatal_error_backtraces=0 để chặn một đường khai thác đã xác nhận của CVE-2026-109619.
  • Nếu ứng dụng không cần tính năng này, có thể đặt session.upload_progress.enabled=0 ở cấu hình PHP áp dụng trước khi request được phân tích, sau đó khởi động lại toàn bộ worker. Không dựa vào ini_set() hoặc .user.ini để áp dụng quá muộn.
  • Giới hạn kích thước request và upload tại web server/proxy khi phù hợp với ứng dụng; đây chỉ là giảm bớt một số bề mặt tấn công.
  • Nếu chưa thể cập nhật máy chủ đang phơi ra Internet, cân nhắc cô lập tạm thời hoặc giới hạn truy cập theo hướng dẫn của đội bảo mật/nhà cung cấp.

Không nhầm biện pháp tạm thời với bản vá

Các thiết lập trên chỉ chặn một số đường khai thác cụ thể. Không tùy tiện đặt memory_limit=-1, giới hạn bộ nhớ hệ điều hành hoặc các tham số khác theo lời khuyên rời rạc như một giải pháp chung; hãy làm theo advisory chính thức và ưu tiên cập nhật gói PHP đã vá.

Kiểm tra dấu hiệu xâm nhập sau khi cập nhật

Vì lỗ hổng có khả năng thực thi mã từ xa, hãy điều tra nếu máy chủ có biểu hiện bất thường, đặc biệt khi PHP đã phơi ra Internet trong thời gian dài. Việc vá lỗi không tự loại bỏ mã độc hoặc tài khoản mà kẻ tấn công có thể đã tạo trước đó.

  • Rà soát access log, error log, log ứng dụng và log xác thực quanh thời điểm bất thường; tìm request lạ, lỗi PHP dồn dập hoặc mẫu truy cập không phù hợp với hoạt động bình thường.
  • Kiểm tra tiến trình con do PHP/web server tạo ra, kết nối outbound bất thường, tài khoản mới, cron job lạ và thay đổi quyền truy cập.
  • Kiểm tra các file mới hoặc bị sửa trong thư mục website, đặc biệt file PHP không rõ nguồn gốc, thư mục upload và thư mục tạm.
  • Nếu có dấu hiệu bị xâm nhập, cô lập máy chủ khi cần, lưu giữ log/bằng chứng, quét và khôi phục từ bản sao lưu sạch; thay mật khẩu, token API, SSH key và các bí mật có thể đã bị lộ.

Checklist dành cho quản trị viên

  • Liệt kê tất cả website, PHP handler, phiên bản CLI và các runtime PHP được đóng gói kèm phần mềm.
  • Cập nhật từng nhánh PHP lên phiên bản đã vá hoặc xác nhận backport chính thức.
  • Kiểm tra trạng thái bản vá của control panel và repository nhà cung cấp.
  • Khởi động lại đúng worker/service khi cần và xác minh qua HTTP.
  • Xóa file chẩn đoán sau khi kiểm tra, theo dõi lỗi ứng dụng sau cập nhật.
  • Rà soát dấu hiệu xâm nhập và thay các thông tin xác thực nếu có nghi ngờ.

Nguồn tham khảo chính thức

Cập nhật nội dung: 22/10/2026. Trạng thái gói vá của control panel có thể thay đổi theo phiên bản và nhà cung cấp; hãy kiểm tra thông báo mới nhất trước khi triển khai trên máy chủ sản xuất.

Đọc tiếp

Bài viết liên quan

Yêu cầu tư vấn

Để lại thông tin, Newnet sẽ liên hệ lại với bạn trong thời gian sớm nhất.