PHP2Shell: cập nhật PHP ngay để vá 2 lỗ hổng RCE critical

Ngày 21/10/2026, PHP phát hành bản vá khẩn cấp cho hai lỗ hổng critical trong lõi PHP: CVE-2026-109618 và CVE-2026-109619, được gọi chung là PHP2Shell. Cả hai cho phép thực thi mã từ xa mà không cần đăng nhập, chấm CVSS v4.0 9.2, và ảnh hưởng mọi bản PHP đang phục vụ web: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP và LiteSpeed.

Việc cần làm rất ngắn: lên PHP 8.5.12, 8.4.27, 8.3.36 hoặc 8.2.35 (hoặc gói đã vá của bản phân phối Linux), rồi restart mọi worker PHP.

Bài này giúp bạn kiểm tra server trong 5 phút, cập nhật theo từng môi trường, giảm thiểu tạm thời nếu chưa vá được ngay, và biết dấu hiệu nào cho thấy server đã bị tấn công.

PHP2Shell là gì: hai lỗ hổng trong lõi PHP

Lỗ hổng nằm ở chính PHP, không nằm trong code ứng dụng hay framework. Vì vậy composer update không giúp gì; thứ cần cập nhật là bản PHP đang chạy trên server.

Mã của kẻ tấn công chạy với quyền user của web worker (thường là www-data). Quyền này thường đủ để đọc file .env của ứng dụng, tức là mật khẩu database và các API key nằm trong đó.

PHP báo trước một ngày (20/10/2026) rằng sẽ có bản vá critical, rồi phát hành lúc 14:00 UTC ngày 21/10/2026, tức 21:00 giờ Việt Nam.

Đã bị khai thác chưa?

Các nguồn nói khác nhau, tuỳ thời điểm:

• CISA (cơ quan an ninh mạng Mỹ), cảnh báo ngày 21/10/2026: chưa ghi nhận khai thác vào lúc công bố, nhưng yêu cầu vá ngay, ưu tiên server ra internet.
• watchTowr, cập nhật ngày 22/10/2026: đã thấy lỗ hổng bị khai thác trên mạng honeypot của họ từ ngày 21/10/2026.
• Sansec, cập nhật ngày 22/10/2026: exploit công khai không chạy được với PHP cài mặc định, và khả năng bị khai thác hàng loạt thấp hơn họ dự đoán vào ngày bản vá ra.

Lời khuyên thực tế: hãy coi như server của bạn đang bị quét, và vá trong hôm nay.

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

Theo cách chạy PHP

• Apache mod_php: rủi ro cao nhất. PHP cho biết đã có exploit chạy được bằng một request không cần đăng nhập, trước cả khi code ứng dụng chạy.
• FrankenPHP: advisory đánh giá "likely susceptible", tức khả năng cao bị ảnh hưởng.
• PHP-FPM (Nginx + FPM, cách phổ biến nhất): "plausibly susceptible", có thể bị, chưa có exploit minh hoạ. Vẫn phải vá.
• php-cgi, LiteSpeed: nằm trong danh sách bị ảnh hưởng.
• PHP CLI (cron, queue worker, artisan): không nằm trong danh sách, vì không phục vụ web request. Nhưng CLI thường được cập nhật cùng lúc với các gói PHP khác.

Đừng quên PHP nằm sẵn bên trong nhiều phần mềm khác: WordPress, phpMyAdmin, các hệ thống nội bộ cũ, panel quản trị hosting. CISA khuyên kiểm kê mọi hệ thống có chạy PHP, kể cả khi PHP chỉ là một thành phần.

Theo phiên bản

Riêng PHP 8.5 còn một điểm đáng lo. Hai thiết lập nằm trên đường khai thác đã được xác nhận của CVE-2026-109619 là session.upload_progress.enabled và fatal_error_backtraces đều bật sẵn theo mặc định. Mình đã kiểm tra trên image Docker chính thức php:8.5.12-cli.

Kiểm tra server trong 5 phút

Các lệnh dưới đây chỉ đọc, chạy trên Ubuntu/Debian. RHEL, Rocky, Alma dùng lệnh tương đương ở phần cập nhật.

1. Xem PHP nào đang phục vụ web, không phải PHP trong terminal

php -v chỉ cho biết bản CLI. Server cài nhiều phiên bản song song thì FPM có thể là một bản khác hẳn:

ls /etc/php/
systemctl list-units 'php*-fpm*' --no-legend
php-fpm8.3 -v

