Lỗ hổng cho phép tin tặc chiếm quyền kiểm soát máy chủ Nginx mà không cần xác thực

Nhóm nghiên cứu bảo mật Pluto Security vừa công bố lỗ hổng CVE-2026-33032 mức độ cực kỳ nghiêm trọng (CVSS 9.8) trong nginx-ui — công cụ quản lý Nginx qua giao diện web phổ biến với hơn 11.000 GitHub stars và hơn 430.000 lượt kéo Docker image. Lỗ hổng xuất phát từ việc endpoint xử lý lệnh MCP bị bỏ sót middleware xác thực, cho phép bất kỳ kẻ tấn công nào trong cùng mạng có thể toàn quyền ghi đè cấu hình và khởi động lại Nginx mà không cần bất kỳ thông tin xác thực nào. Lỗ hổng đã được xác nhận đang bị khai thác tích cực trên thực tế — VulnCheck đã bổ sung CVE-2026-33032 vào danh sách Known Exploited Vulnerabilities (KEV), trong khi Recorded Future's Insikt Group xếp nó vào danh sách 31 CVE có tác động cao nhất bị khai thác tích cực trong tháng 3/2026 với Risk Score 94/100.
Thông tin chi tiết
Định danh lỗ hổng: CVE-2026-33032
Điểm CVSS(3.1): 9.8
Mức độ nghiêm trọng: CRITICAL - Cực kỳ nghiêm trọng
Mô tả tóm tắt: Endpoint
/mcp_messagetrong nginx-ui thiếu middleware xác thựcAuthRequired(), cho phép kẻ tấn công không có thông tin xác thực truy cập toàn bộ 12 MCP tool — bao gồm ghi đè cấu hình Nginx và tự động reload — chỉ bằng một HTTP request thông thường từ bất kỳ host nào trong cùng mạng.Phiên bản bị ảnh hưởng: nginx-ui v2.3.3 và các phiên bản trước đó
nginx-ui là giao diện web phổ biến để quản lý máy chủ Nginx, cho phép người dùng chỉnh sửa cấu hình, quản lý chứng chỉ SSL, theo dõi trạng thái và khởi động lại máy chủ mà không cần SSH trực tiếp. Gần đây, nginx-ui tích hợp thêm hỗ trợ MCP (Model Context Protocol) — một giao thức mới cho phép các AI agent tương tác trực tiếp với ứng dụng thông qua một tập hợp các "tool" được chuẩn hoá. Chính sự tích hợp này đã tạo ra lỗ hổng nghiêm trọng.
MCP trong nginx-ui sử dụng cơ chế truyền tải SSE (Server-Sent Events) thông qua thư viện mcp-go, hoạt động trên hai endpoint riêng biệt: GET /mcp — mở kênh SSE để nhận phản hồi từ server, và POST /mcp_message — nhận và xử lý toàn bộ các lệnh gọi tool theo định dạng JSON-RPC. Khi kết nối, client sẽ nhận một session ID từ /mcp và dùng session ID này để gửi lệnh tới /mcp_message.
Vấn đề nằm ở đây: trong code router của nginx-ui, endpoint /mcp được bảo vệ bởi cả hai middleware IPWhiteList() và AuthRequired(), trong khi endpoint /mcp_message — nơi xử lý toàn bộ các lệnh thực thi nguy hiểm — chỉ có IPWhiteList(), hoàn toàn bỏ sót bước xác thực. Cả hai endpoint đều trỏ về cùng một handler, nhưng chỉ một endpoint được bảo vệ đúng cách.
Lớp bảo vệ duy nhất còn lại là IP whitelist, nhưng bản thân cơ chế này cũng có lỗ hổng thiết kế nghiêm trọng: khi danh sách IP trắng để trống (mặc định trên mọi cài đặt mới), hệ thống tự động cho phép tất cả IP đi qua — một hành vi "fail-open" cực kỳ nguy hiểm. Kết quả là trên hầu hết các triển khai thực tế, cả hai lớp bảo vệ đều vô hiệu hoá, để lộ hoàn toàn 12 MCP tool cho bất kỳ kẻ tấn công nào trong cùng mạng.
12 MCP tool bị lộ bao gồm:
| Tên Tool | Chức năng chính | Mức độ nguy hiểm |
|---|---|---|
| nginx_config_add | Tạo file cấu hình mới và tự động reload nginx | Cho phép modify nginx |
| nginx_config_modify | Chỉnh sửa bất kỳ file cấu hình hiện có | Cho phép modify nginx |
| nginx_config_enable | Bật hoặc tắt các site | Cho phép modify nginx |
| nginx_config_rename | Đổi tên file cấu hình | Cho phép modify nginx |
| nginx_config_mkdir | Tạo thư mục mới | Cho phép modify nginx |
| reload_nginx | Reload cấu hình nginx | Cho phép modify nginx |
| restart_nginx | Khởi động lại tiến trình nginx | Cho phép modify nginx |
| nginx_config_get | Đọc nội dung bất kỳ file cấu hình | Phục vụ reconnaissance |
| nginx_config_list | Liệt kê toàn bộ cấu hình hiện có | Phục vụ reconnaissance |
| nginx_config_base_path | Lấy đường dẫn thư mục cấu hình | Phục vụ reconnaissance |
| nginx_config_history | Xem lịch sử thay đổi cấu hình | Phục vụ reconnaissance |
| nginx_status | Đọc trạng thái máy chủ | Phục vụ reconnaissance |
Đặc biệt nguy hiểm là tool nginx_config_add: tool này không chỉ tạo file cấu hình mới mà còn tự động reload Nginx ngay sau đó — nghĩa là kẻ tấn công có thể chèn cấu hình độc hại và kích hoạt ngay lập tức chỉ bằng một lệnh API duy nhất, không cần bất kỳ thông tin đăng nhập nào.
Để khai thác lỗ hổng, kẻ tấn công chỉ cần thực hiện hai bước: gửi GET /mcp?node_secret=xxx để mở phiên SSE và nhận session ID, sau đó gửi POST /mcp_message?sessionId=xxx để gọi bất kỳ tool nào — hoàn toàn không cần JWT, cookie hay bất kỳ thông tin xác thực nào khác. Từ đó, kẻ tấn công có thể: chặn toàn bộ lưu lượng mạng qua server bằng cách viết lại server block, thu thập thông tin đăng nhập của quản trị viên thông qua directive access_log tùy chỉnh, leo thang đặc quyền bằng cách đánh cắp JWT admin để truy cập API cài đặt nginx-ui, lập bản đồ kiến trúc hạ tầng nội bộ qua các file cấu hình, hoặc đánh sập dịch vụ bằng cách ghi file cấu hình sai cú pháp và trigger reload.
Pluto Security đã xây dựng thành công PoC (Proof-of-Concept) thực hiện toàn bộ chuỗi tấn công — liệt kê 12 tool, đọc file nginx.conf và chèn cấu hình độc hại — từ một máy hoàn toàn tách biệt trong cùng mạng, không cần bất kỳ thông tin xác thực nào.
Theo khảo sát trên Shodan sử dụng favicon hash của nginx-ui, có hơn 2.689 instance nginx-ui đang được public ra Internet, phân bố trên các nhà cung cấp đám mây lớn như Alibaba Cloud, Oracle, Tencent và DigitalOcean — mỗi instance là một mục tiêu tiềm năng của CVE-2026-33032.
Khuyến nghị & Khắc phục
Lỗ hổng CVE-2026-33032 đã được vá trong phiên bản v2.3.4 (phát hành ngày 15/03/2026) bằng cách bổ sung middleware AuthRequired() vào endpoint /mcp_message — đúng như cách /mcp đã được bảo vệ từ trước. Kèm theo bản vá, nhóm phát triển cũng bổ sung regression test kiểm tra cả hai MCP endpoint đều trả về HTTP 403 khi truy cập không có xác thực, nhằm ngăn lỗ hổng tương tự tái xuất hiện trong tương lai.
Đội ngũ FPT Threat Intelligence khuyến nghị người dùng và quản trị viên thực hiện ngay các bước sau:
Cập nhật ngay lập tức nginx-ui lên phiên bản v2.3.4 hoặc mới hơn. Đây là biện pháp duy nhất giải quyết triệt để lỗ hổng.
Nếu chưa thể cập nhật ngay: vô hiệu hoá tính năng MCP hoặc cấu hình IP whitelist chặt chẽ chỉ cho phép các host tin cậy — không để mặc định fail-open.
Rà soát access log của Nginx để phát hiện các thay đổi cấu hình bất thường có thể đã xảy ra trước khi vá lỗi.
Kiểm tra thư mục
conf.d/vàsites-enabled/để phát hiện các file cấu hình lạ hoặc không rõ nguồn gốc.Đối với các nhà phát triển tích hợp MCP: kiểm tra xác thực trên cả hai endpoint SSE và message handler; mặc định cấu hình fail-closed cho IP whitelist; áp dụng cùng tiêu chuẩn bảo mật như với các API đặc quyền nhất trong hệ thống.






