Lỗ hổng PHP CVE-2026-109618/109619: cách xử lý khi chưa kịp nâng cấp

Tóm tắt: Ngày 21/10/2026, đội phát triển PHP vá hai lỗ hổng cho phép thực thi mã từ xa mà không cần xác thực (CVSS v4.0 là 9.2) trong PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35. Cách xử lý triệt để duy nhất là nâng cấp. Nếu chưa nâng cấp được ngay, hãy chặn site trước khi request chạm tới PHP.

Mục lục

1. Lỗ hổng PHP công bố ngày 21/10/2026 nguy hiểm ở điểm nào?
2. Làm sao biết PHP của bạn có bị ảnh hưởng không?
3. Chưa nâng cấp được ngay thì nên làm gì?
4. VAON đã nâng cấp hệ thống PHP của khách hàng như thế nào?
5. Sau khi nâng cấp xong, cần kiểm tra thêm điều gì?
6. Khi nào quy trình này chưa đủ?
7. Câu hỏi thường gặp

1. Lỗ hổng PHP công bố ngày 21/10/2026 nguy hiểm ở điểm nào?

Khoảng 23 giờ (giờ Nhật) ngày 21/10/2026, đội phát triển PHP công bố bản vá cho hai lỗ hổng. Cả hai đều đạt 9,2 điểm CVSS v4.0 (mức Critical). Kẻ tấn công từ bên ngoài có thể chạy mã với quyền của user chạy web server mà không cần đăng nhập.

PHP 8.1 trở xuống không còn nhận bản cập nhật từ đội phát triển PHP. Một số nhà cung cấp bản phân phối hoặc hỗ trợ dài hạn (LTS) có thể đã backport bản vá. Bạn cần hỏi trực tiếp nhà cung cấp của mình.

Tại Nhật, tình hình còn gấp hơn. Theo ITmedia NEWS, thông tin lỗ hổng và PoC (mã chứng minh khả năng tấn công) đã xuất hiện trên mạng trước khi bản vá ra mắt, và đã ghi nhận các nỗ lực tấn công. Thủ tướng Takaichi kêu gọi xử lý ngay trong đêm trên X. Thủ tướng cũng cho rằng tạm dừng site cũng là một lựa chọn hợp lý nếu chưa vá kịp. Nhiều dịch vụ trực tuyến tại Nhật đã phải bảo trì khẩn cấp.

2. Làm sao biết PHP của bạn có bị ảnh hưởng không?

Chỉ nhìn số phiên bản là chưa đủ. Bạn cần kiểm tra cùng lúc ba điểm sau.

1. Phiên bản PHP đang chạy cho web. Lệnh php -v trên server chỉ cho biết PHP bản dòng lệnh (CLI). Request web do PHP-FPM hoặc mod_php xử lý. Hãy kiểm tra chính FPM, ví dụ php-fpm8.3 -v (họ RHEL dùng php-fpm -v), hoặc mở phpinfo() ở nơi chỉ quản trị viên truy cập được. Nhiều server cài CLI và FPM ở hai phiên bản khác nhau.
2. Nguồn cài đặt gói. Gói chính thức của Ubuntu, Debian và họ RHEL đôi khi chỉ đưa bản vá vào mà không đổi số phiên bản. Khi đó php -v báo số cũ hơn 8.3.36 nhưng lỗ hổng đã được vá. Chỉ dựa vào số để kết luận "an toàn" hay "nguy hiểm" đều dễ sai. Hãy căn cứ vào thông báo bảo mật và lịch sử cập nhật của nhà cung cấp. Theo thông báo chính thức của PHP, repository rpms.remirepo.net do cộng đồng vận hành chưa có bản cập nhật trong ngày công bố. Server dùng repository này cần chuyển sang gói của bản phân phối hoặc build từ mã nguồn.
3. SAPI (cách PHP kết nối với web server). Xem dòng "Server API" trong phpinfo(). Nếu là "Apache 2.0 Handler", bạn đang dùng mod_php, cấu hình nguy hiểm nhất lần này. Nếu là "FPM/FastCGI", hãy kiểm tra cấu hình web server có truyền PHP_VALUE hay không.

Với shared hosting hoặc môi trường managed, bạn có thể không tự nâng cấp PHP được. Hãy đọc thông báo của nhà cung cấp trước. Nếu chưa thấy lịch xử lý, hãy hỏi họ ngay.

3. Chưa nâng cấp được ngay thì nên làm gì?

Nếu chưa nâng cấp PHP được ngay, quyết định đầu tiên là có nên tạm dừng site hay không. Thông báo chính thức của PHP viết rằng không có biện pháp giảm thiểu hoàn chỉnh, và nâng cấp là lựa chọn an toàn duy nhất. Các cấu hình giảm rủi ro có được nêu, nhưng tất cả chỉ có tác dụng một phần.

