Lỗ hổng PHP: bản vá PHP2Shell và cách kiểm tra phiên bản PHP (WordPress)

PHP2Shell là tên gọi của hai lỗ hổng PHP (CVE-2026-109618 · CVE-2026-109619) đã có bản vá vào ngày 21 tháng 10 năm 2026. Đây là các lỗ hổng thực thi mã từ xa, khiến ngay cả một yêu cầu chưa đăng nhập cũng có thể chạy mã trên máy chủ, vì vậy việc đầu tiên là kiểm tra phiên bản PHP mà website của bạn đang dùng và nâng lên bản đã vá. Dưới đây là quá trình kiểm tra phiên bản PHP bằng Tình trạng website trên một máy chủ Nginx + Apache chạy WordPress 7.1.3, chỉ nâng các gói php lên bản đã vá rồi kiểm tra lại.

1️⃣ Lỗ hổng PHP PHP2Shell: nguyên lý và phạm vi ảnh hưởng

Lỗ hổng nằm trong engine PHP, phần đọc yêu cầu trước khi mã WordPress chạy, nên dù bạn luôn cập nhật plugin và giao diện, nó vẫn còn nếu không nâng PHP. Theo cảnh báo của CERT-EU, cả hai đều có điểm CVSS 9,2; chi tiết kỹ thuật đã được công bố và đang được thảo luận, mã proof of concept ban đầu cũng đã bắt đầu lan truyền.

CVE-2026-109618 là lỗ hổng khiến quá trình dọn dẹp coi dữ liệu yêu cầu mới khởi tạo được một nửa là dữ liệu hợp lệ khi yêu cầu vượt giới hạn bộ nhớ (memory_limit) và bị dừng giữa chừng. CVE-2026-109619 là lỗ hổng khiến trạng thái của vùng nhớ đã giải phóng sau lỗi nghiêm trọng (fatal error) vẫn còn lại và bị dùng lại trước khi khởi tạo ở yêu cầu tiếp theo mà cùng worker xử lý.

Theo thông báo của php.net, mọi bản cài đặt PHP xử lý yêu cầu web đều bị ảnh hưởng, trong đó Apache mod_php được xem là cấu hình nguy hiểm nhất. Lý do là trên mod_php đã có bản trình diễn cho thấy chỉ một yêu cầu chưa đăng nhập cũng kích hoạt cuộc tấn công trước khi mã ứng dụng chạy.

Các bản đã sửa là 8.2.35, 8.3.36, 8.4.27 và 8.5.12, và mọi bản thấp hơn trong các dòng 8.2–8.5 đều bị ảnh hưởng. PHP 8.1 trở xuống là các dòng mà dự án PHP đã ngừng hỗ trợ nên không có bản vá chính thức; các dòng này được xử lý bằng bản sửa do bản phân phối và nhà cung cấp hosting đưa vào (backport).

Vào thời điểm CISA ra thông báo ngày 21 tháng 10, chưa có trường hợp khai thác thực tế nào được xác nhận, nhưng CISA đánh giá việc để hệ thống không vá là nguy hiểm và khuyến nghị vá ngay, bắt đầu từ các hệ thống lộ ra Internet. Trong cảnh báo cùng ngày, CERT-EU nhận định rằng khi mã proof of concept bắt đầu lan truyền, khả năng kẻ tấn công đã khai thác các lỗ hổng này cũng tăng lên.

2️⃣ Kiểm tra phiên bản PHP: Tình trạng website › Thông tin › Máy chủ

Dù đã biết về lỗ hổng, bạn vẫn chưa thể quyết định phải làm gì nếu không biết website của mình đang chạy phiên bản PHP nào. Trong trang quản trị, hãy mở [Công cụ › Tình trạng website] rồi mở rộng mục [Máy chủ] trong tab [Thông tin]: dòng [Phiên bản PHP] hiển thị phiên bản PHP thực sự đang xử lý yêu cầu của website.

Dòng [PHP SAPI] ngay dưới [Phiên bản PHP] cho biết cách PHP chạy; fpm-fcgi là cấu hình PHP-FPM. Ở đây chỉ cần xem hai dòng [Phiên bản PHP] và [PHP SAPI] trong mục [Máy chủ].

Cuộc tấn công bắt đầu bằng một yêu cầu chưa đăng nhập. Ở giai đoạn PHP đọc yêu cầu được tạo đặc biệt trước mã WordPress, yêu cầu đó kích hoạt một trong hai lỗ hổng và dẫn tới việc thực thi mã trên máy chủ. Các bản đã sửa chặn luồng này, nên việc cần làm là nâng PHP của website lên bản đã sửa hoặc mới hơn.

[php -v] trong terminal chỉ hiển thị phiên bản PHP mặc định của dòng lệnh. Với các cấu hình cài nhiều phiên bản PHP trên một máy chủ như EA-PHP của cPanel hay alt-php của CloudLinux, phiên bản này có thể khác với phiên bản website đang dùng. Vì vậy, chuẩn để dựa vào là giá trị [Phiên bản PHP] trong Tình trạng website.