Lệnh đầu liệt kê các phiên bản đang cài. Lệnh thứ hai cho biết FPM nào đang chạy. Lệnh thứ ba hỏi đúng phiên bản của FPM 8.3; đổi 8.3 theo kết quả của bạn.

Xem Apache có đang chạy mod_php không:

apache2ctl -M 2>/dev/null | grep -i php

Có dòng chứa php (ví dụ php_module) là bạn đang dùng mod_php, nhóm rủi ro cao nhất.

2. Đừng chỉ nhìn số phiên bản: bẫy backport

Ubuntu và Debian không nâng PHP lên 8.3.36. Họ chép bản vá vào phiên bản đang có và tăng số phiên bản gói. Mình đã thử trên Ubuntu 24.04 với gói đã vá:

$ php-fpm8.3 -v
PHP 8.3.6 (fpm-fcgi) (built: Oct 19 2026 15:16:58)
$ dpkg-query -W php8.3-fpm
php8.3-fpm	8.3.6-0ubuntu0.24.04.13

php -v vẫn in 8.3.6, nhưng gói đã vá. Vì vậy hãy xem phiên bản gói:

dpkg-query -W -f='${Package} ${Version}\n' 'php8.3*'

Hoặc hỏi thẳng changelog của gói xem có nhắc tới CVE không. Kết quả lớn hơn 0 là đã có bản vá:

zgrep -c 'CVE-2026-109618' /usr/share/doc/php8.3-fpm/changelog.Debian.gz

So với bảng dưới (đối chiếu trên trang bảo mật của Ubuntu và Debian ngày 23/10/2026):

3. Server chạy Docker

docker ps --format '{{.Image}}\t{{.Names}}' | grep -i php
docker exec <container> php -v

Image php chính thức trên Docker Hub build từ mã nguồn PHP, nên php -v trong container in đúng số upstream: 8.3.36, 8.4.27… Image do bên khác đóng gói (dựa trên Ubuntu/Debian) thì xem phiên bản gói như mục 2.

Cập nhật theo từng môi trường

Ubuntu/Debian (gói của bản phân phối hoặc PPA ondrej)

sudo apt update
sudo apt-get install --only-upgrade 'php8.3*'

Đổi 8.3 theo phiên bản của bạn. Lệnh chỉ nâng các gói PHP 8.3 đã cài, không cài thêm gói mới. Muốn cập nhật toàn bộ hệ thống thì dùng sudo apt upgrade.

RHEL, Rocky, AlmaLinux (repo Remi)

Ngày 21/10/2026, PHP cảnh báo repo Remi chưa có bản vá. Tới ngày 22/10/2026, Remi đã đưa lên 8.2.35, 8.3.36, 8.4.27 và 8.5.12.

sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm

Dùng Remi dạng Software Collection (ví dụ php83) thì cập nhật 'php83*' và restart service php83-php-fpm.

Docker

Build lại image để kéo bản base mới, rồi chạy lại container:

docker compose build --pull
docker compose up -d

Muốn chắc chắn, ghi rõ phiên bản trong Dockerfile thay vì chỉ ghi nhánh, ví dụ FROM php:8.3.36-fpm.

Hosting dùng chung, cPanel và các panel quản trị

Bạn không tự cập nhật PHP được. Hãy hỏi nhà cung cấp hosting đã cập nhật chưa, và đổi site sang nhánh 8.2 trở lên nếu đang chọn 8.1 hoặc cũ hơn.

Windows

Tải bản build mới trên trang download của php.net.

Đừng quên restart, rồi kiểm tra lại

Cập nhật gói chưa đủ: worker đang chạy vẫn giữ code cũ trong bộ nhớ. Restart từng service có dùng PHP:

sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2

Lệnh thứ hai dành cho Apache mod_php. Sau đó chạy lại phần kiểm tra ở trên. systemctl status php8.3-fpm cho biết service vừa khởi động lại lúc nào, nên dùng để xác nhận worker đã chạy bản mới.

Đang dùng PHP cũ (8.1, 7.4, 7.3…): làm gì?

Đây là nhóm khó nhất, và thường cũng là hệ thống ít ai dám đụng vào: CRM chạy từ năm 2018, trang quản trị viết bằng CodeIgniter, dự án Laravel 5–8 chưa từng nâng cấp. Ba sự thật cần biết trước:

• PHP 7.3, 7.2, 5.6 cũng bị ảnh hưởng. Theo Sansec, lỗi có mặt trong mọi bản PHP chưa vá từ 5.4 trở đi.
• PHP không phát hành bản mới cho 8.1 trở xuống (không có 7.4.34 hay file cài đặt nào), nhưng đội bảo mật của PHP có đưa ra patch chính thức dạng mã nguồn cho 7.4, 8.0 và 8.1. Không có patch cho 7.3.
• Docker image php chính thức của các bản cũ không được build lại. Trên Docker Hub, php:8.1 cập nhật lần cuối ngày 31/12/2025, php:7.4 từ tháng 11/2022, php:7.3 từ tháng 3/2022.

Lộ trình gồm 3 bước: hôm nay chặn, trong tuần tìm bản vá, rồi lên kế hoạch nâng cấp.

Bước 1, ngay hôm nay: đừng để PHP cũ nhận request từ internet

CISA khuyên tạm ngắt các hệ thống PHP 8.1 trở xuống khỏi internet tới khi vá xong. Làm thực tế thì như sau.

Hệ thống nội bộ (trang quản trị, ERP, CRM, công cụ cho nhân viên): chỉ cho phép IP văn phòng hoặc VPN. Request bị chặn ở Nginx không bao giờ tới được PHP, nên lỗ hổng không còn cửa vào:

server {
    # ... cấu hình hiện có ...
    allow 203.0.113.10;   # IP văn phòng hoặc VPN của bạn
    deny  all;
}

Dùng Apache thì trong khối <Directory> của site, thay Require all granted bằng Require ip 203.0.113.10. Để cả hai dòng thì Apache vẫn cho mọi người vào. Không cố định được IP thì bật đăng nhập ngay ở Nginx (auth_basic); request chưa đăng nhập cũng bị chặn trước khi tới PHP.

Site công khai không đóng được: áp dụng các thiết lập ở mục giảm thiểu tạm thời bên dưới (riêng fatal_error_backtraces chỉ có trên PHP 8.5, bản cũ bỏ qua dòng đó), bật WAF nếu có, rồi làm ngay bước 2.

Bước 2, trong tuần: tìm bản vá cho đúng nền tảng

Không có bản vá chính thức không có nghĩa là không có bản vá nào. Các bản phân phối và nhà cung cấp hỗ trợ dài hạn đã backport cho nhiều bản cũ (kiểm tra ngày 23/10/2026):

Cài xong, kiểm tra changelog của gói có nhắc tới CVE-2026-109618 như ở phần kiểm tra phía trên. Không thấy thì hỏi lại nhà cung cấp, đừng mặc định là đã vá.

Riêng PHP 7.3: bản thân 7.3 chỉ còn 3 đường vá: Debian 10 kèm Freexian ELTS, cPanel/CloudLinux (ea-php73), hoặc mua TuxCare hay ZendPHP LTS. Với đa số hệ thống, đường nhanh nhất là lên PHP 7.4:

• Từ 7.3 lên 7.4 là bước nhảy nhỏ nhất, vẫn cùng dòng 7.x, ít thay đổi gây lỗi hơn nhiều so với lên 8.x.
• 7.4 có patch chính thức của PHP, và PPA ondrej đã có gói php7.4 build lại ngày 21/10/2026.
• Laravel 8 chạy được trên 7.4 (composer.json của Laravel 8 yêu cầu "php": "^7.3|^8.0").

Đổi lại, 7.4 vẫn là bản đã hết hỗ trợ: chỉ hai lỗi PHP2Shell được vá. Hãy coi đây là bước chữa cháy, không phải đích đến.

Tự build PHP (Dockerfile riêng, môi trường đặc thù) cho 7.4, 8.0 hoặc 8.1 thì lấy mã từ nhánh patch trên repo chính thức của PHP, rồi build như bình thường với các tham số ./configure bạn vẫn dùng:

git clone --depth 1 --branch PHP-7.4-CVE-2026-109618-109619 https://github.com/php/php-src.git

Nhánh cho 8.0 và 8.1 đặt tên tương tự. Trên nhánh 7.4, patch là commit 712e60f ngày 18/10/2026 của Arnaud Le Blanc, một trong các dev PHP được advisory ghi tên. Patch này chỉ sửa hai lỗi PHP2Shell, không phải nhánh được hỗ trợ trở lại: các lỗ hổng khác phát hiện sau ngày hết hỗ trợ vẫn còn nguyên.

Bước 3: lên kế hoạch nâng cấp

Bản vá cho PHP cũ chỉ mua thêm thời gian. Đích đến nên là PHP 8.3 trở lên: 8.3 có bản vá bảo mật tới 31/12/2027, 8.4 tới 31/12/2028, 8.5 tới 31/12/2029. PHP 8.2 hết hạn ngày 31/12/2026, chỉ nên là bước đệm.

