php2shell (CVE-2026-109618 / 109619) không thể đánh giá bằng php -v: nơi số phiên bản lệch nhau giữa FPM, Docker và các bản phân phối

Nếu PHP xử lý yêu cầu web (PHP-FPM, mod_php của Apache, php-cgi, FrankenPHP, LiteSpeed) cũ hơn 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 thì nó bị ảnh hưởng bởi CVE-2026-109618 và CVE-2026-109619, được gọi là php2shell. Cách khắc phục là nâng cấp lên một trong các phiên bản này (hoặc, với gói của bản phân phối, lên gói đã được vá) rồi khởi động lại các tiến trình. Điều cần kiểm tra không phải là php -v trên máy bạn, mà là “PHP thực sự đang phục vụ web” và “phiên bản gói đã cài”.

Bài viết này tập trung vào bốn chỗ mà việc chỉ dựa vào số phiên bản dễ dẫn đến kết luận sai. Mọi số liệu và thông tin tình trạng đều tính đến 2026-10-22, và nguồn của từng mục được liệt kê ở cuối bài.

Những gì đã biết tính đến 2026-10-22

Thông báo của PHP nêu rằng “cách khắc phục hoàn chỉnh duy nhất là cập nhật”. Các biện pháp giảm thiểu cho giai đoạn trước khi bạn cập nhật được được trình bày ở phần sau của bài.

Cạm bẫy 1: php -v và PHP phía web có thể khác nhau

php -v gõ qua SSH báo phiên bản của PHP CLI. Các yêu cầu web được xử lý bởi các tiến trình PHP-FPM hoặc bởi mod_php nạp vào Apache, là những binary và gói riêng. Nếu bạn chỉ cài PHP mới cho CLI, chạy song song nhiều phiên bản, hoặc có một FPM pool trỏ tới phiên bản khác, thì phía web vẫn có thể cũ ngay cả khi php -v hiển thị phiên bản đã vá.

Có nhiều cách để xem phiên bản thực ở phía web.

# FPM trên Debian / Ubuntu (tên theo từng phiên bản)
php-fpm8.3 -v

# FPM trên họ RHEL
php-fpm -v

# Kiểm tra mod_php có được nạp trong Apache hay không
apachectl -M | grep -i php

Cách đáng tin cậy nhất là để chính PHP chạy qua web tự báo phiên bản của nó. Hãy đặt một tệp tạm có tên khó đoán, và xóa ngay sau khi kiểm tra xong.

<?php echo PHP_VERSION, ' ', PHP_SAPI;

Nếu PHP_SAPI là fpm-fcgi, PHP đang chạy dưới FPM; apache2handler nghĩa là mod_php; cgi-fcgi nghĩa là CGI. Không nên để lộ phpinfo(), vì bản thân việc đó đã làm rò rỉ thông tin.

Khởi động lại là một bước khác dễ bị bỏ sót. Ngay cả sau khi gói đã được thay, các tiến trình php-fpm hoặc Apache đang chạy vẫn có thể tiếp tục chạy mã cũ. Một số cấu hình tự khởi động lại khi cập nhật gói; số khác thì không. Sau khi cập nhật, hãy khởi động lại FPM / Apache và kiểm tra lại phiên bản phía web bằng các cách ở trên.

Cạm bẫy 2: Với Docker, bạn không thể đánh giá theo tên thẻ

Image php chính thức có các “thẻ thay đổi” như 8.3 và 8.3-fpm, nội dung của chúng được thay thế theo thời gian, và các thẻ cố định như 8.3.30, giữ nguyên phiên bản.

• Ngay cả sau khi một thẻ thay đổi được chuyển sang phiên bản đã vá trên Docker Hub, bản sao cục bộ của bạn vẫn là image cũ cho đến khi bạn pull lại. Các container đang chạy cũng tiếp tục dùng image cũ cho đến khi được tạo lại. Một Dockerfile có FROM php:8.3-fpm vẫn sẽ build trên base cũ nếu base đó còn trong build cache.
• Một thẻ cố định sẽ cũ mãi cho đến khi bạn tự nâng số phiên bản.

Bạn có thể kiểm tra các thẻ phiên bản đã vá đã được công bố hay chưa bằng Docker Hub API.

curl -s "https://hub.docker.com/v2/repositories/library/php/tags?name=8.3.36&page_size=100"

Dưới đây là kết quả truy vấn bốn dòng phát hành vào 2026-10-22 (giờ UTC).

Qua việc kiểm tra này, có ba điểm mà việc đánh giá theo con số có thể gây hiểu lầm.