php -v

PHP 8.3.xx (cli) (built: Jun  3 2025 17:17:57) (NTS gcc x86_64)

3️⃣ Dưới PHP 8.2: hỏi nhà cung cấp hosting về bản backport, chưa có thì yêu cầu

Nếu [Phiên bản PHP] trong Tình trạng website thấp hơn 8.2 (7.x · 8.0 · 8.1) thì php.net không có bản vá chính thức. Theo bảng các phiên bản được hỗ trợ của php.net (kiểm tra ngày 22 tháng 10 năm 2026), chỉ còn bốn dòng được hỗ trợ là 8.2, 8.3, 8.4 và 8.5, còn các bản chính thức từ 8.1 trở xuống không nhận bản vá bảo mật.

Thay vào đó, bản phân phối và nhà cung cấp hosting đôi khi phát hành các gói giữ nguyên số phiên bản nhưng chỉ đưa bản sửa vào (backport). Các gói 7.4.33 · 8.0.30 · 8.1.34 trên máy chủ thử nghiệm của một dịch vụ hosting được quản lý là một ví dụ. Nhật ký thay đổi của chúng có dòng [Backported from 8.2.35 — CVE-2026-109618, CVE-2026-109619].

Dù số phiên bản giống nhau, vẫn có thể kiểm tra bản sửa đã có hay chưa bằng cách tìm số CVE trong nhật ký thay đổi của gói. Với dòng Debian · Ubuntu, tìm theo dạng [zcat /usr/share/doc/php8.2-cli/changelog.Debian.gz | grep 109618]. Với dòng RPM, dạng lệnh là [rpm -q --changelog php-common | grep 109618]; số phiên bản trong tên gói cần khớp với phiên bản website đang dùng.

Vì vậy, nếu đang dưới 8.2, trước hết hãy hỏi nhà cung cấp hosting xem đã áp dụng backport chưa; nếu chưa hoặc không xác nhận được, hãy yêu cầu nâng lên phiên bản được hỗ trợ (8.2 trở lên). Sau khi nâng, hãy kiểm tra lại giá trị [Phiên bản PHP] trong Tình trạng website.

CISA khuyến nghị các tổ chức dùng 8.1 trở xuống mà chưa thể cập nhật ngay hãy để các hệ thống chạy PHP ở trạng thái ngoại tuyến cho tới khi vá hoặc nâng cấp.

Nếu bạn tự vận hành máy chủ và dùng 8.1 trở xuống, bạn có thể cài các gói backport của bản phân phối hoặc áp dụng bản vá mã nguồn cho 7.4 · 8.0 · 8.1 do đội bảo mật PHP phát hành. Dù vậy, đây là các dòng đã ngừng hỗ trợ, nên cách giải quyết tận gốc là chuyển sang phiên bản được hỗ trợ.

4️⃣ Từ PHP 8.2 trở lên: cập nhật lên bản đã vá rồi kiểm tra lại

Nếu bạn đang ở 8.2 trở lên nhưng thấp hơn bản đã vá, hãy nâng chính PHP. Với hosting được quản lý và shared hosting, nhà cung cấp áp dụng bản vá cho toàn bộ máy chủ, nên hãy xác nhận qua thông báo hoặc bộ phận hỗ trợ xem đã áp dụng chưa và đang dùng bản build nào, rồi xem [Phiên bản PHP] trong Tình trạng website đã thay đổi chưa. Theo thông báo trên trang trạng thái, Cloudways bắt đầu vá mọi phiên bản PHP mà họ hỗ trợ (5.6–8.4) lúc 22:19 UTC ngày 21 tháng 10. Lúc 10:11 UTC ngày 22 tháng 10, Cloudways thông báo đã hoàn tất.

Với máy chủ bạn tự vận hành, hãy nâng cấp bằng các gói trong kho của bản phân phối hoặc nhà cung cấp LTS như thông báo của php.net. Trước khi cập nhật, hãy xem trước danh sách gói sẽ thay đổi để chắc rằng chỉ các gói bắt đầu bằng php được nâng và không có gói nào khác đi kèm, và đừng gộp chung với các bản cập nhật khác của hệ điều hành.

dnf upgrade --assumeno 'php*'

Dependencies resolved.
================================================================================
 Package       Architecture  Version         Repository  Size
================================================================================
Upgrading:
 php           x86_64  8.3.xx-1.…        …       1.9 M
 php-cli       x86_64  8.3.xx-1.…        …       5.6 M
 php-common    x86_64  8.3.xx-1.…        …       1.3 M
 php-fpm       x86_64  8.3.xx-1.…        …       1.9 M
 (đã lược các dòng gói mở rộng như php-gd · php-intl)

Transaction Summary
================================================================================
Upgrade  xx Packages

dnf upgrade 'php*'

