Một lỗ hổng Nginx nghiêm trọng mới được công bố, được theo dõi là CVE-2026-42533, ảnh hưởng đến công cụ script của Nginx. Lỗ hổng này đã tồn tại và có thể bị khai thác âm thầm kể từ tháng 3 năm 2011, thời điểm directive map được bổ sung hỗ trợ biểu thức chính quy (regex).
Lỗ hổng CVE-2026-42533 được báo cáo bởi nhà nghiên cứu bảo mật Stan Shaw cho đội ngũ F5 SIRT. F5 đã phối hợp phát hành một bản vá trong các phiên bản Nginx 1.30.4 (stable) và 1.31.3 (mainline).
Các phiên bản NGINX Plus cũng đã nhận được các bản vá tương ứng: R33–R36 (đã vá trong R36 P7) và 37.0.0.1–37.0.2.1 (đã vá trong 37.0.3.1).
Phân Tích Kỹ Thuật về CVE-2026-42533
Nguồn Gốc Lỗ Hổng Remote Code Execution
CVE-2026-42533 là một lỗ hổng remote code execution (RCE) tiền xác thực. Nguyên nhân sâu xa của lỗ hổng này nằm ở việc thiếu cơ chế lưu/phục hồi trạng thái capture PCRE (Perl Compatible Regular Expressions) trong công cụ script nội bộ của Nginx.
Cụ thể, Nginx đánh giá các biểu thức trong hai lượt:
- LEN pass: Được sử dụng để đo kích thước bộ đệm cần thiết.
- VALUE pass: Dùng để ghi dữ liệu thực tế vào bộ đệm.
Cả hai lượt này đều dựa vào một mảng chia sẻ, có thể thay đổi được gọi là r->captures. Khi một directive map với một mẫu regex được thực thi giữa hai tham chiếu đến một nhóm capture (ví dụ: $1), nó sẽ âm thầm ghi đè lên trạng thái chia sẻ này.
Việc ghi đè này dẫn đến sự không khớp về kích thước giữa LEN pass và VALUE pass, tạo ra hai primitive tấn công riêng biệt.
Các Primitive Tấn Công
Sự không nhất quán giữa LEN pass và VALUE pass tạo ra hai primitive tấn công chính:
- Memory Leak: Kẻ tấn công có thể rò rỉ các byte dữ liệu tùy ý từ bộ nhớ Nginx. Điều này thường được sử dụng để vượt qua các biện pháp bảo vệ như ASLR (Address Space Layout Randomization).
- Write-What-Where: Kẻ tấn công có thể ghi dữ liệu tùy ý vào một vị trí bộ nhớ cụ thể. Đây là primitive mạnh mẽ, có thể dẫn đến việc kiểm soát luồng thực thi của chương trình.
Chuỗi Khai Thác và Độ Tin Cậy
Khi được kết hợp lại, hai primitive này cho phép kẻ tấn công đạt được remote code execution một cách đáng tin cậy.
Theo báo cáo của Cyberstan Cyberstan report, chuỗi khai thác này yêu cầu:
- Khoảng một yêu cầu rò rỉ (leak request).
- Khoảng 40 kết nối spray.
- Và một yêu cầu kích hoạt tràn (overflow-triggering request).
Độ tin cậy khai thác được báo cáo là 10/10 trên Ubuntu 24.04 với ASLR được bật đầy đủ, cho thấy mức độ nghiêm trọng và khả năng thực thi cao của lỗ hổng Nginx này.
Phạm Vi Ảnh Hưởng và Các Directive Liên Quan
Theo phân tích kỹ thuật, lỗ hổng Nginx này không bị giới hạn ở một directive duy nhất. Nó trải rộng trên ít nhất 13 điểm gọi độc lập trên 9 tệp mã nguồn, ảnh hưởng đến cả module HTTP và module stream.
Bất kỳ cấu hình nào kết hợp một nguồn capture regex (như location, server_name, rewrite, hoặc các khối if) với một biến map dựa trên regex được đánh giá sau đó trong cùng một ngữ cảnh yêu cầu, đều có khả năng bị khai thác. Điều này đúng ngay cả khi các directive đó nằm trong các khối location riêng biệt.
Các directive thường bị ảnh hưởng bao gồm:
location ~ ^/path/(.*)server_name ~^(?<subdomain>.+)\.example\.com$rewrite ^/old/(.*) /new/$1 permanent;if ($uri ~ ^/regex/(.*)) { ... }
Một biến thể khai thác độc lập khác tồn tại thông qua các nhóm capture có tên ((?P<name>...)). Các nhóm này được cache khác nhau và sẽ không được khắc phục bởi các bản vá chỉ giải quyết các capture được đánh số. Đây là một điểm quan trọng cần lưu ý khi đánh giá và vá lỗi.
Phân Biệt với Các Lỗ Hổng Nginx Khác
Điều đáng chú ý là các bản vá gần đây cho các lỗi Nginx khác, bao gồm CVE-2026-42945, CVE-2026-9256, CVE-2026-42055 và CVE-2026-48142, không giải quyết được vấn đề này.
Điều đó có nghĩa là các tổ chức đã vá các lỗ hổng đó vẫn còn đối mặt với nguy cơ bị khai thác bởi CVE-2026-42533. Việc này nhấn mạnh tầm quan trọng của việc cập nhật toàn diện và không chỉ dựa vào các bản vá riêng lẻ.
Bối Cảnh Lịch Sử và Tầm Quan Trọng
Hành vi phức tạp này đã được cảnh báo lần đầu tiên hơn một thập kỷ trước, vào năm 2014, trong một ticket trac của Nginx. Tại thời điểm đó, nhà phát triển Maxim Dounin đã thừa nhận đây là một lỗi.
Tuy nhiên, vấn đề này chưa bao giờ được khắc phục hoàn toàn như một vấn đề bảo mật nghiêm trọng cho đến nay. Sự chậm trễ này làm nổi bật thách thức trong việc xác định và đánh giá đúng mức độ rủi ro của các lỗi kỹ thuật.
Giải Pháp Giảm Thiểu và Công Cụ Phát Hiện
Để hỗ trợ các nhà quản trị hệ thống và chuyên gia bảo mật, nhà nghiên cứu đã phát hành một công cụ quét cấu hình tĩnh trên GitHub: 0xCyberstan/CVE-2026-42533-Config-Scanner.
Công cụ này có khả năng xác định các thứ tự directive dễ bị tổn thương mà không cần thực hiện khai thác. Điều này cung cấp cho các nhà phòng thủ một cách ngay lập tức để kiểm tra mức độ tiếp xúc với lỗ hổng Nginx và thực hiện các biện pháp khắc phục.
Đoạn mã ví dụ cho việc quét cấu hình có thể được thực hiện thông qua CLI sau khi cài đặt công cụ:
./nginx-config-scanner /etc/nginx/nginx.conf
Kết quả sẽ hiển thị các vị trí tiềm năng trong cấu hình Nginx có thể dẫn đến khai thác RCE.
Cập Nhật Bản Vá Bảo Mật
Biện pháp khắc phục hiệu quả nhất là cập nhật Nginx lên các phiên bản đã vá lỗi:
- Nginx (stable): Phiên bản 1.30.4 trở lên.
- Nginx (mainline): Phiên bản 1.31.3 trở lên.
- NGINX Plus R33–R36: Cập nhật lên R36 P7.
- NGINX Plus 37.0.0.1–37.0.2.1: Cập nhật lên 37.0.3.1.
Quản trị viên cần ưu tiên áp dụng các bản vá bảo mật này càng sớm càng tốt để bảo vệ hệ thống khỏi nguy cơ remote code execution.
Thông tin chi tiết về CVE-2026-42533 có thể được tìm thấy trên Cổng thông tin lỗ hổng quốc gia Hoa Kỳ (NVD) tại nvd.nist.gov khi thông tin được công bố chính thức.
Tác giả lỗ hổng đã quyết định giữ lại mã khai thác (PoC) và tài liệu chi tiết trong 21 ngày sau khi bản vá được phát hành. Quyết định này được đưa ra dựa trên tốc độ vũ khí hóa nhanh chóng được ghi nhận sau khi CVE-2026-42945 (“NGINX Rift”) được công bố rộng rãi, nhằm cung cấp thời gian cần thiết cho các nhà quản trị cập nhật hệ thống.
