Kiểm phiên bản PHP của website ngay hôm nay vì hai lỗ hổng chạy mã từ xa đã có bản vá

Website của bạn, hay của cửa hàng bạn thuê người làm, rất có thể chạy PHP (ngôn ngữ lập trình đứng sau WordPress, Magento và nhiều trang bán hàng, tin tức). Ngày 21/10/2026, nhóm PHP công bố cảnh báo bảo mật về hai lỗ hổng mức nghiêm trọng cho phép kẻ lạ chạy mã trên máy chủ mà không cần đăng nhập, kèm bản vá. Việc của bạn hôm nay là biết trang đang chạy bản nào và hỏi đúng người có đã vá chưa.

Điểm tin tuần weekly-roundup-2026-w44 (26/10) đã nhắc bản vá PHP và dòng cấu hình ngày 23/10; bài này thêm các bước kiểm phiên bản và tin nhắn mẫu để hỏi nhà cung cấp.

Năm việc làm theo thứ tự

Ví dụ dựng để minh họa: chị Hoa bán đồ gia dụng trên một website WordPress do anh Tuấn, người làm web thuê ngoài, quản trị, đặt trên gói hosting chung.

1. Hỏi người quản trị site hoặc xem trang quản lý của nhà cung cấp hosting để biết site chạy PHP phiên bản nào. WordPress hiện số này trong mục Tình trạng site (Site Health, Thông tin). Nếu có quyền SSH (đăng nhập dòng lệnh vào máy chủ), gõ php -v; lệnh này cho phiên bản dùng trên dòng lệnh, có thể khác phiên bản web dùng, nên đối chiếu với trang quản lý.
2. So số vừa thấy với các bản đã vá theo thông báo của nhóm PHP: 8.5.12, 8.4.27, 8.3.36, 8.2.35 hoặc cao hơn trong cùng nhánh. Nếu thấp hơn hoặc thuộc 8.1 trở xuống, chuyển sang bước 3.
3. Gửi nhà cung cấp hosting hoặc người quản trị một tin ngắn: “Site của tôi chạy PHP bản nào? Đã có bản vá cho CVE-2026-109618 và CVE-2026-109619 chưa? Nếu đang dùng PHP 8.1 trở xuống, bên anh/chị có bản vá lại cho bản cũ không, hay phải nâng lên bản mới? Sau khi nâng, bên anh/chị đã đặt session.upload_progress.enabled=0 như khuyến nghị của nhóm PHP ngày 23/10 chưa?” Câu thứ ba quan trọng vì số phiên bản cũ có thể đã được vá lại mà số vẫn không đổi, và chỉ nhà cung cấp trả lời được.
4. Ghi lại câu trả lời và ngày nhận. Nếu họ hẹn nâng cấp, hỏi ngày cụ thể và nhờ sao lưu site trước khi nâng, vì plugin (phần cài thêm của WordPress) cũ có thể không chạy trên PHP mới.
5. Sau khi nâng, làm lại bước 1. Dấu hiệu đạt là số phiên bản mới nằm trong danh sách ở bước 2, trang chủ, giỏ hàng, trang đăng nhập vẫn mở bình thường, và nhà cung cấp xác nhận đã tắt session.upload_progress.enabled, hoặc xác nhận ứng dụng không đổi session.serialize_handler lúc chạy.

Phần nền cho các bước trên: theo thông báo trên php.net, hai lỗ hổng là CVE-2026-109618 (CVE là mã định danh chung cho từng lỗ hổng bảo mật, dùng mã này khi hỏi nhà cung cấp; lỗi này do xử lý hết bộ nhớ làm dữ liệu của yêu cầu truy cập bị khởi tạo dở, rồi bước dọn dẹp coi dữ liệu hỏng là hợp lệ) và CVE-2026-109619 (dữ liệu trạng thái của một yêu cầu còn sót lại sau khi vùng nhớ đã được giải phóng, yêu cầu sau dùng nhầm). Cả hai đều cho phép RCE (remote code execution, chạy mã từ xa) mà không cần xác thực. Nhóm PHP viết rằng mọi cài đặt PHP phục vụ yêu cầu web đều có nguy cơ, gồm PHP-FPM, Apache với mod_php, php-cgi, FrankenPHP và LiteSpeed (các cách máy chủ chạy PHP), và rủi ro cao nhất ở mod_php, nơi họ có một mã khai thác chứng minh được yêu cầu của người lạ kích hoạt lỗi trước cả khi mã ứng dụng chạy.