Với Laravel, phiên bản framework quyết định bạn lên được PHP nào:

Ví dụ app Laravel 8 trên PHP 7.3, đi theo 3 nấc:

1. Chữa cháy: lên PHP 7.4 như ở bước 2. Laravel 8 chạy được, code gần như không phải sửa.
2. Qua dòng 8.x: lên PHP 8.1, Laravel 8 vẫn chạy được. Dùng gói đã có backport của Ubuntu 22.04 hoặc PPA ondrej.
3. Về đích: nâng Laravel lên 10 theo upgrade guide từng phiên bản, rồi lên PHP 8.3.

Ba việc giúp ước lượng và giảm rủi ro trước khi nâng:

• Xem package nào đang chặn bạn lên PHP mới:

composer why-not php 8.3

• Quét cú pháp toàn bộ code trên PHP 8.3 bằng Docker, không cần cài gì lên server (đổi thư mục theo dự án của bạn):

docker run --rm -v "$PWD":/app -w /app php:8.3-cli sh -c "find app routes config -name '*.php' -exec php -l {} \; 2>&1 | grep -v '^No syntax errors'"

Không in ra gì nghĩa là không có lỗi cú pháp. Nhưng php -l chỉ bắt lỗi cú pháp: những hàm đã bị gỡ như each() hay create_function() chỉ lộ ra khi code chạy, nên vẫn phải test các luồng chính.

• Chạy song song hai bản PHP: cài php8.3-fpm cạnh bản cũ, rồi chuyển từng site bằng cách đổi socket trong cấu hình Nginx của site đó:

fastcgi_pass unix:/run/php/php8.3-fpm.sock;

Góc nhìn quản lý dự án: thứ làm việc nâng cấp kéo dài thường không phải số dòng code, mà là không có test. Hệ thống cũ chưa có test tự động thì hãy viết test cho các luồng liên quan tới tiền, đơn hàng và đăng nhập trước khi đổi PHP. Phần đó cũng chính là con số nên đưa vào bản ước lượng.

Chưa vá được ngay: giảm thiểu tạm thời

Nói rõ trước: theo PHP, chỉ cập nhật mới là giải pháp đầy đủ. Các thay đổi dưới đây chỉ chặn một số đường tấn công đã biết. CISA còn khuyên nếu chưa cập nhật được, hoặc đang chạy PHP 8.1 trở xuống, thì tạm ngắt hệ thống khỏi internet tới khi vá xong.

Nếu buộc phải giữ server chạy thêm vài giờ, đặt các giá trị sau trong pool FPM (trên Ubuntu là /etc/php/8.3/fpm/pool.d/www.conf). Dùng php_admin_* để ứng dụng không ghi đè được:

php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M

• session.upload_progress.enabled = off chặn đường đã xác nhận của CVE-2026-109619. Phải đặt ở php.ini, pool FPM hoặc cấu hình server; ini_set() và .user.ini không có tác dụng. PHP còn khuyên giữ thiết lập này sau khi vá nếu bạn không dùng tính năng upload progress.
• memory_limit = -1 bỏ điểm hết bộ nhớ mà kẻ tấn công điều khiển được (CVE-2026-109618). Đổi lại, một script lỗi có thể ăn hết RAM, nên hãy đặt giới hạn bộ nhớ ở mức container hoặc cgroup. Đừng dùng RLIMIT_AS hay RLIMIT_DATA: PHP cảnh báo chúng có thể kích hoạt chính lỗi này.
• post_max_size thấp: 8M nếu ứng dụng không cần upload file, 32M nếu cần, và luôn để upload_max_filesize nhỏ hơn.
• PHP 8.5: thêm php_admin_flag[fatal_error_backtraces] = off.

Dùng mod_php thì đặt tương tự trong cấu hình Apache, ví dụ php_admin_flag session.upload_progress.enabled off. Đặt xong, restart PHP-FPM hoặc Apache.

Thêm vài lớp chặn ở ngoài PHP:

• Giới hạn kích thước request ở Nginx hoặc reverse proxy, ví dụ client_max_body_size 8m;. PHP khuyên giới hạn cả số field, số phần multipart, số header và độ sâu lồng nhau nếu proxy của bạn hỗ trợ.
• Bật WAF nếu có. CISA đánh giá WAF chỉ bảo vệ được một phần.
• Nếu hiệu năng cho phép, pm.max_requests = 1 buộc mỗi worker chỉ xử lý một request, nên request sau không thể dùng lại trạng thái cũ. Cái giá rất đắt: mỗi request phải khởi tạo worker mới.

