PHP vừa phát hành bốn bản vá khẩn cho hai lỗ hổng có thể dẫn tới thực thi mã từ xa không cần đăng nhập: 8.2.35, 8.3.36, 8.4.27 và 8.5.12. Nếu một website vẫn phục vụ request bằng bản thấp hơn trong cùng nhánh, việc cần làm là nâng patch ngay, rồi chứng minh tiến trình web thực sự đã chạy bản mới.
Chỗ dễ nhầm là php -v trên terminal chỉ cho biết PHP CLI. PHP-FPM, Apache mod_php, container hoặc một node khác trong cụm vẫn có thể giữ runtime cũ. Bài này đi theo hướng phòng thủ: xác định phiên bản, cập nhật, restart hoặc redeploy, smoke test và chuẩn bị đường lui; không tái hiện payload hay cách khai thác.
Mục lục [Hiển thị]
Phiên bản nào đã vá?
Thông báo ngày 21/10/2026 của PHP Security Team nêu hai vấn đề ảnh hưởng các cài đặt PHP phục vụ web request, gồm PHP-FPM, Apache với mod_php, php-cgi, FrankenPHP và LiteSpeed. Hai advisory gốc là CVE-2026-109618, liên quan xử lý trạng thái khi hết bộ nhớ, và CVE-2026-109619, liên quan trạng thái toàn cục còn sót qua ranh giới request.
| Nhánh đang dùng | Bản đầu tiên chứa vá | Việc nên làm |
|---|---|---|
| PHP 8.2 | 8.2.35 | Nâng tối thiểu lên 8.2.35 |
| PHP 8.3 | 8.3.36 | Nâng tối thiểu lên 8.3.36 |
| PHP 8.4 | 8.4.27 | Nâng tối thiểu lên 8.4.27 |
| PHP 8.5 | 8.5.12 | Nâng tối thiểu lên 8.5.12 |
| PHP 8.1 trở xuống | Không còn bản phát hành chính thức từ PHP project | Kiểm tra vendor backport hoặc nâng lên nhánh còn hỗ trợ |
Trang Supported Versions hiện liệt kê 8.2 đến 8.5 là các nhánh còn được hỗ trợ. Upstream cũng cung cấp source backport tối thiểu cho 7.4, 8.0 và 8.1 nhằm hỗ trợ trường hợp tự build hoặc không có vendor LTS, nhưng đó không biến các nhánh cũ thành nhánh được hỗ trợ trở lại.
PHP 8.6 RC4 cũng chứa thay đổi mới hơn, nhưng vẫn là release candidate dành cho kiểm thử. Đừng đưa RC4 lên production chỉ vì số phiên bản lớn hơn. Nếu đang chuẩn bị nâng nhánh, checklist trong bài Laravel trên PHP 8.6 RC3 hữu ích cho lab compatibility; còn sự cố hiện tại cần một patched stable runtime.
Đừng chỉ nhìn php -v
Một máy có thể cài nhiều binary, nhiều pool FPM hoặc nhiều image cùng lúc. Vì thế inventory nên tách theo đường request. CLI dùng binary nào? Web server chuyển request sang socket FPM nào? Apache có nạp module khác không? Container đang chạy digest nào? Load balancer còn node chưa rollout không?
# CLI: chỉ là một nguồn bằng chứng
php -v
php --ini
# FPM: kiểm service và pool đúng với website
systemctl status php8.4-fpm
php-fpm8.4 -i | grep -E 'PHP Version|Loaded Configuration'
# Container: kiểm image và process thực tế đang chạy
docker inspect --format '{{.Image}}' my-app
docker exec my-app php -v
Tên service và lệnh package khác nhau giữa distro, image và control panel, nên không nên copy một lệnh apt hay yum cho mọi server. Hãy bắt đầu từ kênh cài đặt đang quản lý runtime: repository của distro, vendor LTS, image chính thức, Forge hoặc platform tương ứng.
Bằng chứng tốt nhất đến từ tiến trình thực sự phục vụ request. Có thể dùng health check nội bộ chỉ trả phiên bản tối thiểu, giới hạn bằng authentication hoặc mạng riêng rồi xóa sau khi xác minh. Không để phpinfo() công khai: trang đó lộ quá nhiều cấu hình, extension, path và biến môi trường.
Với cụm nhiều node, nên gọi health check nhiều lần qua load balancer trong một khoảng đủ dài và gắn một mã node đã ẩn danh vào response nội bộ. Kết quả cần cho thấy mọi node đều trả patch version mong muốn. Nếu một request vẫn rơi vào bản cũ, dừng kết luận “đã vá”, cô lập node đó và kiểm lại rollout. Đây là negative control đơn giản nhưng bắt được tình huống autoscaling kéo image cũ hoặc deployment chỉ thay một phần.
Nâng bản vá nhưng vẫn phải có đường lui
Trước khi đổi runtime, lưu lại package version, image digest, cấu hình FPM và danh sách extension. Kiểm backup, rollback artifact và khoảng bảo trì phù hợp. Mục tiêu của rollback không phải quay lâu dài về bản dễ bị tấn công, mà là có lối phục hồi dịch vụ trong lúc sửa incompatibility rồi tiếp tục đưa bản vá lên.
Sau khi cài package mới, restart FPM hoặc Apache nếu mô hình đó giữ process PHP. Với container, build hoặc pull image đã vá rồi rollout workload; việc chỉ đổi tag trong file cấu hình chưa chứng minh container đang chạy digest mới. Queue worker, scheduler và process dài hạn cũng cần restart theo cơ chế deploy của ứng dụng.
Thông báo Laravel cập nhật lúc 23:26 UTC ngày 21/10 nói Laravel Cloud đã vá các ứng dụng đang chạy và deployment đã mở lại. Với Forge, người quản trị cần bấm Update PHP trên từng server hoặc dùng hướng dẫn SSH nếu thao tác thất bại. Vapor native runtime từ PHP 8.2 trở lên cần redeploy; custom hoặc Docker runtime cần một deployment với image mới. Envoyer đã hoạt động lại nhưng health check vẫn chưa được khôi phục tại thời điểm kiểm tra 10:06 ngày 22/10/2026 UTC+7.
Hướng dẫn platform có thể tiếp tục thay đổi, vì vậy hãy đọc lại trang trạng thái trước khi thao tác. Đặc biệt, đừng suy từ một node đã vá rằng toàn bộ cụm đều an toàn.
Nếu website có nhiều phiên bản PHP cho từng site, thao tác trên server mặc định cũng chưa chắc chạm đúng pool của ứng dụng. Ghi rõ mapping giữa domain, upstream socket, service và executable trước khi restart. Làm vậy mất thêm vài phút nhưng tránh cảnh CLI báo 8.4.27 trong khi virtual host vẫn đi vào pool 8.4.26.
Xác minh Laravel sau cập nhật
Runtime mới chỉ là nửa đầu công việc. Nửa còn lại là kiểm application vẫn chạy đúng và mọi process đã đổi phiên bản. Với Laravel, có thể đi theo một vòng ngắn nhưng đủ ý nghĩa:
- Chạy
composer check-platform-reqstrong artifact được deploy để phát hiện extension hoặc phiên bản không khớp. - Chạy test quan trọng nhất cho đăng nhập, route chính, upload hoặc import, session và database.
- Smoke test request qua đúng load balancer hoặc ingress mà người dùng đi qua, không chỉ gọi localhost trên một máy.
- Restart queue worker theo quy trình của dự án, chạy một job vô hại và kiểm scheduler.
- Theo dõi error log, tỉ lệ 5xx và exception mới; so sánh với baseline trước deploy.
Nếu có nhiều pool hay nhiều node, lưu evidence cho từng node: timestamp, SAPI, patch version, image digest hoặc package source và kết quả smoke test. Redact hostname, IP nội bộ, token và path riêng trước khi chia sẻ. Cách làm này cũng giống nguyên tắc trong bài kiểm tra đường nâng cấp Laravel 12: đừng coi dependency resolver chạy xong là bằng chứng ứng dụng production đã ổn.
Nếu chưa thể cập nhật ngay
Upstream nói rõ chỉ cập nhật mới là giải pháp đầy đủ. Các biện pháp cấu hình chỉ giảm một số đường tấn công và không làm hệ thống an toàn. Với CVE-2026-109618, advisory đề cập quản trị memory_limit, giới hạn kích thước request và upload ở nhiều lớp, cùng ranh giới tài nguyên container. Với CVE-2026-109619, upstream nêu việc tắt session upload progress khi không dùng, tắt fatal error backtrace trên PHP 8.5 và restart toàn bộ worker.
Những thay đổi này có trade-off thật. Bỏ giới hạn bộ nhớ có thể tăng rủi ro availability; siết request có thể làm upload hợp lệ thất bại; tắt session upload progress ảnh hưởng tính năng đang dựa vào nó. Hãy áp dụng trong change window, test đúng luồng ứng dụng và đặt thời hạn gỡ workaround sau khi runtime đã vá.
Nếu dự án có Botble hoặc một CMS khác, nhớ kiểm upload, import và cache sau restart. Bài Botble vẫn hiện giao diện cũ sau deploy có thêm checklist phân biệt cache, asset và process cũ; phần đó chỉ hỗ trợ xác minh deploy, không thay thế bản vá PHP.
Chốt việc cần làm hôm nay
Trước tiên, đối chiếu mọi nhánh PHP đang phục vụ web với 8.2.35, 8.3.36, 8.4.27 hoặc 8.5.12. Tiếp theo, nâng qua kênh vendor đáng tin, restart hoặc redeploy đúng lớp, rồi kiểm version từ request path thật và chạy smoke test Laravel. Nếu chưa vá được ngay, dùng mitigation upstream như một cầu tạm có kiểm soát, không gọi đó là fix.
Hai CVE này nằm trong PHP runtime, không phải lỗi của Laravel framework. Vì request độc hại có thể chạm runtime trước logic ứng dụng trong một số mô hình, vá PHP mới là việc ưu tiên; dọn cache hay cập nhật package Composer không đủ.
