Hai lỗi PHP nghiêm trọng: cập nhật WordPress thôi chưa đủ

Ngày 21/10/2026, PHP phát hành bản vá cho CVE-2026-109618 và CVE-2026-109619, hai lỗ hổng có thể cho phép kẻ tấn công chưa đăng nhập thực thi mã trên máy chủ trong những điều kiện nhất định. Điểm đáng lo là lỗi xuất hiện ở tầng chạy ứng dụng: cập nhật WordPress có thể là việc cần làm thường xuyên, nhưng không thay thế được bản vá PHP lần này.

Một số website tại Hà Lan, Đan Mạch, Pháp, Phần Lan và Canada đã tạm ngoại tuyến để phòng ngừa. Đây là lựa chọn giảm thời gian phơi nhiễm khi chưa thể vá ngay, không phải bằng chứng rằng mọi website ngừng hoạt động đều đã bị tấn công.

Lỗi nằm dưới lớp ứng dụng nên bộ lọc thông thường không đủ

Ranh giới cần phân biệt là mã của website và bộ máy thực thi mã đó. WordPress, Drupal hay ứng dụng PHP tự viết đều dựa vào PHP trên máy chủ, nên một website không cài plugin có lỗ hổng vẫn cần được kiểm tra trong đợt cập nhật này.

Với CVE-2026-109618, PHP Foundation mô tả tình huống yêu cầu web chạm ngưỡng memory_limit vào thời điểm bất lợi, để lại dữ liệu nội bộ chưa được khởi tạo đầy đủ nhưng sau đó vẫn bị xử lý như dữ liệu hợp lệ. Hệ quả là bộ nhớ có thể bị hỏng, tạo đường dẫn tới thực thi mã từ xa.

Trên Apache dùng mod_php, đường tấn công đã được chứng minh với thiết lập mặc định và có thể xảy ra trước khi mã ứng dụng bắt đầu chạy. PHP Foundation cũng xác nhận thực thi mã từ xa trên PHP-FPM qua các đường xử lý ở cấp ứng dụng; vì vậy, không thể coi việc dùng PHP-FPM là đủ để loại trừ rủi ro.

CVE-2026-109619 liên quan tới trạng thái cũ còn sót lại sau một lỗi nghiêm trọng, khi trạng thái nội bộ vẫn trỏ tới vùng nhớ thuộc yêu cầu trước đó. Một yêu cầu về sau được cùng tiến trình xử lý có thể sử dụng vùng nhớ đã giải phóng. Lỗi sử dụng bộ nhớ sau giải phóng và tiến trình bị sập đã được xác nhận, còn thực thi mã từ xa được trình diễn trên một ứng dụng thực tế chạy Apache với mod_php.

Hai cơ chế này giải thích vì sao chỉ sửa biểu mẫu tải tệp, bật thêm plugin bảo mật hoặc lọc dữ liệu ở ứng dụng không thể được xem là biện pháp thay thế bản vá. Đặc biệt với đường tấn công xảy ra trước mã ứng dụng, lớp kiểm tra do website tự viết chưa kịp can thiệp.

Bản vá phải khớp với PHP thực sự phục vụ website

Việc cần xác nhận là môi trường đang xử lý yêu cầu web đã nhận bản sửa lỗi, chứ không chỉ là ứng dụng có còn thông báo cập nhật hay không. Theo PHP Foundation, các phiên bản được phát hành để sửa hai lỗi này gồm PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35; điểm CVSS được công bố là 9,2, không phải mức 10 từng lan truyền trước đó.

Phạm vi ảnh hưởng được mô tả là các bản cài PHP phục vụ yêu cầu web, bao gồm cả những nhánh cũ. Tuy nhiên, phạm vi bị ảnh hưởng và phạm vi còn được hỗ trợ là hai việc khác nhau: không thể thấy website vẫn chạy ổn mà suy ra phiên bản PHP cũ sẽ có bản cập nhật trực tiếp từ dự án.

Một số nhà phân phối hoặc nhà cung cấp hỗ trợ dài hạn có thể đưa bản sửa lỗi về nhánh cũ. Với kiểu bảo trì này, quản trị viên nên đối chiếu thông báo gói cập nhật của nhà cung cấp, thay vì chỉ so số phiên bản hiển thị với danh sách phát hành từ PHP. Ngược lại, lời xác nhận chung chung rằng máy chủ đã cập nhật cũng chưa đủ nếu không biết bản vá nào đã được áp dụng.

Đổi sang một nhánh PHP mới còn có thể kéo theo vấn đề tương thích ứng dụng và phần mở rộng. Vì thế, lựa chọn hợp lý là nhận bản vá phù hợp với môi trường đang dùng khi có sẵn, đồng thời xử lý các hệ thống đã hết hỗ trợ thay vì giữ chúng hoạt động vô thời hạn chỉ vì việc chuyển đổi khó khăn.

Website thuê hosting cần làm rõ ai chịu trách nhiệm vá

Với một cửa hàng hoặc doanh nghiệp Việt Nam thuê hosting để chạy WordPress, điểm dễ bỏ sót là quyền cập nhật ứng dụng không đồng nghĩa quyền cập nhật PHP. Chủ website có thể tự nâng phiên bản WordPress, còn gói PHP phục vụ trang lại thuộc phạm vi quản lý của đơn vị hosting.

Câu hỏi nên gửi nhà cung cấp là môi trường PHP của đúng website đã được vá hai mã CVE này chưa, bằng phiên bản hoặc gói cập nhật nào. Nếu tài khoản quản lý nhiều website, cần xác nhận cho từng môi trường liên quan, không suy từ một trang đã được xử lý sang toàn bộ các trang còn lại.

Với máy chủ tự quản trị, nên bắt đầu bằng kiểm kê những dịch vụ PHP đang mở ra Internet rồi áp dụng hướng dẫn cập nhật tương ứng của nhà phân phối. Khi chưa thể vá kịp, tạm ngắt hệ thống có nguy cơ là một lựa chọn phòng ngừa đáng cân nhắc; đánh đổi ở đây là thời gian gián đoạn dịch vụ so với việc tiếp tục để máy chủ chưa được bảo vệ tiếp nhận yêu cầu.

Bản vá cũng không tự trả lời câu hỏi máy chủ đã từng bị xâm nhập hay chưa. Nếu xuất hiện dấu hiệu bất thường, cần tách việc cập nhật khỏi việc điều tra: cô lập hệ thống nghi vấn và bảo toàn nhật ký máy chủ web, nhật ký PHP để phục vụ kiểm tra, thay vì coi trang hoạt động trở lại là dấu hiệu mọi việc đã xong.

Người truy cập thông thường không thể sửa lỗi phía máy chủ bằng cách cập nhật trình duyệt. Phần việc quyết định nằm ở đơn vị vận hành website và nhà cung cấp hạ tầng; với chủ website, xác nhận bản vá PHP cụ thể có giá trị hơn việc chỉ thấy bảng quản trị WordPress báo đã cập nhật đầy đủ.

Nguồn tham khảo: PHP Foundation; WIRED; Engadget.