PHP vá khẩn CVE-2026-109618 và CVE-2026-109619: Cập nhật ngay
PHP phát hành bản vá khẩn cho CVE-2026-109618 và CVE-2026-109619. Xem phiên bản đã sửa và cách kiểm tra runtime web, hosting, worker sau cập nhật.
Bởi Võ Danh — 22 Tháng 10, 2026 trong Bảo mật
PHP vừa phát hành bản vá khẩn cho CVE-2026-109618 và CVE-2026-109619, hai lỗ hổng nghiêm trọng có thể cho phép thực thi mã từ xa mà không cần đăng nhập khi đáp ứng điều kiện khai thác. Các bản đã sửa là PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35, công bố ngày 21/10/2026. Nếu đang vận hành website PHP, đây là việc cần ưu tiên ngay, không nên chờ đến kỳ bảo trì định kỳ tiếp theo.[1]
Phạm vi cảnh báo rộng hơn một plugin hay một framework. PHP liệt kê các môi trường phục vụ yêu cầu web gồm PHP-FPM, Apache với mod_php, php-cgi, FrankenPHP và LiteSpeed. Nhóm phát triển đánh giá rủi ro cao nhất ở mod_php: đã có minh chứng khai thác không cần xác thực, xảy ra trước khi mã ứng dụng bắt đầu chạy.[1] Tuy vậy, cảnh báo này không có nghĩa mọi máy chủ đều chắc chắn khai thác được theo cùng một cách, hoặc website của bạn đã bị xâm nhập.
CVE-2026-109618 và CVE-2026-109619 nguy hiểm ở đâu?
Cả hai advisory chính thức đều chấm mức Critical, CVSS v4.0 là 9.2/10. Không phải 10/10 như một số thông tin lan truyền trước lúc công bố. Điểm số đi kèm các điều kiện về độ phức tạp và môi trường triển khai; nó không phải xác suất một website cụ thể sẽ bị tấn công.[3][4][5]
Với CVE-2026-109618, vấn đề nằm ở cách PHP xử lý tình huống cạn bộ nhớ, gọi là out-of-memory hay OOM. Một yêu cầu có thể bị ngắt khi dữ liệu nội bộ còn khởi tạo dang dở. Đến lúc dọn dẹp, PHP lại xử lý phần dữ liệu chưa hợp lệ ấy như dữ liệu bình thường, tạo khả năng hỏng bộ nhớ và thực thi mã.[3]
Advisory xác nhận thực thi mã từ xa qua HTTP trên mod_php với giới hạn bộ nhớ, đầu vào mặc định và cấu hình nhiều worker thông thường. Riêng advisory OOM đánh giá FPM có khả năng bị ảnh hưởng dựa trên phân tích mã nguồn, nhưng chưa trình diễn được chuỗi khai thác FPM hoàn chỉnh cho lỗi đó. Không nên lấy kết luận này để nói PHP-FPM an toàn trước cả hai CVE.[3]
CVE-2026-109619 liên quan đến trạng thái toàn cục cũ còn sót lại trong worker. Bộ nhớ của yêu cầu trước đã được giải phóng nhưng một tham chiếu vẫn còn; yêu cầu sau trên cùng worker có thể sử dụng lại nó trước khi khởi tạo thông thường kịp đặt lại trạng thái. Advisory mô tả trường hợp thực thi mã đã được xác nhận ở mod_php và đường khai thác vòng đời session đã được kiểm chứng trên cả mod_php lẫn FPM, với những điều kiện ứng dụng tương ứng.[4]
Đọc đến đây, điều cần giữ lại là: đổi từ Apache sang FPM không thay thế bản vá. Tăng số worker cũng không xóa nguyên nhân. Tác động thực thi mã được xác nhận với quyền của tài khoản chạy web worker; đừng tự động diễn giải thành quyền root trên mọi hệ thống.[3][4]
Đang dùng PHP nhánh nào thì cập nhật lên đâu?
Mốc phiên bản upstream được PHP công bố như sau:[1]
- Nhánh PHP 8.2: cập nhật lên 8.2.35.
- Nhánh PHP 8.3: cập nhật lên 8.3.36.
- Nhánh PHP 8.4: cập nhật lên 8.4.27.
- Nhánh PHP 8.5: cập nhật lên 8.5.12.
Đây là các bản đầu tiên sửa hai lỗi trong những nhánh này. Hãy dùng bản đã vá hoặc bản mới hơn được nhà cung cấp xác nhận chứa bản sửa, lấy từ kênh phân phối tin cậy. Với hệ điều hành Linux doanh nghiệp, số phiên bản gốc có thể trông cũ nhưng gói đã được backport bản vá. Cần đối chiếu đúng mã gói, phiên bản phát hành của distro và advisory/changelog ghi hai CVE, thay vì kết luận chỉ từ một dòng phiên bản.[1]
PHP 8.1 trở về trước không còn được dự án PHP cấp bản cập nhật chính thức. Một số nhà cung cấp distro hoặc dịch vụ hỗ trợ dài hạn vẫn có bản sửa riêng. Do tính nghiêm trọng của đợt này, nhóm bảo mật cung cấp bản vá mã nguồn tối thiểu cho PHP 7.4, 8.0 và 8.1; đó không phải thông báo khôi phục hỗ trợ đầy đủ cho các nhánh đã hết vòng đời. Nếu không có đơn vị hỗ trợ đáng tin cậy, hãy lập kế hoạch chuyển sang nhánh còn được hỗ trợ.[1][2]
PHP cũng cho biết nhánh 8.2 kết thúc vòng đời ngày 31/12/2026. Vá 8.2.35 giải quyết việc cấp bách hôm nay, nhưng không nên biến thành lý do trì hoãn kế hoạch nâng cấp dài hạn. Bản PHP 8.6.0 RC4 có chứa bản sửa song vẫn là bản thử nghiệm, không phải lối tắt để đưa lên production.[1]
Checklist cập nhật: kiểm tra đúng PHP mà website đang chạy
Phần dưới là checklist vận hành an toàn, không phải kết quả kiểm thử trên máy chủ của bạn. Không có dữ liệu cấu hình host thì không thể khẳng định một website cụ thể đang có lỗ hổng hay đã sạch lỗi.
- Kiểm kê toàn bộ runtime. Ghi lại từng website, virtual host, pool FPM, container, máy ảo và nút sau load balancer. Đừng bỏ quên website cũ ít truy cập nhưng vẫn mở ra Internet. Xác định nơi lấy gói PHP và người có quyền cập nhật.
- Đối chiếu CLI với môi trường web. Các lệnh chỉ đọc như
php -vvàphp --inigiúp xem PHP dòng lệnh và tệp cấu hình CLI, không chứng minh FPM hoặc Apache đang dùng cùng bản. Dùng bảng quản trị hosting, thông tin dịch vụ hoặc công cụ quản trị nội bộ để kiểm tra runtime phục vụ đúng tên miền. - Chuẩn bị đường khôi phục. Sao lưu dữ liệu, cấu hình và ghi lại phiên bản gói hiện tại. Kiểm tra khả năng tương thích trên staging nếu có, ưu tiên những luồng đăng nhập, thanh toán, upload, tác vụ nền và extension đang dùng. Chọn cách triển khai phù hợp mức phơi nhiễm, thay vì hoãn vô thời hạn vì muốn mọi thứ hoàn hảo.
- Cài gói đã sửa từ nguồn chính thức. Với distro, lưu lại mã gói và liên kết advisory xác nhận backport. Với container, kéo hoặc dựng lại image đã sửa, triển khai lại các instance thực sự chạy dịch vụ; chỉ cập nhật image trên registry chưa thay thế container cũ đang hoạt động.
- Khởi động lại đúng tiến trình. Tổ chức restart hoặc thay thế toàn bộ worker theo quy trình của nền tảng. Kiểm tra từng pool và từng nút sau triển khai để tránh còn worker cũ tiếp tục phục vụ. Tên dịch vụ khác nhau giữa các máy nên không nên sao chép một lệnh restart chung rồi coi như xong.
- Kiểm tra sau thay đổi. Đọc lại phiên bản runtime web hoặc bằng chứng gói đã vá, thử các luồng nghiệp vụ quan trọng và quan sát lỗi 5xx, crash, hàng đợi, thời gian phản hồi. Ghi nhận giờ hoàn tất cùng người chịu trách nhiệm để ca trực sau không phải đoán.
Nếu cần tạo trang chẩn đoán tạm thời, hãy giới hạn truy cập và xóa ngay sau khi kiểm tra. Không công khai phpinfo() chỉ để chụp một dòng phiên bản: thông tin cấu hình không cần trở thành phần thưởng thêm cho người ngoài.
Dùng WordPress hoặc shared hosting thì làm gì?
Cập nhật WordPress, theme và plugin vẫn cần thiết, nhưng không thay được bản vá trong runtime PHP. Mã ứng dụng nằm ở lớp khác; riêng đường khai thác mod_php đã được PHP mô tả có thể xảy ra trước khi mã ứng dụng chạy.[1][3] Một website hiển thị mọi plugin đều mới nhất chưa đủ để đóng cảnh báo này.
Với shared hosting, hãy gửi ticket có đủ hai mã CVE và hỏi nhà cung cấp: tên miền của tôi đang dùng nhánh PHP nào, gói nào chứa bản sửa, thời điểm nào đã thay thế worker cũ? Nếu họ áp dụng backport, đề nghị liên kết advisory hoặc changelog và phiên bản gói cụ thể. Câu trả lời “đã bật WAF” không tương đương xác nhận runtime đã vá.
Không nên tự đổi phiên bản PHP trong control panel sang một lựa chọn chưa kiểm tra tương thích. Hãy phối hợp với bên vận hành, thử nhanh các chức năng quan trọng và xác nhận chính tên miền đang trỏ vào runtime mới. Với người thuê VPS có quản trị, trách nhiệm cập nhật có thể thuộc nhà cung cấp hoặc khách hàng tùy hợp đồng; cần chốt rõ thay vì để cả hai bên cùng chờ.
Các cảnh báo ứng dụng khác như lỗ hổng WordPress CVE-2026-87902 hay vấn đề ở Ninja Forms và WPC Product Bundles vẫn cần xử lý độc lập. Vá một lớp không làm các lớp còn lại tự được bảo vệ.
Chưa thể nâng cấp ngay: chỉ giảm phơi nhiễm, không phải đã an toàn
PHP nhấn mạnh không có cấu hình giảm thiểu hoàn chỉnh; cập nhật là giải pháp đầy đủ. Advisory đưa ra các biện pháp tạm thời cho từng đường tấn công, không phải một công thức miễn nhiễm.[1][3][4] Nếu bạn không trực tiếp quản trị hệ thống, hãy chuyển phần này cho đội vận hành thay vì sửa cấu hình theo cảm tính.
Với lỗi trạng thái cũ, PHP hướng dẫn tắt session.upload_progress.enabled ở cấu hình có hiệu lực trước khi phân tích request rồi khởi động lại mọi worker. PHP 8.5 có thêm biện pháp tắt fatal_error_backtraces. Các bước này chỉ chặn những đường đã xác nhận tương ứng, không bao phủ tất cả biến thể. Không dựa vào ini_set() hay FPM .user.ini để thay thế cấu hình sớm mà thông báo yêu cầu.[1][4]
Với lỗi OOM, thông báo có đề cập đặt và cưỡng chế memory_limit=-1, đi kèm giới hạn kích thước đầu vào ở lớp trước PHP và ranh giới tài nguyên phù hợp. Không nên hiểu thành lời khuyên cứ gỡ giới hạn bộ nhớ cho mọi website: cách này có rủi ro vận hành, vẫn không chặn được lỗi cấp phát bên dưới và không thay thế bản vá. Người vận hành phải đọc đầy đủ advisory, đánh giá tài nguyên, tính sẵn sàng và quyền ghi đè cấu hình trước khi áp dụng.[1][3]
Ẩn thông báo bằng display_errors, error_reporting hoặc toán tử @ không ngăn việc truy cập trạng thái cũ. Việc rà soát fatal error, timeout và cấu hình lỗi có thể giảm phơi nhiễm, nhưng log không thấy dấu hiệu cũng không chứng minh máy chủ an toàn.[4]
Đã bị khai thác ngoài thực tế chưa?
Cần tách ba chuyện: lỗi có thể khai thác, nhà nghiên cứu đã chứng minh khai thác và kẻ xấu đang khai thác hệ thống ngoài thực tế. Hai advisory xác nhận những đường thực thi mã cụ thể. PHP Foundation cho biết tại thời điểm phát hành/công bố, nhóm bảo mật đã theo dõi các PoC xuất hiện nhưng chưa xác định được exploit hoạt động trong số đó.[3][4][5]
Thông tin này không chứng minh Internet hiện không có tấn công, cũng không phải xác nhận đã có chiến dịch khai thác diện rộng. Bài viết được kiểm chứng ngày 22/10/2026 theo các nguồn chính thức bên dưới; không gắn nhãn “đang bị khai thác” khi các nguồn được kiểm tra chưa đủ căn cứ. Bạn vẫn nên vá khẩn vì mức độ tác động và khả năng khai thác đã được xác nhận, chứ không cần chờ một thông báo nạn nhân mới hành động.
Nếu phát hiện crash bất thường, tệp lạ, tiến trình hoặc kết nối đáng ngờ, hãy giữ log và bằng chứng, chuyển sang quy trình ứng cứu thay vì chỉ cập nhật rồi xóa dấu vết. Bản vá ngăn nguyên nhân đã biết; nó không tự gỡ quyền truy cập mà kẻ tấn công có thể đã thiết lập trước đó. Việc có xâm nhập hay không cần điều tra trên chính môi trường của bạn.
Việc cần chốt hôm nay là một bằng chứng cụ thể: đúng runtime web đã dùng bản chứa sửa lỗi, mọi worker cũ đã được thay thế và chức năng quan trọng vẫn hoạt động. Dòng “đã chạy cập nhật” trong nhóm chat chưa phải bằng chứng đó.
Nguồn kiểm chứng