Điều cần lưu ý là chặn ở đâu. Chế độ bảo trì của ứng dụng (như php artisan down của Laravel) chỉ hoạt động sau khi PHP đã chạy rồi mới trả về "đang bảo trì". CVE-2026-109618 có ví dụ tấn công thành công trước khi code ứng dụng chạy, nên cách này không bảo vệ được bạn. Hãy trả trang bảo trì dạng HTML tĩnh từ load balancer, CDN hoặc cấu hình web server, để request không bao giờ tới PHP.

Nếu không thể dừng site, thông báo chính thức đưa ra các cấu hình tạm thời sau.

• Đặt session.upload_progress.enabled=0 trong php.ini, cấu hình pool của FPM hoặc cấu hình server, rồi khởi động lại toàn bộ worker (ini_set() và .user.ini không có tác dụng).
• Đặt memory_limit=-1 bằng php_admin_value để ứng dụng không ghi đè được.
• Giảm post_max_size (ví dụ chính thức là 8M, hoặc 32M nếu cần upload file). upload_max_filesize phải nhỏ hơn giá trị đó.
• Với PHP 8.5, đặt fatal_error_backtraces=0 rồi khởi động lại toàn bộ worker.
• Nếu ứng dụng không dùng request multipart, hãy chặn loại request này ở tầng phía trước.

memory_limit=-1 nghĩa là bỏ hẳn giới hạn bộ nhớ. Cấu hình này giúp tránh lỗ hổng, nhưng đổi lại server có thể bị chiếm hết RAM. Thông báo chính thức cũng cảnh báo không dùng RLIMIT_AS hoặc RLIMIT_DATA để thay thế, vì chúng sẽ kích hoạt đúng đoạn xử lý có lỗ hổng.

4. VAON đã nâng cấp hệ thống PHP của khách hàng như thế nào?

Ngay sau khi bản vá ra mắt lúc khoảng 23 giờ (giờ Nhật), VAON bắt đầu xử lý 5 hệ thống PHP mà chúng tôi đang bảo trì cho khách hàng, và nâng cấp xong PHP trong khoảng 1 giờ. Phần test toàn bộ được làm sau đó, tính thêm thời gian riêng. Hệ thống nào cũng đi theo 6 bước dưới đây, cùng một thứ tự.

1. Chuyển sang trang bảo trì. Chúng tôi báo khung giờ dừng cho đầu mối phía khách hàng, rồi trả trang bảo trì tĩnh từ web server hoặc load balancer. Như phần trên đã nêu, trang này không đi qua PHP.
2. Liệt kê cấu hình server. Với từng hệ thống, chúng tôi lập danh sách: OS, web server, SAPI, nguồn cài gói PHP, và có dùng Docker image hay không. Cùng là "PHP 8.3" nhưng nguồn cài khác nhau thì cách nâng cấp cũng khác.
3. Xác nhận phiên bản PHP đang chạy. Ngoài php -v, chúng tôi xem phiên bản của chính FPM và dòng Server API trong phpinfo() để tìm chỗ lệch giữa CLI và web. Danh sách extension (php -m) được lưu lại làm bản ghi trước khi nâng cấp.
4. Nâng cấp PHP. Chúng tôi thay bằng gói đã vá của nhà cung cấp, hoặc build lại image từ bản đã vá. Sau đó khởi động lại PHP-FPM hoặc Apache để mọi worker chạy bản mới, vì chỉ sửa file cấu hình thì worker cũ vẫn tiếp tục chạy. Với session.upload_progress.enabled=0, chúng tôi xác nhận ứng dụng không dùng tính năng này rồi giữ nguyên cấu hình sau khi nâng cấp.
5. Kiểm thử toàn bộ. Hệ thống có test tự động thì chạy test. Phần test tự động chưa phủ tới, chúng tôi kiểm tra tay các thao tác mà khách hàng không thể để gián đoạn: đăng nhập, tìm kiếm, upload file, thanh toán. Chúng tôi cũng so php -m sau nâng cấp với bản ghi trước đó để chắc chắn không mất extension, và xem error log có cảnh báo mới nào không.
6. Gỡ trang bảo trì và theo dõi. Sau khi mở lại site, chúng tôi tiếp tục theo dõi error log và lưu lượng truy cập một thời gian, rồi mới báo hoàn tất cho khách hàng.

Trong 6 bước, phần tốn công nhất là kiểm tra trước và sau khi nâng cấp. Khi lên phiên bản PHP mới, một số thư viện mà dự án đang dùng có thể không chạy được nữa. Vì vậy chúng tôi xác định trước thư viện nào, ở phiên bản nào có thể bị ảnh hưởng, rồi mới test lại toàn bộ dự án. Thời gian dành cho phần kiểm tra này nhiều hơn chính việc nâng cấp PHP.

5. Sau khi nâng cấp xong, cần kiểm tra thêm điều gì?

Nâng cấp PHP chỉ chặn được các cuộc tấn công sắp tới. Các nỗ lực tấn công đã được ghi nhận từ trước khi bản vá ra mắt. Nếu site vẫn công khai trước khi bạn nâng cấp, hãy kiểm tra xem kẻ tấn công đã vào chưa.

