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 phiê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 phiê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ý.

Thông báo của php.net cho biết 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 phiên bản đã vá là 8.2.35, 8.3.36, 8.4.27 và 8.5.12, và mọi phiên 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ó phiên 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. Vì lỗi nằm trong engine PHP đọc yêu cầu nên cấu hình này cũng bị ảnh hưởng, và thông báo của php.net nêu Apache mod_php là cấu hình nguy hiểm nhất. Ở đâ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 phiên bản đã vá chặn luồng này, nên việc cần làm là nâng PHP của website lên phiên bản đã vá 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)

Trên máy chủ không vào được trang quản trị, hãy tìm phiên bản website đang dùng từ các tiến trình PHP-FPM đang chạy để xử lý yêu cầu web. Với gói của Debian · Ubuntu, số phiên bản nằm trong đường dẫn tệp cấu hình mà tiến trình master của FPM đã đọc; dưới đây là kết quả kiểm tra trên một máy chủ thử nghiệm Debian 12 của một nhà cung cấp hosting được quản lý.

ps -eo user,args | grep '[p]hp-fpm'

root     php-fpm: master process (/etc/php/8.2/fpm/php-fpm.conf)
abcdefg+ php-fpm: pool abcdefghij-82
klmnopq+ php-fpm: pool klmnopqrst-82

Số 8.2 trong đường dẫn cấu hình là phiên bản PHP mà website dùng trên máy chủ này, và nhà cung cấp hosting này còn gắn số phiên bản vào cuối tên pool (-82). Tệp mà dịch vụ FPM đang bật đã chạy cũng xem được ở dòng [Main PID] của [systemctl status], và vẫn hiện dù không dùng tài khoản root.

systemctl status php8.2-fpm --no-pager | head -6

● php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.2-fpm.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-10-22 07:14:57 UTC; 7h ago
       Docs: man:php-fpm8.2(8)
    Process: <PID> ExecStartPost=/usr/lib/php/php-fpm-socket-helper install /run/php/php-fpm.sock /etc/php/8.2/fpm/pool.d/www.conf 82 (code=exited, status=0/SUCCESS)
   Main PID: <PID> (php-fpm8.2)

Với gói mặc định của các bản phân phối dòng RHEL như AlmaLinux, đường dẫn cấu hình của master là /etc/php-fpm.conf nên không thấy số phiên bản; khi đó, hãy kiểm tra phiên bản của gói FPM bằng [rpm -qf /usr/sbin/php-fpm].

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ó phiên 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 phiên bản chính thức từ 8.1 trở xuống không nhận bản vá bảo mật.

Dòng 8.2 kết thúc hỗ trợ bảo mật vào ngày 31 tháng 12 năm 2026, nên nếu nâng cấp bây giờ, hãy chọn 8.3 trở lên.

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; nếu có dòng hiện ra thì gói đó đã có bản sửa. Với dòng Debian · Ubuntu, hãy tìm như bên dưới, và số phiên bản trong đường dẫn cần khớp với phiên bản website đang dùng.

zcat /usr/share/doc/php8.2-cli/changelog.Debian.gz | grep 109618

   + (CVE-2026-109618, CVE-2026-109619): Avoid state corruption via

Với dòng RPM, hãy tìm bằng lệnh bên dưới.

rpm -q --changelog php-common | grep 109618

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ợ. 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 phiê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 phiê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. Cloudways cho biết trong thông báo trên trang trạng thái rằng lúc 22:19 UTC ngày 21 tháng 10 họ đang áp dụng bản vá cho PHP 5.6 · 7.4 · 8.0–8.4, và lúc 10:11 UTC ngày 22 tháng 10 đã cho biết việc áp dụng 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 phiên bản đã vá, và php-fpm tự khởi động lại khi việc cài gói kết thúc. Phiên bản đã vá 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à phiên 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.

Thiết lập session.upload_progress.enabled trong bảng đã được khuyến nghị thêm một lần nữa trong thông tin của php.net ngày 23 tháng 10. Để chặn cả đường thực thi mã từ xa có khả năng thấp (CVE-2026-115560), php.net khuyên giữ giá trị này ở 0 cho đến phiên bản sửa lỗi định kỳ tiếp theo. Thiết lập này đã có trong khuyến cáo GHSA-6wmf-4rv5-p3rp ngày 21 tháng 10 dưới dạng biện pháp giảm thiểu, nên nếu bạn đã áp dụng từ lúc đó thì cứ để nguyên.

Đường này chỉ xuất hiện khi một ứng dụng đặt session.serialize_handler là php_binary hoặc php_serialize trong cấu hình lại đổi nó thành php bằng ini_set() trước session_start(), và tính năng tiến trình tải lên của phiên cũng đang bật. Nếu chỉ xét đường của CVE-2026-115560, php.net cho biết các ứng dụng không đổi phương thức tuần tự hóa trong lúc chạy có thể tiếp tục dùng tính năng này ở trạng thái bật.

🔢 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á.