Dấu hiệu server đã bị tấn công

CISA khuyên theo dõi worker PHP tự sinh ra shell hoặc tải công cụ về. Xem cây tiến trình:

ps -eo pid,ppid,user,cmd --forest | grep -A3 -E 'php-fpm: pool|apache2'

Bên dưới các worker php-fpm: pool hay apache2 mà xuất hiện sh, bash, curl, wget hoặc nc là dấu hiệu đáng lo.

Xem file PHP nào trong thư mục web bị thay đổi từ ngày 21/10/2026 (trừ những file bạn vừa deploy):

sudo find /var/www -name '*.php' -newermt '2026-10-21' -ls

Nếu nghi đã bị xâm nhập: cách ly server, đổi toàn bộ mật khẩu và key trong .env (database, mail, API), rồi dựng lại từ bản sạch thay vì chỉ xoá file lạ.

Dùng Laravel thì cần làm gì thêm?

• Laravel trên PHP-FPM hoặc Apache: làm đúng như trên. Phiên bản Laravel không liên quan, vì lỗi nằm ở PHP.
• Laravel Octane với FrankenPHP: FrankenPHP 1.13.2 (21/10/2026) đã build lại với PHP 8.2.35, 8.3.36, 8.4.27 và 8.5.12. Cập nhật binary hoặc image FrankenPHP lên bản này trở lên.
• Queue worker và scheduler chạy bằng CLI nên không nằm trong phạm vi lỗ hổng. Nhưng sau khi cập nhật PHP, nên chạy php artisan queue:restart để worker nạp lại bản PHP mới. Cách cấu hình Supervisor cho queue có trong bài setup Crontab và Supervisor Queue trên server.
• Laravel Sail ở máy dev: rủi ro thấp vì không mở ra internet, nhưng nên build lại cho đồng bộ: ./vendor/bin/sail build --no-cache.

Checklist PHP2Shell

• Liệt kê mọi server và container có chạy PHP, ưu tiên những cái mở ra internet.
• Kiểm tra phiên bản PHP đang phục vụ web (FPM hoặc mod_php), không chỉ php -v.
• Trên Ubuntu/Debian: so phiên bản gói với bảng trong bài.
• Cập nhật lên 8.5.12, 8.4.27, 8.3.36, 8.2.35 hoặc gói đã vá của bản phân phối.
• Docker: build lại với --pull và chạy lại container.
• Restart PHP-FPM, Apache, FrankenPHP; với Laravel, chạy thêm queue:restart.
• PHP 8.1 trở xuống (kể cả 7.3): chặn truy cập từ internet ngay hôm nay, tìm gói backport theo bảng trong bài, và lên kế hoạch nâng cấp lên 8.3 trở lên.
• Chưa vá được: áp dụng các thiết lập giảm thiểu, nhưng đặt hạn vá trong ngày.
• Xem cây tiến trình và các file PHP bị thay đổi từ 21/10/2026.

Nguồn

Kiểm tra ngày 23/10/2026.

• PHP, Security advisory ngày 21/10/2026 và thông báo trước ngày 20/10/2026: https://www.php.net/archive/2026.php
• GHSA-w8hw-w9fx-j79w, CVE-2026-109618: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
• GHSA-6wmf-4rv5-p3rp, CVE-2026-109619: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• CISA, Critical Vulnerabilities in PHP Require Immediate Patching: https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
• watchTowr, PHP2Shell FAQ: https://watchtowr.com/intelligence/php-cve-2026-109618-faq/
• Ubuntu CVE-2026-109618: https://ubuntu.com/security/CVE-2026-109618
• Debian security tracker: https://security-tracker.debian.org/tracker/CVE-2026-109618
• Remi, PHP 8.2.35, 8.3.36, 8.4.27 và 8.5.12: https://blog.remirepo.net/
• FrankenPHP releases: https://github.com/php/frankenphp/releases
• Sansec, PHP2Shell (bảng các đường vá cho PHP cũ): https://sansec.io/research/php2shell
• TuxCare, php2shell patch FAQ: https://tuxcare.com/els-php2shell-patches-faq/
• Red Hat, RHSB-2026-013: https://access.redhat.com/security/vulnerabilities/RHSB-2026-013
• Ubuntu Pro: https://ubuntu.com/pro
• PHP, các phiên bản còn hỗ trợ: https://www.php.net/supported-versions.php
• Laravel, Support Policy: https://laravel.com/docs/12.x/releases và https://laravel.com/docs/9.x/releases