• Thư mục public của web server có file PHP lạ mới xuất hiện không?
• Access log trước và sau thời điểm nâng cấp có dồn nhiều request multipart dung lượng lớn không?
• Có tiến trình lạ nào đang chạy dưới user của web server không?

Chỉ cần một dấu hiệu đáng ngờ, hãy nhờ chuyên gia điều tra và giả định rằng server phải dựng lại.

Còn một việc để lần này không lặp lại. Bản vá bảo mật của PHP 8.2 kết thúc vào ngày 31/12/2026. Hệ thống chạy PHP 8.1 trở xuống đã không còn nhận bản vá chính thức. Muốn nâng cấp được ngay trong ngày khi có lỗ hổng khẩn cấp tiếp theo, bạn nên lập kế hoạch nâng phiên bản từ bây giờ.

6. Khi nào quy trình này chưa đủ?

Quy trình trong bài giả định bạn đã có gói hoặc image bản vá và tự thao tác được trên server. Các trường hợp sau cần cách xử lý khác.

• Đang chạy PHP 8.1 trở xuống và chưa kiểm tra ứng dụng có chạy được trên PHP mới. Nâng phiên bản có thể làm hỏng ứng dụng. Bạn phải chọn giữa dùng backport của nhà cung cấp hoặc giữ site tạm dừng trong lúc di chuyển.
• Dùng shared hosting hoặc môi trường do nhà cung cấp nâng cấp PHP. Bạn chỉ quyết định được có dừng site hay không và hỏi nhà cung cấp.
• Đã có dấu vết bị xâm nhập. Nâng cấp không đưa server về trạng thái trước khi bị xâm nhập.

Cách VAON xử lý cũng không đảm bảo hệ thống chưa bị xâm nhập trước thời điểm nâng cấp. Mức độ kiểm tra thêm, chúng tôi bàn và chốt cùng khách hàng.

7. Câu hỏi thường gặp

php -v báo phiên bản cũ thì có nguy hiểm không? Không thể kết luận chỉ từ con số. php -v cho biết PHP bản CLI, có thể khác PHP đang chạy cho web. Gói chính thức của OS cũng có thể đã vá mà không đổi số. Hãy kiểm tra phiên bản của chính FPM và thông báo bảo mật của nhà cung cấp gói.

Bật chế độ bảo trì của ứng dụng có chặn được tấn công không? Không nên tin như vậy. Cơ chế như php artisan down của Laravel chỉ trả "đang bảo trì" sau khi PHP đã chạy. CVE-2026-109618 có ví dụ tấn công thành công trước khi code ứng dụng chạy, nên trang bảo trì phải được trả từ tầng không đi qua PHP.

Dùng PHP-FPM thì có bị ảnh hưởng không? Có. Thông báo chính thức của PHP coi mod_php là nguy hiểm nhất, nhưng áp dụng cho mọi môi trường xử lý request web, kể cả PHP-FPM. Cấu hình truyền PHP_VALUE hoặc PHP_ADMIN_VALUE từ nginx thỏa điều kiện của CVE-2026-109619, nên cần đặc biệt lưu ý.

Chỉ đổi cấu hình tạm thời rồi chờ có được không? Chúng tôi không khuyến nghị. Thông báo chính thức của PHP nêu rõ không có biện pháp giảm thiểu hoàn chỉnh và nâng cấp là lựa chọn an toàn duy nhất. Hãy coi thay đổi cấu hình là biện pháp bắc cầu và chốt trước ngày giờ nâng cấp.

Tôi đang dùng PHP 8.1. Nên bắt đầu từ đâu? Trước hết, hỏi nhà cung cấp OS hoặc LTS xem họ đã có bản vá chưa. Nếu chưa, bạn cần tạm dừng site đến khi nâng cấp được, hoặc chặn request multipart ở tầng trước, trong lúc di chuyển lên phiên bản còn hỗ trợ. Có cần sửa ứng dụng hay không, chỉ biết được sau khi xem mã nguồn.

Site nào của bạn vẫn chưa nâng cấp PHP? Bạn chưa rõ cấu hình server, hoặc người bàn giao đã nghỉ việc cũng không sao. Trong buổi trao đổi miễn phí, chúng tôi cùng bạn quyết định có nên dừng site không và nâng cấp theo thứ tự nào. Nếu cần gấp, bạn có thể gửi email trực tiếp tới luan.dang@vaon.com.vn. Đặt lịch trao đổi miễn phí

Tài liệu tham khảo

• PHP "News Archive 2026" (Security advisory: Critical remote code execution vulnerabilities, update now, 21/10/2026): https://www.php.net/archive/2026.php (kiểm tra 22/10/2026)
• php-src "GHSA-6wmf-4rv5-p3rp: RCE via stale global state" (CVE-2026-109619): https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp (kiểm tra 22/10/2026)
• ITmedia NEWS "高市総理「大至急、PHPパッチ適用を」Xで異例の要請　エンジニアは評価「経営層に伝わる」" (22/10/2026): https://www.itmedia.co.jp/news/article/2610/22/2000002483/ (kiểm tra 22/10/2026)