1 Tìm mọi bản PHP trên server

Nhiều server chạy nhiều hơn một bản PHP: gói của hệ thống, các phiên bản do control panel cài (cPanel EA-PHP, Plesk, CWP/CloudLinux alt-php, DirectAdmin), container và các bản build dòng lệnh dùng cho cron. Mỗi bản phục vụ yêu cầu web đều phải được cập nhật.

Chạy php -v, liệt kê các tiến trình php-fpm bằng ps aux | grep php-fpm và kiểm tra trình chọn PHP trong panel của bạn.

2 Cập nhật lên phiên bản đã vá

Các phiên bản upstream đã vá là 8.5.12, 8.4.27, 8.3.36 và 8.2.35. Gói của bản phân phối có thể chứa bản vá dưới số phiên bản cũ hơn — hãy kiểm tra changelog để tìm CVE-2026-109618 và CVE-2026-109619.

PHP 8.1 trở về trước không nhận bản phát hành nào từ dự án PHP. Các bản backport tối thiểu ở dạng mã nguồn đã được công bố cho 7.4, 8.0 và 8.1 dành cho những ai tự build từ mã nguồn, nhưng giải pháp lâu dài là chuyển sang một nhánh được hỗ trợ.

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

Cài bản cập nhật bảo mật từ bản phân phối của bạn và khởi động lại PHP. Số phiên bản có thể giữ nguyên; changelog của gói sẽ liệt kê CVE.

sudo apt update && sudo apt install --only-upgrade 'php*'
sudo systemctl restart 'php*-fpm' apache2 2>/dev/null
apt changelog php8.3-fpm | grep -i -m3 CVE-2026-1096

RHEL / AlmaLinux / Rocky (dnf)

Áp dụng errata của nhà cung cấp cho module stream PHP của bạn, sau đó khởi động lại.

sudo dnf upgrade --refresh 'php*'
sudo systemctl restart php-fpm httpd
rpm -q --changelog php-common | grep -i -m3 CVE-2026-1096

Docker / image php chính thức

Pull hoặc build lại với tag đã vá và tạo lại các container.

docker pull php:8.3-fpm   # must report 8.3.36 or later
docker compose up -d --build --force-recreate
docker compose exec app php -v

cPanel, Plesk, CWP, DirectAdmin

Dùng công cụ cập nhật của panel cho mọi phiên bản PHP đã cài (EA-PHP, PHP handler của Plesk, alt-php, CustomBuild), sau đó khởi động lại PHP-FPM. Panel thường giữ lại các phiên bản cũ cho từng trang web — hãy cập nhật hoặc gỡ bỏ chúng.

Shared hosting hoặc managed hosting

Thông thường bạn không thể tự cập nhật PHP. Hãy dùng tin nhắn trên thẻ kết quả để hỏi nhà cung cấp về phiên bản chính xác, ngày vá và xác nhận rằng các worker đã được khởi động lại.

Windows / IIS

Tải bản build đã vá từ windows.php.net, thay thế thư mục PHP và recycle các application pool của IIS.

3 Khởi động lại mọi tiến trình PHP

Cài gói không thay đổi mã đang chạy. Hãy khởi động lại PHP-FPM, Apache (với mod_php), LiteSpeed, FrankenPHP, queue worker và supervisor. Với container, hãy build lại hoặc pull image mới — khởi động lại cùng một image không cài được bản vá.

4 Xác minh

Chạy php -v cho từng binary và xác nhận các tiến trình đang chạy dùng bản build mới (ví dụ ls -l /proc/$(pgrep -o php-fpm)/exe không được hiện “deleted”). Sau đó chạy lại công cụ kiểm tra này.

5 Nếu bạn chưa thể cập nhật hôm nay

Áp dụng các biện pháp giảm thiểu một phần bên dưới và hạn chế ai có thể truy cập trang web cho đến khi bạn cập nhật được. Chúng giảm rủi ro chứ không loại bỏ rủi ro.

6 Kiểm tra dấu hiệu bị xâm nhập — và thay các thông tin bí mật

Nếu một trang web có lỗ hổng truy cập được từ internet, hãy rà soát hoạt động từ 20 tháng 10 năm 2026 trở đi: worker PHP bị crash (SIGSEGV) trong log lỗi của PHP-FPM hoặc Apache, các tệp PHP mới hoặc bị sửa đổi trong web root, cron job mới, tài khoản quản trị mới và các kết nối ra ngoài bất thường.

Vì CVE-2026-109619 có thể làm lộ bộ nhớ của tiến trình PHP mà không chạy bất kỳ mã nào, hệ thống tệp sạch không chứng minh rằng không có gì bị rò rỉ. Hãy thay mật khẩu cơ sở dữ liệu, API key, thông tin xác thực thanh toán và email, đồng thời vô hiệu hóa phiên người dùng của các trang web đã bị lộ.

7 Sau khi cập nhật

Bản vá đưa vào một giới hạn bộ nhớ cứng mới: tiến trình chạm tới giới hạn này bị dừng ngay lập tức và các shutdown handler không được chạy. Hãy kiểm tra cách ứng dụng của bạn hoạt động khi thiếu bộ nhớ, xem lại memory_limit cùng với post_max_size và max_input_nesting_level, và hoàn tác mọi thiết lập tạm thời memory_limit = -1 bạn đã đặt trước khi vá. Ẩn phiên bản bằng expose_php = Off là biện pháp tăng cường tùy chọn, không phải bản vá.

Biện pháp giảm thiểu một phần (từ php.net và các thông báo bảo mật)

Các biện pháp này chỉ thu hẹp những đường tấn công đã biết. php.net khẳng định cập nhật là lựa chọn an toàn duy nhất.

; php.ini / FPM pool (php_admin_value) — khởi động lại tất cả worker sau đó
session.upload_progress.enabled = 0
fatal_error_backtraces = 0        ; PHP 8.5
post_max_size = 8M                ; 32M nếu cần tải tệp lên
max_input_nesting_level = 16      ; default 64
display_errors = 0

; FPM pool
pm.max_requests = 200

Thiết lập các giá trị này trong php.ini, pool PHP-FPM (php_admin_value) hoặc cấu hình server — không dùng ini_set() hay .user.ini — rồi khởi động lại các worker. Các biện pháp bổ sung từ các thông báo bảo mật và nhóm nghiên cứu:

memory_limit = -1 chặn một số đường tấn công dựa vào giới hạn bộ nhớ của chính PHP, nhưng đẩy việc cạn bộ nhớ sang hệ điều hành — chỉ dùng cùng với giới hạn cgroup v2 memory.max. Không dùng RLIMIT_AS hay RLIMIT_DATA; chúng có thể kích hoạt chính các đường tấn công có lỗ hổng đó.
Giảm max_input_nesting_level xuống mức thấp nhất mà các biểu mẫu của bạn cho phép.
Giảm pm.max_requests của PHP-FPM để worker được tái tạo thường xuyên hơn (ảnh hưởng đến hiệu năng).
Giới hạn kích thước yêu cầu, số trường và độ lồng nhau ở web server hoặc proxy; loại bỏ các thiết lập INI theo từng yêu cầu không hợp lệ hoặc đã lỗi thời.
Chính sách SELinux hoặc AppArmor có thể hạn chế những gì một worker bị xâm nhập được phép chạy — chúng giảm tác động, không ngăn được việc lộ bộ nhớ.

Tài liệu tham khảo

Nguồn: thông báo bảo mật của php.net, 21 tháng 10 năm 2026. Xác minh lần cuối 2026-10-23.