1. “Mới cập nhật gần đây” không có nghĩa là “đã vá”. Thẻ cố định 8.3.35 đã được build lại trong ngày 2026-10-21, nhưng PHP_VERSION bên trong vẫn là 8.3.35. Hãy xem phiên bản bên trong, không phải thời điểm cập nhật.
2. Digest khác nhau vẫn có thể có cùng nội dung. 8.3 và 8.3.36 có digest thẻ khác nhau (giá trị của chỉ mục đa kiến trúc), nhưng image amd64 giống hệt nhau và cả hai đều có PHP_VERSION=8.3.36. Tương tự, với 8.3-fpm / 8.3.36-fpm, 8.4-apache / 8.4.27-apache, latest / 8.5.12, 8.5-fpm và 8.2-fpm, PHP_VERSION của image amd64 là phiên bản đã vá.
3. Không có image chính thức đã vá cho 8.1 trở xuống. 8.1-fpm được cập nhật lần cuối vào 2025-12-31.

Để kiểm tra các image cục bộ và container đang chạy:

# Phiên bản PHP của một image đã pull về máy
docker image inspect php:8.3-fpm --format '{{range .Config.Env}}{{println .}}{{end}}' | grep PHP_VERSION

# Pull lại và tạo lại các container
docker compose pull
docker compose up -d

# Nếu bạn tự build image, hãy pull lại base rồi mới build
docker compose build --pull

# Phiên bản bên trong một container đang chạy
docker compose exec app php -r 'echo PHP_VERSION, PHP_EOL;'

Hãy thay app trong lệnh cuối bằng tên service của bạn. Mỗi image chính thức được build với một PHP_VERSION duy nhất, nên phiên bản CLI bên trong container khớp với phiên bản FPM / Apache của container đó (Cạm bẫy 1 áp dụng khi PHP được cài trực tiếp trên máy chủ).

FrankenPHP nhúng PHP bên trong, nên phiên bản FrankenPHP và phiên bản PHP nhúng là hai con số khác nhau. Ghi chú phát hành của FrankenPHP 1.13.2, phát hành vào 2026-10-21, nêu rằng các image Docker được build với PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 và các binary tĩnh được build với PHP 8.5.12.

Cạm bẫy 3: Gói của bản phân phối là “được vá nhưng giữ số cũ”

Ubuntu và RHEL chỉ chuyển các bản sửa lỗi sang các phiên bản cũ (backporting). Số hiển thị bởi php -v vẫn cũ, nên cách kiểm tra bằng số như “thấp hơn 8.3.36, do đó dễ bị tấn công” sẽ đánh dấu nhầm một hệ thống đã vá là có lỗ hổng. Ngược lại, bạn cũng không thể dựa vào con số để yên tâm. Hãy đưa ra kết luận dựa trên phiên bản gói và trình theo dõi bảo mật của từng bản phân phối.

Các gói đã vá được liệt kê trong từng trình theo dõi tính đến 2026-10-22 (giống nhau cho cả hai CVE):

Bảng này cho thấy trực tiếp vì sao chỉ dựa vào con số là không đủ. PHP đã vá của Ubuntu 24.04 là phiên bản bắt đầu bằng 8.3.6, thấp hơn nhiều so với 8.3.36 của upstream. PHP mặc định của RHEL 9 được vá nhưng vẫn ở 8.0.30, dù upstream không còn phát hành bản sửa lỗi cho 8.0. Debian đã chuyển sang cùng số với upstream (8.2.35 / 8.4.27).

Một số gói vẫn chưa được vá (tính đến 2026-10-22).

• php module 8.4 của RHEL 9 được liệt kê là “affected, no fix” (bị ảnh hưởng, chưa có bản vá).
• Debian forky (testing) có php8.4 8.4.26-1, được đánh dấu “vulnerable”. php8.4 trong sid (unstable) là 8.4.27-1 và đã được vá.

Ví dụ các lệnh để kiểm tra máy chủ của bạn:

# Debian / Ubuntu: phiên bản đã cài và phiên bản có sẵn
apt-cache policy php8.3-fpm libapache2-mod-php8.3

# Ubuntu: CVE này đã được vá trên máy chủ này chưa
pro fix CVE-2026-109618
pro fix CVE-2026-109619

# Họ RHEL: có bản cập nhật vá CVE này không, và phiên bản đã cài
dnf updateinfo list --cve CVE-2026-109618
rpm -q php-fpm php-cli

Hãy điều chỉnh tên gói (php8.3-fpm, v.v.) cho phù hợp với môi trường của bạn. So sánh phiên bản hiển thị với “phiên bản đã vá” trong bảng trên hoặc trong trình theo dõi; nếu bằng hoặc cao hơn thì bản vá đã có. Sau đó hãy hoàn tất việc khởi động lại và kiểm tra phía web như mô tả ở Cạm bẫy 1.

Nếu bạn cài PHP từ kho của bên thứ ba thay vì gói của chính bản phân phối, bạn cần theo dõi các bản cập nhật của kho đó. Thông báo của PHP lưu ý rằng rpms.remirepo.net, do tình nguyện viên vận hành, sẽ chưa có bản cập nhật vào ngày công bố, và khuyến nghị chuyển sang gói của bản phân phối hoặc bản tự build.

Cạm bẫy 4: Trên shared hosting và môi trường được quản lý, bạn không thể tự nâng cấp PHP

