F5 phát hành bản vá khẩn cho các lỗ hổng NGINX có thể dẫn đến DoS và thực thi mã

F5 đã phát hành bản cập nhật bảo mật ngoài chu kỳ cho NGINX sau khi ghi nhận nhiều lỗ hổng mới trong các thành phần xử lý HTTP/3, proxy và gRPC. Vấn đề đáng chú ý là một số lỗi có thể bị khai thác từ xa, không cần xác thực, trong các cấu hình không mặc định và có khả năng dẫn đến gián đoạn dịch vụ hoặc thực thi mã trong điều kiện nhất định.

Thông tin này đáng chú ý vì NGINX là một trong những nền tảng web server, reverse proxy và gateway phổ biến trong hạ tầng doanh nghiệp. Với các hệ thống internet-facing, rủi ro không chỉ nằm ở bản thân lỗ hổng mà còn ở tốc độ rà soát cấu hình, cập nhật phiên bản và xác định dịch vụ nào đang bật các module liên quan.

Các lỗ hổng chính được công bố

Theo danh sách advisory chính thức của NGINX, CVE-2026-42530 là lỗi use-after-free trong module HTTP/3. NGINX ghi nhận các phiên bản không bị ảnh hưởng là 1.31.2 trở lên, trong khi nhánh 1.31.0 đến 1.31.1 nằm trong vùng rủi ro nếu cấu hình liên quan được kích hoạt.

Lỗ hổng CVE-2026-42055 liên quan đến ngx_http_proxy_v2_module và ngx_http_grpc_module. NGINX cho biết các phiên bản 1.31.2 trở lên và 1.30.3 trở lên không bị ảnh hưởng, còn các phiên bản từ 1.13.10 đến 1.31.1 cần được rà soát theo advisory. BleepingComputer dẫn thông tin từ F5 cho biết việc khai thác thành công có thể gây khởi động lại worker process và trong một số điều kiện như ASLR bị vô hiệu hóa hoặc bị vượt qua, có thể dẫn tới thực thi mã.

Vì sao các cấu hình không mặc định vẫn cần được ưu tiên

Nhiều tổ chức có xu hướng đánh giá thấp các lỗ hổng chỉ ảnh hưởng đến cấu hình không mặc định. Tuy nhiên, trong môi trường sản xuất, cấu hình NGINX thường được tùy biến sâu để phục vụ HTTP/3, gRPC, reverse proxy, cân bằng tải, API gateway hoặc kiến trúc microservices. Điều này khiến câu hỏi quan trọng không phải là hệ thống có dùng NGINX hay không, mà là module nào đang bật và phiên bản nào đang chạy ở từng lớp hạ tầng.

HTTP/3 và gRPC ngày càng phổ biến trong các dịch vụ cần độ trễ thấp hoặc giao tiếp giữa nhiều thành phần backend. Khi lỗi nằm ở tầng xử lý giao thức hoặc header, rủi ro có thể lan tới các dịch vụ tưởng như chỉ đóng vai trò trung gian, đặc biệt nếu chúng nằm trước nhiều ứng dụng nội bộ.

Tác động đối với đội vận hành và bảo mật

Tác động trực tiếp nhất là nguy cơ từ chối dịch vụ, khiến worker process của NGINX bị restart và ảnh hưởng đến khả năng phục vụ truy cập. Với hệ thống có lưu lượng cao, sự cố lặp lại có thể tạo ra hiệu ứng dây chuyền: gateway quá tải, backend bị dồn kết nối, giám sát sinh cảnh báo nhiễu và đội vận hành khó phân biệt giữa lỗi cấu hình, lưu lượng bất thường và khai thác có chủ đích.

Khả năng thực thi mã, dù phụ thuộc vào điều kiện bổ sung, vẫn là tín hiệu cần xử lý nghiêm túc. Các máy chủ reverse proxy thường có quyền truy cập tới nhiều vùng mạng, token dịch vụ, log nhạy cảm hoặc backend nội bộ. Vì vậy, bản vá cho NGINX không nên được xem là tác vụ bảo trì thông thường, mà là một phần của quy trình giảm thiểu rủi ro hạ tầng.

Recommended response

Quản trị viên nên lập danh sách toàn bộ máy chủ, container image, ingress controller, gateway hoặc appliance có sử dụng NGINX, sau đó đối chiếu với advisory chính thức. Các hệ thống chạy NGINX Open Source nên ưu tiên cập nhật lên 1.31.2 hoặc 1.30.3 tùy nhánh phù hợp. Với NGINX Plus, NGINX Gateway Fabric và các sản phẩm liên quan, cần theo dõi hướng dẫn riêng từ F5.

Trong thời gian chờ cập nhật, đội vận hành nên rà soát việc bật HTTP/3, gRPC proxy, proxy protocol và các thiết lập header có liên quan. Những cấu hình không cần thiết nên được tắt hoặc giới hạn ở phạm vi nội bộ. Log truy cập, log lỗi và tín hiệu restart worker process cũng cần được theo dõi để phát hiện các mẫu request bất thường.

Bài học cho quản trị hạ tầng web

Sự kiện này cho thấy một điểm quen thuộc trong an ninh hạ tầng: thành phần càng phổ biến, tác động của một lỗi cấu hình càng rộng. NGINX thường nằm ở lớp đầu vào của hệ thống, nên việc kiểm kê phiên bản, module và cấu hình thực tế cần được duy trì liên tục thay vì chỉ thực hiện khi có cảnh báo lớn.

Với các tổ chức vận hành nhiều môi trường, cách tiếp cận hiệu quả là kết hợp quản lý tài sản, quét cấu hình, kiểm soát image build và quy trình cập nhật có thể rollback. Khi có bản vá ngoài chu kỳ từ nhà cung cấp, đội bảo mật cần nhanh chóng chuyển advisory thành danh sách hệ thống bị ảnh hưởng, mức ưu tiên xử lý và tiêu chí xác minh sau cập nhật.

VNCyberS tổng hợp từ BleepingComputer, F5 và NGINX