Từ PHP 8.1 trở xuống, dự án không còn phát hành cập nhật; nhóm PHP cho biết một số nhà phân phối Linux và nhà cung cấp hỗ trợ dài hạn tự vá lại cho các bản cũ, và nhóm cũng đưa ra bản vá tối thiểu cho PHP 7.4, 8.0 và 8.1 để ai tự biên dịch từ mã nguồn dùng.

Theo báo Tuổi Trẻ dẫn Reuters và South China Morning Post, nhiều cơ quan chính phủ đã gỡ website khỏi mạng trong lúc chờ vá, và hai lỗ hổng do các công ty an ninh mạng tìm ra với sự hỗ trợ của AI. Wiz, một trong hai công ty đó, ước tính PHP chạy khoảng 70% website toàn cầu.

Ngày 21/10 nhóm PHP nói chỉ bản cập nhật mới là giải pháp đầy đủ; các biện pháp tạm chỉ giảm bớt đường tấn công. Ngày 23/10 nhóm khuyên tắt session.upload_progress.enabled cho tới bản sửa lỗi thường kỳ kế tiếp, để chặn một đường chạy mã từ xa hiếm gặp, kể cả trên bản đã vá. Lỗi này chỉ xảy ra khi ứng dụng đặt session.serialize_handler là php_binary hoặc php_serialize rồi đổi sang php lúc chạy bằng ini_set() trước session_start(), trong khi session upload progress vẫn bật; ai đã tắt từ 21/10 thì giữ nguyên, không cần làm thêm. Người quản trị máy chủ có thể đặt memory_limit=-1 ở cấp máy chủ để ứng dụng không ghi đè được, đặt post_max_size thấp (8M nếu site không cho tải tệp lên, 32M nếu có), và tắt session.upload_progress.enabled rồi khởi động lại mọi tiến trình PHP. Danh sách đầy đủ, kể cả giới hạn ở máy chủ web, nằm trong thông báo gốc; đừng tự sửa nếu bạn không phải người quản trị máy chủ.

Nếu nhà cung cấp không trả lời trong ngày, hoặc cho biết gói của bạn dùng PHP 8.1 trở xuống mà không có bản vá lại, hãy hỏi phương án nâng cấp hoặc chuyển nhà cung cấp, và cân nhắc tạm đóng các trang có đăng nhập hoặc thanh toán trong lúc chờ. Đây là gợi ý của riêng bài, không phải lời khuyên của nhóm PHP.

Nguồn tham khảo

1. php.net, “Security advisory: Critical remote code execution vulnerabilities, update now” (21/10/2026) — nguồn gốc về hai CVE, phiên bản đã vá, phạm vi ảnh hưởng và biện pháp tạm, cùng mục “Informational advisory: Session upload progress” ngày 23/10/2026 trên cùng trang; đây là thông báo chính thức của dự án PHP.
2. Tuổi Trẻ, “Lỗ hổng bảo mật do AI phát hiện khiến loạt website chính phủ nhiều nước ngừng hoạt động” (22/10/2026) — tường thuật việc các cơ quan gỡ website, việc AI hỗ trợ tìm lỗi và ước tính 70% của Wiz, dẫn Reuters và South China Morning Post.
3. Wiz Research blog, “PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet” (21/10/2026) — trang blog Wiz Research liệt kê bài PHP2Shell ngày 21/10/2026 của Sagi Tzadik, Shir Tamari, Nir Ohfeld và Tomer Schwartz; nguồn của ước tính 70%.

Tiếp trên bàn Việc hôm nay: Năm bước rà lại mọi link chia sẻ trợ lý AI bạn đã gửi, sau vụ Muse để tên cuộc trò chuyện nằm trong DNS