Trên shared hosting và các môi trường PHP được quản lý, nhà cung cấp là bên thay thế runtime PHP. Ở đây cũng vậy, chỉ có con số là không đủ: nếu nhà cung cấp tự build PHP hoặc backport các bản sửa lỗi thì số phiên bản có thể vẫn cũ.

Có ba việc bạn có thể tự làm.

1. Kiểm tra phiên bản phía web. Dùng tệp tạm ở Cạm bẫy 1 để in ra PHP_VERSION và PHP_SAPI, rồi xóa ngay. Nếu bảng điều khiển có mục chọn phiên bản PHP, hãy ghi lại phiên bản bạn đã chọn.
2. Đọc thông báo của nhà cung cấp, và hỏi nếu chưa có. Hãy hỏi: “Các bản sửa lỗi cho CVE-2026-109618 và CVE-2026-109619 sẽ được áp dụng cho những phiên bản PHP nào trong gói của tôi, và khi nào (hoặc đã được áp dụng chưa)?” Hỏi theo số CVE thay vì số phiên bản sẽ cho bạn câu trả lời bao gồm cả các bản backport.
3. Nếu bạn đang chọn một phiên bản không còn được hỗ trợ, hãy nâng cấp. Dự án PHP không phát hành bản sửa lỗi cho 8.1 trở xuống, và hỗ trợ cho 8.2 kết thúc vào 2026-12-31. Trừ khi nhà cung cấp đã backport các bản sửa lỗi, việc chuyển phiên bản là con đường chắc chắn.

Tình trạng theo từng nhà cung cấp hosting (tính đến 2026-10-22)

Trên shared hosting, nhà cung cấp thường là bên cập nhật runtime PHP, và thông báo của nhiều nhà cung cấp cho biết “người dùng không cần thực hiện thao tác nào”. Người dùng có hai việc cần làm: kiểm tra thông báo chính thức từ nhà cung cấp của mình, và nếu đã chọn một phiên bản PHP cũ trong bảng điều khiển thì cân nhắc có nên chuyển sang phiên bản mà thông báo khuyến nghị (phiên bản đã có bản phát hành vá lỗi) hay không.

Bảng dưới đây chỉ tóm tắt những gì được viết trên các trang chính thức của từng nhà cung cấp (thông báo và thông tin bảo trì), diễn đạt lại lời văn trong thông báo của họ. Các thông báo được cập nhật theo tiến độ, vì vậy hãy luôn xác nhận tình trạng thực tế trên trang chính thức được dẫn nguồn.

Ở những chỗ tôi không tìm thấy hoặc không mở được thông báo chính thức, bảng ghi “không xác nhận được” hoặc “không tìm thấy”. Việc thiếu thông tin ở đó không có nghĩa là nhà cung cấp chưa xử lý. Hãy kiểm tra trực tiếp qua thông báo và bộ phận hỗ trợ của nhà cung cấp của bạn.

Biện pháp giảm thiểu khi chưa thể cập nhật ngay

Thông báo của PHP liệt kê các thiết lập giúp giảm bề mặt tấn công cho đến khi bạn có thể cập nhật. Tuy nhiên, chính thông báo cũng nêu rõ rằng chúng “không làm bạn an toàn”. Các biện pháp chính là:

• Với CVE-2026-109619: đặt session.upload_progress.enabled=0 trong php.ini, FPM pool hoặc cấu hình máy chủ, và khởi động lại tất cả worker (ini_set() và .user.ini của FPM không có tác dụng với thiết lập này). Trên PHP 8.5, hãy đặt thêm fatal_error_backtraces=0.
• Với CVE-2026-109618: đặt memory_limit=-1 theo cách ứng dụng không thể ghi đè, và giảm post_max_size (8M nếu không có tải lên, 32M nếu có). Không dùng RLIMIT_AS / RLIMIT_DATA để thay thế.

NCSC của Vương quốc Anh khuyến nghị cân nhắc đưa ngoại tuyến bất kỳ hệ thống nào không thể cập nhật hoặc giảm thiểu ngay, và kiểm tra dấu hiệu bị xâm nhập trước khi cập nhật hoặc áp dụng biện pháp giảm thiểu.

Nguồn (kiểm tra ngày 2026-10-22)

• php.net: Security advisory: Critical remote code execution vulnerabilities, update now (2026-10-21)
• php.net: Upcoming Critical PHP Security Release (2026-10-20)
• php.net: Thông báo phát hành PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
• GitHub: GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Docker Hub: image php chính thức
• Ghi chú phát hành FrankenPHP 1.13.2
• Debian Security Tracker: CVE-2026-109618 / CVE-2026-109619
• Ubuntu: CVE-2026-109618 / CVE-2026-109619 / USN-8948-1 / USN-8948-2
• Red Hat: CVE-2026-109618 / CVE-2026-109619 (phiên bản gói đã vá lấy từ dữ liệu VEX của Red Hat)
• NCSC: Critical security issue affecting PHP