Upgraded:
  php-8.3.xx-1.….x86_64
  php-cli-8.3.xx-1.….x86_64
  php-common-8.3.xx-1.….x86_64
  php-fpm-8.3.xx-1.….x86_64
  (đã lược các dòng gói mở rộng)

Complete!

Trong lần đo thực tế này, chỉ các gói bắt đầu bằng php được nâng lên bản đã vá, và php-fpm tự khởi động lại khi việc cài gói kết thúc. Bản đã sửa chỉ có hiệu lực khi các worker php-fpm khởi động lại, nên ở môi trường không có khởi động lại tự động, hãy tự chạy [systemctl restart php-fpm].

Sau khi nâng, hãy xem cả [php -v] và dòng [Phiên bản PHP] ở tab [Thông tin] của Tình trạng website có cùng là bản đã vá trở lên không, rồi kiểm tra cả trạng thái dịch vụ php-fpm và phản hồi của website. Nếu chỉ giá trị ở dòng lệnh thay đổi còn [Phiên bản PHP] vẫn như cũ, hãy khởi động lại php-fpm rồi kiểm tra lại.

Sau khi cập nhật, bạn cũng mở rộng mục [Máy chủ] ở tab [Thông tin] của cùng màn hình [Công cụ › Tình trạng website] rồi xem dòng [Phiên bản PHP]. Nếu giá trị này đã đổi sang phiên bản vừa nâng, nghĩa là các worker php-fpm cũng đang chạy bằng phiên bản mới.

php -v

PHP 8.3.xx (cli) (built: Oct 19 2026 14:00:34) (NTS gcc x86_64)

systemctl is-active php-fpm

active

curl -s -o /dev/null -w '%{http_code}\n' 'https://example.com/?r=1'

200

Với gói mà chính số phiên bản tăng lên, bản vá được xác nhận qua số phiên bản mới; với gói backport giữ nguyên số phiên bản, xác nhận qua số CVE trong nhật ký thay đổi. Máy chủ lần này thuộc loại đầu nên [rpm -q --changelog php-common] không có dòng số CVE, và bản vá được xác nhận qua số phiên bản mới ở dòng đầu tiên của nhật ký thay đổi.

5️⃣ Khi chưa thể nâng cấp ngay: biện pháp tạm thời php.net hướng dẫn

Với các máy chủ chưa thể nâng ngay, php.net hướng dẫn các thiết lập dưới đây như biện pháp tạm thời, đồng thời nói rõ rằng chúng chỉ thu hẹp một số đường tấn công cụ thể chứ không làm cho bản cài đặt an toàn. php.net cũng ghi rằng không nên đặt giới hạn bộ nhớ bằng RLIMIT_AS hay RLIMIT_DATA thay thế, vì điều đó có thể gây ra chính các lỗi cấp phát bộ nhớ dễ bị khai thác.

php_admin_value là thiết lập phía máy chủ mà ứng dụng không đảo ngược được, nên người dùng shared hosting thường không tự thay đổi được và rốt cuộc vẫn phải yêu cầu nhà cung cấp hosting. php.net còn khuyên đặt giới hạn trên, kể cả ở tầng máy chủ web hoặc proxy, cho kích thước phần thân yêu cầu, số trường nhập, số phần multipart, số header và độ sâu lồng nhau.

🔢 FAQ & nội dung đề xuất

🔗 Nội dung đề xuất

Bảo mật Bảo mật WP: bảo mật wp-admin Thiết lập bảo vệ trang quản trị bằng cách đổi địa chỉ đăng nhập, giới hạn số lần đăng nhập và chặn XML-RPC. Xem bài viết →

Bảo mật Lỗ hổng bảo mật wp-config.php Cách ngăn tệp wp-config.php bị lộ và tăng cường thiết lập bảo mật. Bảo mật WordPress XML-RPC Cách nhận biết tấn công xmlrpc.php qua nhật ký và ba cách vô hiệu hóa. Server cảnh báo php-fpm max_children Bài đo thực tế tìm nguyên nhân cảnh báo qua nhật ký trước khi tăng worker.

ℹ️ Thông báo tiếp thị liên kết
Nội dung trên trang này có chứa liên kết affiliate (tiếp thị liên kết). Khi khách truy cập mua sản phẩm hoặc dịch vụ qua các liên kết này, trang sẽ nhận hoa hồng từ bên bán. Trong quá trình đó, số tiền người mua phải trả ^{(sẽ giảm khi có chương trình khuyến mãi ↓)} không hề tăng lên. Giá, khuyến mãi và tình trạng hàng được đăng theo thời điểm viết bài và có thể khác với thực tế, vì vậy hãy kiểm tra lại lần cuối với bên bán trước khi mua. Việc chọn và đánh giá sản phẩm dựa trên tiêu chí riêng của trang; việc có nhận hoa hồng hay không không ảnh hưởng đến thứ tự giới thiệu hay nội dung đánh giá.