Câu hỏi thường gặp
Những phiên bản PHP nào bị ảnh hưởng?
Mọi phiên bản trước 8.5.12, 8.4.27, 8.3.36 và 8.2.35 trong các nhánh được hỗ trợ. PHP 8.1 trở về trước đã hết vòng đời và không nhận bản phát hành nào từ dự án PHP; hãy coi chúng là bị ảnh hưởng trừ khi nhà cung cấp xác nhận có bản vá backport.
Trang web của tôi không hiện phiên bản PHP. Vậy có an toàn không?
Chưa chắc. Ẩn phiên bản (expose_php = Off) là thực hành tốt nhưng không vá được gì. Hãy kiểm tra trên server bằng php -v hoặc hỏi nhà cung cấp của bạn.
Công cụ hiện phiên bản cũ, nhưng nhà cung cấp hosting nói đã vá. Ai đúng?
Có thể cả hai. Các bản phân phối Linux như Debian, Ubuntu và RHEL thường backport bản vá bảo mật mà không đổi số phiên bản. Hãy hỏi nhà cung cấp hosting bản build gói nào đang được cài và changelog của nó có nhắc đến CVE-2026-109618 và CVE-2026-109619 không.
WordPress, Laravel hay CMS của tôi có bị ảnh hưởng không?
Lỗi nằm ngay trong PHP, nên mọi ứng dụng chạy trên bản PHP bị ảnh hưởng đều bị lộ. Các nhà nghiên cứu đã trình diễn tấn công không cần xác thực trên WordPress, Drupal và Joomla, nhưng đó chỉ là ví dụ — ngay cả một trang “Hello World” đơn thuần cũng đủ. Cập nhật WordPress hay plugin không khắc phục được; phải cập nhật PHP.
Dữ liệu có thể bị rò rỉ dù không có mã nào được thực thi không?
Có. CVE-2026-109619 có thể làm lộ bộ nhớ của tiến trình PHP — mật khẩu, token phiên, API key và chứng chỉ từ các yêu cầu khác — mà kẻ tấn công không cần chạy mã. Những vụ rò rỉ như vậy không để lại tệp nào và khó phát hiện, vì vậy hãy thay các thông tin bí mật của mọi trang web đã chạy phiên bản bị ảnh hưởng trên internet.
Tắt session.upload_progress có khắc phục được không?
Không. php.net liệt kê session.upload_progress.enabled=0 là biện pháp giảm thiểu một phần cho một số đường tấn công đã xác nhận của CVE-2026-109619. Nó không bao quát mọi biến thể và hoàn toàn không có tác dụng với CVE-2026-109618.
Web application firewall có đủ không?
WAF hoặc giới hạn yêu cầu có thể giảm mức độ phơi nhiễm trong lúc bạn cập nhật, nhưng vấn đề nằm ở cách PHP xử lý yêu cầu và bộ nhớ. Vẫn bắt buộc phải cập nhật.
Có cần khởi động lại gì sau khi cập nhật không?
Có. PHP-FPM, Apache, LiteSpeed và các worker chạy lâu dài vẫn tiếp tục chạy mã cũ cho đến khi được khởi động lại. Container phải được tạo lại từ image mới.
Công cụ này thực sự làm gì?
Nó gửi một yêu cầu HEAD (hoặc GET nếu HEAD không được phép) đến địa chỉ bạn nhập, theo tối đa ba lần chuyển hướng và đọc các header phản hồi như X-Powered-By và Server. Nó không bao giờ gửi payload khai thác, yêu cầu lớn hay tệp tải lên, và không quét các đường dẫn khác.
Kiểm tra bất kỳ trang web nào có hợp pháp không?
Chỉ kiểm tra các trang web bạn sở hữu hoặc được ủy quyền đánh giá. Yêu cầu giống hệt một lượt truy cập bình thường, nhưng việc sử dụng có trách nhiệm là trách nhiệm của bạn. Chúng tôi giới hạn số lượt kiểm tra theo mạng và theo trang web.
PHP 8.5.12 đã được vá hoàn toàn chưa?
Ngày 22 tháng 10 năm 2026 có các báo cáo về một lỗi crash trong 8.5.12, nhưng chưa được xác nhận là lỗ hổng có thể khai thác từ xa. Chúng tôi theo dõi php.net; nếu có bản phát hành mới, trang này sẽ được cập nhật và ngày “xác minh lần cuối” sẽ thay đổi.
Tôi có thể đọc thông tin chính thức ở đâu?
Trên php.net và trong các thông báo bảo mật GitHub của dự án PHP GHSA-w8hw-w9fx-j79w và GHSA-6wmf-4rv5-p3rp. Nhóm nghiên cứu (Wiz Research, OpenAI Codex Security và Calif) đã công bố kết quả tại php2shell.com.
Ai đã phát hiện các lỗ hổng này?
Các nhà nghiên cứu từ Wiz Research, OpenAI Codex Security và Calif, thông qua quy trình công bố phối hợp với nhóm bảo mật PHP — nhóm đã chuẩn bị các bản vá. Xem bài viết của The PHP Foundation về bản phát hành này.