Lỗ hổng NGINX: nguyên nhân, cách khắc phục và xác minh sản xuất

Ngày viết lịch sử: 2026-10-14 (ngày tiết lộ và phát hành bảo mật). Nguồn được kiểm tra và bổ sung thông tin thông qua 2026-10-27.

Bài viết này được lưu trữ theo ngày diễn ra sự kiện; phiên bản và bản cập nhật phát hành được phát hành sau ngày 14 tháng 10 được bao gồm bên dưới. Đối tượng: Trang web NGINX Open Source / NGINX Plus và nhân viên vận hành và bảo trì proxy ngược, nhân viên phản hồi bảo mật, người bảo trì phân phối cũng như các kỹ sư tự biên dịch NGINX và duy trì các mô-đun của bên thứ ba.

Bài viết này tập trung vào năm lỗ hổng cốt lõi NGINX đã được tiết lộ và khắc phục chuyên sâu vào ngày 14 tháng 10 năm 2026, đồng thời xem xét các lỗ hổng bảo mật tiêu biểu về an toàn bộ nhớ và tính toàn vẹn yêu cầu từ tháng 5 đến tháng 9 năm 2026. Nội dung bao gồm các điều kiện kích hoạt, nguyên nhân cấp mã, phạm vi tác động, quy trình khắc phục, các biện pháp giảm thiểu ngắn hạn, triển khai bản vá chính thức, chuyển ngược sang các nhánh cũ hơn và xác minh sản xuất. Các tài liệu tham khảo như S1 liên kết với phụ lục nguồn. Cấu hình ví dụ chỉ được sử dụng để minh họa cho các ý tưởng triển khai và kiểm tra, đồng thời cần được xác minh dựa trên phiên bản thực tế, tính kế thừa cấu hình, sự phụ thuộc và năng lực kinh doanh trước khi triển khai.

TL;DR: Hành động ưu tiên

1. Ưu tiên nâng cấp bảo mật. Đối với các gói Mã nguồn mở nginx.org, hãy cập nhật nhánh Stable 1.30 lên ít nhất là 1.30.6 và nhánh Mainline 1.31 lên ít nhất là 1.31.7.. Tại ngày xác minh, 1.31.8 là phiên bản mới nhất Bản phát hành Mainline. Đây là những đường cơ sở của nhánh riêng biệt; đừng so sánh số lượng của họ giữa các chi nhánh. S1S2
2. Xác minh cài đặt phân phối bằng phiên bản gói đầy đủ. Ubuntu 22.04 / 24.04 / 26.04 / 26.10 có backport của nhà cung cấp; Debian 13 (trixie) yêu cầu ít nhất 1.26.3-3+deb13u10. Khi xác minh, gói Debian 12 (bookworm) 1.22.1-9+deb12u10 vẫn được đánh dấu là bị ảnh hưởng. Kiểm tra từng CVE; tư vấn Debian 13 không chứng minh rằng Debian 12 đã được sửa. S13S14S15
3. Kiểm tra năm kết hợp cấu hình: alias + rewrite + $request_filename, map + biểu thức chính quy + đánh giá biến, aio + ssi + include virtual, HTTP/3 với proxy_request_buffering on và ssl_session_cache shared:... với tính năng xoay khóa Vé phiên TLS tự động. Chỉ sự hiện diện của một lệnh không tạo nên khả năng khai thác; đánh giá đường dẫn yêu cầu và phạm vi cấu hình. S1S3S4
4. Thay thế tất cả các quy trình và vùng chứa cũ. Chạy nginx -t, sau đó khởi động lại dịch vụ hoặc thực hiện triển khai luân phiên có tính sẵn sàng cao. Xác nhận rằng các quy trình master/worker cũ đã thoát; Riêng nginx -s reload không chứng minh được rằng tệp nhị phân đang chạy đã thay đổi.
5. Xác minh các điểm cuối thực tế: HTTP/1.1, HTTP/2, HTTP/3 nếu được bật, tải lên qua proxy và nội dung yêu cầu API, xác thực chứng chỉ mTLS, trang SSI và nhật ký truy cập. Ghi lại nguồn gốc, phiên bản, thông báo hình ảnh, quá trình đang chạy và kết quả của gói cho từng điểm cuối.
6. Nếu không thể nâng cấp ngay lập tức, hãy xóa các điều kiện kích hoạt hiện hành: vô hiệu hóa các tham chiếu biến SSI/AIO hoặc HTTP/3 không cần thiết, xem xét các tham chiếu biến alias/rewrite/map dễ bị tổn thương và đánh giá ssl_session_tickets off; tạm thời để biết mTLS bị ảnh hưởng dịch vụ. WAF, ASLR, giới hạn tốc độ và thay đổi cấu hình chỉ bao gồm một số điều kiện và không thể thay thế các bản vá chính thức. S3S4S8S12

1. Tổng quan về lỗ hổng và đánh giá rủi ro

NGINX đã phát hành 1.30.6 (Stable) và 1.31.7 (Mainline) vào ngày 14 tháng 10 năm 2026, khắc phục 5 vấn đề bảo mật. Ba liên quan đến lỗi tràn heap hoặc use-after-free và nhận được điểm F5 CVSS v4.0 là 9.2 / Quan trọng. Hai cái còn lại ảnh hưởng đến tính toàn vẹn của yêu cầu HTTP/3 và xác thực chứng chỉ ứng dụng khách TLS. S1S2S3

Phân biệt các hệ thống xếp hạng: nginx.org liệt kê tất cả năm vấn đề là medium, trong khi F5 CVSS v4.0 và một số cơ quan an ninh quốc gia phân loại ba vấn đề bộ nhớ là Quan trọng. Điều này không có nghĩa là cả năm đều cho phép thực thi mã từ xa vô điều kiện. Cấu hình, khả năng tiếp cận lưu lượng truy cập và các điều kiện nằm ngoài tầm kiểm soát của kẻ tấn công. Lỗi bộ nhớ và RCE đáng tin cậy là các mức độ bằng chứng khác nhau. S1S3S4

CVE	Sự cố kỹ thuật và điều kiện kích hoạt điển hình	tác động cốt lõi	Đánh giá và xử lý
CVE-2026-15176	Ánh xạ đường dẫn alias + thay đổi rewrite URI + đánh giá $request_filename	Tràn bộ đệm heap, sự cố Worker; tiềm năng RCE trong những điều kiện nhất định	F5 CVSS v4.0 9.2; ưu tiên xử lý sự cố
CVE-2026-93479	Đánh giá tập lệnh HTTP/Stream, đặc biệt là thu thập biểu thức chính quy map và thư mục root, tham chiếu chéo biến nhật ký	Bộ đệm dành riêng bị ghi đè và vùng heap tràn; tiềm năng RCE trong những điều kiện nhất định	F5 CVSS v4.0 9.2; là rủi ro hồi quy sau lần sửa chữa trước đó
CVE-2026-97205	SSI ảo bao gồm và AIO/hoạt động không đồng bộ; tràn số lượng hoạt động chưa xử lý	Sử dụng sau khi miễn phí, Worker gặp sự cố, hỏng bộ nhớ; tiềm năng RCE	F5 CVSS v4.0 9.2; yêu cầu cấu hình không mặc định
CVE-2026-95101	HTTP/3 Khung không xác định bị phân mảnh trên các bộ đệm, tính năng đệm nội dung yêu cầu proxy được bật	Chèn không chính xác các byte không phải DATA vào nội dung yêu cầu ngược dòng, có thể bỏ qua giới hạn kích thước nội dung yêu cầu	Lỗ hổng này ảnh hưởng đến tính toàn vẹn của yêu cầu. Bản thân nó không cung cấp khả năng thực thi mã từ xa (RCE).
CVE-2026-97629	Bộ đệm phiên TLS được chia sẻ, xoay khóa tự động và phản chiếu khóa Worker	Giả mạo vé phiên; việc bỏ qua xác thực chứng chỉ ứng dụng khách có thể xảy ra đối với dịch vụ mTLS bị ảnh hưởng	Cần đặc biệt chú ý đến tác động kinh doanh của loại xác thực chứng chỉ API

Điểm CVSS ở trên được F5 đưa ra bằng cách sử dụng v4.0; cùng một lỗ hổng có thể cho thấy mức độ nghiêm trọng khác nhau trong CVSS 3.1, nginx.org có các cấp độ và xếp hạng mức độ nghiêm trọng phân phối khác nhau. S1S3S4

1.1 Ưu tiên hiển thị triển khai thay vì chỉ điểm CVE

Hình thức triển khai	Các điểm điều tra chính	Khuyến nghị ưu tiên xử lý
Proxy đảo ngược mạng công cộng, bao gồm rewrite, alias tùy chỉnh và map phức tạp	CVE-2026-15176, CVE-2026-93479 và viết lại/lập bản đồ các lỗ hổng từ tháng 5 đến tháng 7	P0: Kiểm tra và cập nhật ngay
API / Mặt phẳng quản lý sử dụng chứng chỉ ứng dụng khách làm xác thực lối vào chính hoặc duy nhất	Vé phiên và cấu hình bộ đệm chia sẻ của CVE-2026-97629	P0: Xác nhận ngay ranh giới xác thực và cập nhật
Cung cấp tải lên HTTP/3 bên ngoài, giao diện thay đổi trạng thái, lớp giao dịch API	CVE-2026-95101, đặc biệt là phần thân yêu cầu được ủy quyền cho phần phụ trợ	P0/P1: Sắp xếp theo mức độ quan trọng của doanh nghiệp
SSI Trang động hoặc I/O tệp không đồng bộ	CVE-2026-97205	P1: Xác nhận tình trạng kết hợp và sửa chữa càng sớm càng tốt
Chỉ các trang tĩnh + proxy ngược HTTP/1.1/2 đơn giản	Cấu hình và phiên bản vẫn cần được kiểm tra nhưng có thể thiếu một số điều kiện CVE	P1: Có trong cửa sổ nâng cấp bảo mật khẩn cấp
Sử dụng Cộng đồng Kubernetes đã ngừng hoạt động ingress-nginx	Dự án dừng bảo trì bảo mật và rủi ro không giới hạn ở năm CVE này	Lập kế hoạch di chuyển bộ điều khiển riêng lẻ

P0/P1 là các đề xuất xử lý khi vận hành và bảo trì được đưa ra trong bài viết này đối với mức độ nhạy cảm của chứng nhận và khả năng tiếp xúc với mạng công cộng. Nó không phải là phân loại CVSS chính thức và cũng không nên thay thế đánh giá rủi ro thay đổi và tài sản nội bộ của doanh nghiệp.

1.2 Ranh giới tác động và quyền tấn công

Các lỗ hổng cốt lõi trong đợt này chủ yếu nằm trong Mặt phẳng dữ liệu NGINX: điểm tấn công là kết nối và yêu cầu của máy khách, đồng thời tác động thực tế thường xảy ra trong quy trình Worker. Nếu đáp ứng các điều kiện có thể khai thác để làm hỏng bộ nhớ, thì quyền thực thi mã thường bị hạn chế bởi người dùng đang chạy, các ràng buộc về vùng chứa, khả năng của Linux, quá trình cài đặt và quyền mạng của Worker; RCE tiềm năng không tự động ngụ ý các đặc quyền của root hoặc sự xâm phạm máy chủ. S4

Nhưng ngay cả khi quy trình không có đặc quyền, nó vẫn có thể có quyền truy cập vào thông tin xác thực proxy, các tệp có thể đọc được chứa khóa riêng của chứng chỉ, mã thông báo dịch vụ ngược dòng, tệp tạm thời, API nội bộ và các mạng có thể truy cập. Đối với mTLS, việc bỏ qua xác thực có thể là một hậu quả kinh doanh nghiêm trọng và không nhất thiết phải đi kèm với việc thực thi mã.

2. Phân tích nguyên nhân

2.1 Hiểu ba ranh giới dễ xảy ra lỗi trong NGINX

NGINX worker là một quy trình tồn tại lâu dài, theo hướng sự kiện, duy trì trạng thái yêu cầu, hoạt động không đồng bộ và trình phân tích cú pháp giao thức. Lỗ hổng này thể hiện những hạn chế ở ba cấp độ kỹ thuật:

1. đánh giá biến và kích thước bộ nhớ phải nhất quán: rewrite Sau khi thay đổi yêu cầu URI, ánh xạ đường dẫn phải nhất quán với location hiện có hiệu lực; khi trình thông dịch tập lệnh tính toán độ dài thay đổi, vùng ghi phải bao gồm vùng đầu ra thực tế và vùng dành riêng.
2. Các hoạt động không đồng bộ phải kéo dài vòng đời của bộ nhớ được yêu cầu: Khi có thao tác đọc và ghi tệp chưa hoàn thành, chờ bộ đệm hoặc tác vụ luồng, nhóm bộ nhớ yêu cầu liên quan không thể được giải phóng trước.
3. trạng thái giao thức và trạng thái bảo mật không thể trộn lẫn hoặc bỏ qua: HTTP/3 Độ dài của việc bỏ qua khung không xác định không thể được coi là độ dài nội dung yêu cầu DATA; TLS Tất cả các vị trí khóa tham gia xác minh chữ ký phải được khởi tạo và đồng bộ hóa chính xác trong quá trình quay vé phiên.

Nội dung sau đây dựa trên cam kết sửa lỗi ngược dòng NGINX và thông báo của nhà cung cấp để giải thích cơ chế lỗi có thể được kích hoạt; đoạn ví dụ dùng để phân tích, không phải là mã hoàn chỉnh có thể được sử dụng trực tiếp để sửa chữa môi trường sản xuất. S5S6S7S8S9

2.2 CVE-2026-15176: Ánh xạ đường dẫn giữa alias và URI được viết lại là không hợp lệ.

Trong NGINX, location phù hợp và alias của nó xác định đường dẫn tệp; rewrite có thể thay đổi yêu cầu hiện tại URI. Sau khi viết lại, các giả định được ánh xạ location ban đầu sử dụng có thể không còn đúng nữa.

Đường dẫn xử lý bị ảnh hưởng không kiểm tra đầy đủ liệu yêu cầu có được viết lại hay không khi kiểm tra trạng thái alias trong ngx_http_map_uri_to_path(). Khi cấu hình tiếp tục đánh giá $request_filename sau khi viết lại, đường dẫn có thể được xây dựng với các giả định không phù hợp với trạng thái URI hiện tại, cuối cùng kích hoạt ghi ngoài giới hạn vào bộ nhớ heap. S5

Sự kết hợp điển hình (chỉ được sử dụng làm ví dụ mẫu cho kiểm tra cấu hình, không nên triển khai):

# 仅用于识别风险模式：不是修复配置
location /foo/ {
    alias /srv/alias-root/;
    rewrite ^/foo/.*$ /new-path;
    return 200 $request_filename;
}

Mối nguy hiểm không chỉ giới hạn ở return: set, if, add_header, log_format, v.v. cũng cần được kiểm tra nếu đánh giá $request_filename được kích hoạt trong cùng một quy trình yêu cầu. return trong ví dụ chỉ làm cho đường dẫn trạng thái này dễ nhìn chứ không thể dùng để suy ra rằng tất cả các cấu hình sản xuất sẽ tạo ra lỗi tràn. S5S10

Hậu quả của cuộc tấn công: Việc tạo yêu cầu có thể khiến Worker khởi động lại hoặc gián đoạn dịch vụ; trong các điều kiện như ASLR bị đóng hoặc có thể được bỏ qua, thì có tiềm năng xảy ra RCE. Cốt lõi của bản vá ngược dòng là từ chối hoàn thành ánh xạ đường dẫn URI được viết lại trong ngữ cảnh alias không còn hợp lệ, thay vì chỉ mở rộng một bộ đệm nhất định. S5S10

2.3 CVE-2026-93479: Không khớp giữa “không gian dành riêng” và độ dài biến thực trong đánh giá tập lệnh

Các mô-đun HTTP và Stream của NGINX có các bộ đánh giá tập lệnh nối các chuỗi ký tự và các giá trị biến vào chuỗi kết quả. Các ví dụ ứng dụng bao gồm đường dẫn root của tài liệu HTTP, đường dẫn nhật ký truy cập và biểu thức biến trong Stream.

Một số cấu hình nhất định của map + biểu thức chính quy cho phép các biểu thức khác đọc các giá trị đã ghi trước khi biến kết quả map được đánh giá. Kết hợp với phương thức thực thi tập lệnh có độ dài dành riêng, cách triển khai cũ sẽ tính trước không gian dành riêng len vào bộ tích lũy độ dài được đánh giá, do đó các phép tính con trỏ ghi tiếp theo không còn phù hợp với ranh giới bộ đệm. Trong một chuỗi đánh giá biến cụ thể, việc ghi chuỗi tiếp theo có thể ghi đè lên vùng dành riêng, gây ra tràn vùng nhớ heap. S6

yếu tố có sự tham gia	Tại sao nó đáng được quan tâm
biểu thức chính quy trong map	Đánh giá biến nắm bắt có thể có vòng đời và hành vi lưu vào bộ nhớ đệm độc lập
Các ảnh chụp ẩn danh như $1, $2, v.v.	Dễ dàng bị ghi đè bởi các biểu thức chính quy hoặc biểu thức khác, gây khó khăn cho việc theo dõi quyền sở hữu
Các biến trong root	Thực thi tập lệnh và đặt trước bộ đệm khi kích hoạt xây dựng đường dẫn
Đường dẫn nhật ký động log_format/Dynamic	Loại đánh giá tương tự có thể được kích hoạt sau này trong yêu cầu
Biểu thức tập lệnh trong stream	Bản sửa lỗi ngược dòng cũng sửa đổi ngx_stream_script_run(). Bạn không thể chỉ xem lại mô-đun HTTP.

Mối quan hệ hồi quy quan trọng: Mã liên quan đến lỗ hổng này có liên quan đến những thay đổi trước đó đã sửa lỗi CVE-2026-42533. DSA chính thức cho Debian 13 nêu rõ rằng mã bị ảnh hưởng đã được đưa vào gói trixie thông qua cổng sau bảo mật trước đó. Do đó, “Bản vá lỗ hổng map tháng 7 đã được cài đặt” không có nghĩa là CVE-2026-93479 của tháng 10 đã được bảo vệ; chuỗi sửa lỗi bảo mật đầy đủ phải được kiểm tra. S6S14S17

Rủi ro RCE tiềm ẩn ở đây liên quan đến môi trường bảo vệ bộ nhớ và không nên khẳng định rằng chỉ riêng biểu thức chính quy map sẽ có thể bị những kẻ tấn công ẩn danh khai thác. S11

2.4 CVE-2026-97205: AIO Nguyên nhân bao quanh số lượng thao tác chưa hoàn thành Sử dụng-Sau-Miễn phí

Lỗ hổng này không chỉ đơn giản là “bật SSI là bạn sẽ nhận được UAF”. Chìa khóa nằm ở số tham chiếu hoạt động không đồng bộ được giữ bởi yêu cầu chính.

NGINX Sử dụng r->main->blocked để theo dõi quá trình xử lý không đồng bộ chưa hoàn thành, trong cách triển khai cũ, nó là số 8 bit; một số đường dẫn không thực hiện kiểm tra giới hạn trên trước khi tăng số lượng. Khi cùng một yêu cầu chính tích lũy 256 hoạt động chưa xử lý, số lượng có thể nằm trong khoảng từ 255 đến 0. Các quy trình tiếp theo sẽ nhầm tưởng rằng không có hoạt động không đồng bộ nào ngăn cản yêu cầu được giải phóng, do đó giải phóng nhóm bộ nhớ yêu cầu vẫn được tác vụ tham chiếu. S7

Quá trình thất bại có thể được chia thành:

1. Khi bật đường dẫn I/O/luồng không đồng bộ liên quan, trang SSI sẽ đưa ra nhiều yêu cầu phụ hoặc thao tác đọc thông qua include virtual.
2. Các hoạt động chưa xử lý của một yêu cầu chính nhất định được tích lũy đến giới hạn trên được biểu thị bằng trường đếm.
3. Số lượng 8 bit bao quanh, được biểu thị không chính xác là “không có hoạt động nào đang chờ xử lý”.
4. Nhóm bộ nhớ yêu cầu được giải phóng, trong khi đọc tệp, chờ bộ đệm hoặc gọi lại các tác vụ luồng vẫn giữ lại các tham chiếu đến nó.
5. Các lệnh gọi lại hoàn thành không đồng bộ tiếp theo sẽ truy cập vào bộ nhớ đã giải phóng, dẫn đến UAF, Worker gặp sự cố hoặc có thể bị hỏng bộ nhớ.

Bản sửa lỗi chính thức thêm NGX_HTTP_MAX_BLOCKED 250 vào tệp tiêu đề yêu cầu và thêm các hạn chế đối với bộ lọc đầu ra, đọc bộ đệm và đường dẫn luồng ngược dòng; khi đạt đến ngưỡng, các hoạt động với đường dẫn được đồng bộ hóa sẽ được hoàn thành một cách đồng bộ và nếu chúng không thể được xử lý một cách an toàn thì việc bổ sung thêm các tác vụ đang chờ xử lý sẽ bị từ chối. S7

phán đoán về khả năng áp dụng: Phải đánh giá xem liệu SSI, AIO, bao gồm ảo, yêu cầu phụ và các hoạt động không đồng bộ liên quan có thể xảy ra kết hợp trong cùng một chuỗi yêu cầu hay không. Đây thường không phải là cấu hình proxy tĩnh đơn giản mặc định. aio off; hoặc ssi off; có thể loại bỏ các phần tử kích hoạt cụ thể, nhưng trước tiên phải xác nhận các phần phụ thuộc của chức năng kinh doanh. S4S7S25

2.5 CVE-2026-95101: Khung không xác định HTTP/3 bị nhầm lẫn với trạng thái của nội dung yêu cầu DATA

Trình phân tích cú pháp khung HTTP/3 phải phân biệt giữa các khung DATA (cần được chuyển để xử lý nội dung yêu cầu HTTP) và các khung không xác định cần được bỏ qua. Độ dài của các khung không xác định cũng phải được bảo toàn chính xác khi phân mảnh trên bộ đệm mạng.

Việc triển khai ngx_http_v3_parse_data() cũ đã sử dụng trường st->length để lưu “số byte còn lại cần bỏ qua” khi bỏ qua các khung không xác định, trong khi bộ lọc nội dung yêu cầu diễn giải trường tương tự như “độ dài tải trọng DATA còn lại”. Nếu khung không xác định xảy ra để thực hiện nhiều lệnh gọi phân tích cú pháp, lô byte tiếp theo sau khi quá trình phân tích cú pháp bị gián đoạn có thể bị nhầm lẫn là một phần của nội dung yêu cầu. S8

Hai loại rủi ro phát sinh:

• nội dung yêu cầu: Tải trọng khung không phải DATA do khách hàng gửi có thể được truyền đến ứng dụng ngược dòng, thay đổi dữ liệu mà chương trình phụ trợ thực sự nhận được.
• bỏ qua giới hạn kích thước: client_max_body_size và các hạn chế khác. Các hoạt động kiểm tra dự kiến ​​tập trung vào đường dẫn DATA và nội dung được chuyển đổi không chính xác có thể bỏ qua quá trình xác minh tương ứng.

Kịch bản kích hoạt điển hình được quan chức này mô tả là khi ngx_http_v3_module nhận được yêu cầu HTTP/3 và chuyển tiếp proxy_request_buffering on. Bộ đệm nội dung yêu cầu proxy được bật theo mặc định trong ngx_http_proxy_module. Do đó, proxy ngược bật HTTP/3 trước tiên phải được kiểm tra. Sẽ không phù hợp nếu cho rằng không có điều kiện kích hoạt chỉ vì proxy_request_buffering on; không được viết rõ ràng. S8S18

Hậu quả trực tiếp của lỗ hổng này thuộc về sự thay đổi ranh giới bảo mật và tính toàn vẹn của yêu cầu phụ trợ, đây không phải là biểu hiện tương đương của RCE được hoàn thành trực tiếp trong lõi NGINX. Tác động kinh doanh cuối cùng phụ thuộc vào cách các byte này được phân tích cú pháp và tin cậy ngược dòng. S24

2.6 CVE-2026-97629: TLS Vòng quay vé thiếu khe khóa thứ ba

Trong các cấu hình bị ảnh hưởng, NGINX có thể tự động tạo và xoay các khóa Vé phiên TLS thông qua bộ nhớ đệm dùng chung, cho phép nhiều Worker xử lý cùng một lô vé.

Logic đồng bộ hóa có liên quan phân bổ 3 vị trí khóa cho mỗi Worker và lệnh gọi lại giải mã cũng sẽ đi qua các vị trí này; nhưng cách triển khai cũ chỉ sao chép 2 khe khóa từ bộ nhớ dùng chung mỗi lần, dẫn đến tên khóa, khóa HMAC và AES của khe thứ ba. Chìa khóa có thể vẫn chưa được khởi tạo. Nếu mã định danh khóa của vé khớp với trạng thái này, thì vật liệu khóa chưa được khởi tạo có thể được sử dụng để xác minh và giải mã chữ ký, từ đó tạo thành đường dẫn giả mạo phiên TLS. S9

Các kết hợp triển khai có rủi ro cao thường là:

# 仅为排查触发条件所示：共享缓存本身不是恶意配置
ssl_session_cache shared:SSL:10m;
# 未显式配置 ssl_session_ticket_key 文件，使用自动轮换机制

Hậu quả kinh doanh nghiêm trọng nhất của lỗ hổng này là trên các dịch vụ sử dụng xác thực chứng chỉ ứng dụng khách (mTLS) trong ssl_verify_client on; và các cách khác, các phiên khôi phục giả mạo có thể bỏ qua việc xác minh chứng chỉ ứng dụng khách. Sự thành công của cuộc tấn công còn phụ thuộc vào những điều kiện không thể kiểm soát được; một trang web chỉ sử dụng chứng chỉ HTTPS phía máy chủ thông thường và không có xác thực chứng chỉ ứng dụng khách sẽ không bị mô tả sai là “kẻ tấn công có thể bỏ qua toàn bộ thông tin đăng nhập trang web”. S9S12

Đây là sự cố trạng thái xác thực phiên TLS và không liên quan gì đến việc khóa riêng TLS của máy chủ có bị bẻ khóa hay chứng chỉ CA root công khai có bị ảnh hưởng hay không. S24

2.7 Cách hiểu DoS, RCE, bỏ qua xác thực và các cách khai thác đã biết

• DoS: Lỗi bộ nhớ khiến Worker gặp sự cố hoặc khởi động lại hàng loạt. Việc nguyên nhân gây ra tình trạng không sẵn sàng tổng thể có liên quan đến áp lực lưu lượng, khả năng khởi động lại quy trình, thời gian bảo trì kết nối và kiến ​​trúc có tính sẵn sàng cao hay không.
• RCE tiềm năng: Một số thông báo cho biết rằng có khả năng thực thi mã khi ASLR bị đóng hoặc bỏ qua. Điều này không có nghĩa là một chuỗi tấn công công khai có thể thực thi các lệnh một cách ổn định và phổ biến đã bị tiết lộ. S4
• Bỏ qua yêu cầu chèn/xác thực: Nó có thể trực tiếp thay đổi trạng thái kinh doanh được bảo vệ hoặc nội dung yêu cầu và không thể bỏ qua chỉ vì nó không trực tiếp lấy được shell.
• đã phát hiện các nỗ lực tấn công: CVE-2026-42945 vào tháng 5 năm 2026 có báo cáo về các hoạt động khai thác ngoài tự nhiên; không nên suy luận trực tiếp sự thật lịch sử này có nghĩa là cả 5 CVE trong tháng 10 đều đã được khai thác thành công trên diện rộng. S23

3. Lựa chọn phiên bản sửa chữa và bản vá

Đường cơ sở của bản vá chính thức 3.1 NGINX Open Source

nhánh thượng nguồn	Phiên bản chính thức đầu tiên che 5 lỗ hổng vào tháng 10	Khuyến nghị kể từ 2026-10-27
Stable 1.30.x	1.30.6（2026-10-14）	Cài đặt ít nhất 1.30.6 và theo dõi các phiên bản bảo mật tiếp theo.
Mainline 1.31.x	1.31.7（2026-10-14）	1.31.8（2026-10-21）
Nhánh NGINX Open Source trước đó	Không thể đánh giá chỉ dựa vào “các bản vá lỗ hổng cũ đã được áp dụng”	Trước tiên hãy di chuyển đến nhánh được duy trì; mặt khác, nhà cung cấp phải cung cấp bằng chứng chính thức về việc hỗ trợ trên cơ sở CVE-by-CVE.

Đây là các kết luận về phiên bản của mã nguồn/nhánh chính thức ngược dòng nginx.org và không được sử dụng để từ chối trực tiếp gói bảo mật với các bản sửa lỗi được đưa vào nền do nhà cung cấp phân phối cung cấp. Ngay cả khi giá trị của 1.31.6 lớn hơn 1.30.6, nó vẫn thấp hơn đường cơ sở của bản vá của nhánh chính. S1S2

3.2 Phạm vi tác động ngược dòng của năm CVE

Các phạm vi sau được liệt kê theo văn bản gốc của bản tin bảo mật nginx.org và cần được hiểu cùng với “nhánh đang chạy hiện tại” và “đường dẫn cấu hình thực tế”:

CVE	Các phiên bản bị ảnh hưởng của thẻ ngược dòng	Phiên bản cố định được dán nhãn chính thức
CVE-2026-15176	0.1.29–1.31.6	1.30.6+ hoặc 1.31.7+, trong các nhánh tương ứng của chúng
CVE-2026-93479	1.30.0–1.30.5，1.31.2–1.31.6	Tương tự như trên
CVE-2026-97205	0.8.11–1.31.6	Tương tự như trên
CVE-2026-95101	1.25.0–1.31.6	Tương tự như trên
CVE-2026-97629	1.23.2–1.31.6	Tương tự như trên

CVE-2026-93479 có giới hạn phiên bản giới thiệu cụ thể; không phải mọi phiên bản NGINX cũ đều bị ảnh hưởng bởi sự hồi quy này. Các phiên bản cũ hơn nằm ngoài phạm vi đó vẫn có thể bị ảnh hưởng bởi lỗ hổng biểu thức chính quy map CVE-2026-42533 trước đó. S1

3.3 Ubuntu: cổng sau phân phối (USN-8955-1)

Canonical USN-8955-1 ngày 26 tháng 10 năm 2026 cung cấp bản cập nhật bảo mật cho bốn bản dựng Ubuntu: S13

Phiên bản Ubuntu	nginx và phiên bản cố định của gói nguồn tương tự	Mô tả
22.04 LTS	1.18.0-6ubuntu14.22	Nó là một backport của nhà cung cấp; số phiên bản ngược dòng vẫn hiển thị 1.18.0
24.04 LTS	1.24.0-2ubuntu7.19	Tương tự như trên
26.04 LTS	1.28.3-2ubuntu1.12	Tương tự như trên
26.10	1.30.4-7ubuntu1.1	Tương tự như trên

Thông báo chứa các phiên bản cố định tương ứng của các gói tương đồng như nginx-core, nginx-extras, nginx-full và nginx-light. Đừng đưa ra kết luận về việc có nên sửa nó từ phần ngược dòng chỉ được hiển thị bởi nginx -v hay không. chẳng hạn như Ubuntu 24.04 và 1.24.0-2ubuntu7.19 đã được nhà cung cấp này vá, nhưng 1.24.0 từ bất kỳ nguồn nào vốn dĩ không an toàn.

Ubuntu cũng chính thức đánh dấu rõ ràng rằng CVE-2026-95101 chỉ ảnh hưởng đến Ubuntu 26.04 / 26.10 và CVE-2026-97629 chỉ ảnh hưởng đến Ubuntu 24.04 / 26.04 /26.10. Đây là phạm vi chức năng và bao bì riêng của Ubuntu, không thể quảng bá trực tiếp cho các bản phân phối khác. S13

3.4 Debian: Sự khác biệt giữa các phiên bản phải được kiểm tra riêng

Tư vấn Debian DSA-6575-1 (2026-10-21) bao gồm năm CVE này và xác định gói nginx cố định cho Debian 13 / trixie là:

1.26.3-3+deb13u10

Tuy nhiên, tính đến thời điểm xác minh báo cáo này, 1.22.1-9+deb12u10 dành cho Debian 12 / bookworm vẫn bị Trình theo dõi bảo mật Debian gắn cờ là dễ bị tấn công. Vì vậy:

• Debian 13 Chỉ cần cập nhật và chấp nhận theo DSA-6575-1.
• Debian 12 phải kiểm tra từng bản sửa lỗi bảo mật được cung cấp bởi Trình theo dõi bảo mật hiện tại hoặc nhà cung cấp ELTS; trước khi việc sửa lỗi được xác nhận trong thông báo, không được tuyên bố rằng cả năm mục đã được sửa dựa trên sự thành công của apt upgrade.
• Gói nguồn Debian có thể mang một bộ bản vá độc lập với số phiên bản nginx.org. Đối với các bản dựng tùy chỉnh, bạn cần kiểm tra bộ sửa lỗi gói mã nguồn hoàn chỉnh và bạn không thể chỉ sao chép một cam kết ngược dòng duy nhất và coi như nó đã hoàn thành.

Sự khác biệt trên dựa trên hồ sơ theo dõi DSA và CVE. S14S15S16

3.5 NGINX Plus, njs và Bộ điều khiển xâm nhập

Sản phẩm/Thành phần	Các điểm chính về lựa chọn và xác minh bảo mật
NGINX Plus (phiên bản thương mại)	Mời bạn tham khảo thông báo và hướng dẫn nâng cấp của nhánh Plus tương ứng với F5. CR mới nhất tại thời điểm xác minh là PLS.37.2.0.1 và bản dựng bảo mật của LTS là PLS.37.0.7.1; phiên bản Plus và cổng sau đi kèm không thể được thay thế trực tiếp bằng ngưỡng 1.30/1.31 của Nguồn mở. S19
njs / ngx_http_js_module	2026-10-14 phát hành njs 1.0.2 và sửa lỗi CVE-2026-101019 và CVE-2026-101025; nếu bạn đang sử dụng njs, bạn cũng phải kiểm tra tính tương thích của mô-đun với NGINX. S20
F5 NGINX Bộ điều khiển xâm nhập / Vải cổng	Lõi NGINX là chuỗi phân phối phần mềm độc lập nhưng có liên quan. Khắc phục các lỗ hổng liên quan bằng bộ điều khiển, hình ảnh và ghi chú phát hành tương ứng. Bạn không thể chỉ thay thế tệp nhị phân NGINX trong Pod.
Cộng đồng Kubernetes kubernetes/ingress-nginx	Dự án sẽ ngừng hoạt động vào tháng 3 năm 2026 và sẽ không cung cấp dịch vụ bảo trì bảo mật mới nữa. Bạn nên lập kế hoạch di chuyển sang bộ điều khiển được bảo trì hoặc Gateway API thay vì nhầm số phát hành của nó với Bộ điều khiển xâm nhập F5 NGINX. S21

3.6 Bạn nên chọn bản vá nào?

Hình thức triển khai	Các phương pháp được đề xuất	Bằng chứng sửa chữa
Gói DEB/RPM chính thức của nginx.org	Nâng cấp lên phiên bản cố định của nhánh thượng nguồn	nginx -v/-V, nguồn gói, thông báo bảo mật chính thức
Kho lưu trữ chính thức của Ubuntu/Debian	Cài đặt gói bảo mật của nhà cung cấp	Phiên bản trọn gói + trạng thái USN/DSA + CVE của nhà cung cấp
RHEL/Alma/Rocky/SUSE/Các bản phân phối khác	Nâng cấp theo các bản tin bảo mật phân phối cụ thể và các phiên bản gói	CSAF/thông báo của nhà cung cấp tương ứng, không thể áp dụng phiên bản Ubuntu/Debian
Hình ảnh vùng chứa chính thức hoặc tùy chỉnh	Xây dựng lại hoặc kéo hình ảnh sửa chữa đã được xác minh và thay thế nó trên cơ sở luân phiên	Phân loại hình ảnh, xây dựng SBOM, chạy ID hình ảnh nhóm/container
NGINX, OpenResty, Tengine tự biên dịch hoặc các phiên bản được vá bằng mô-đun của bên thứ ba	Ưu tiên sử dụng phiên bản bảo mật đầy đủ của nhà bảo trì; thực hiện các bản vá lỗi đã được xem xét lại cho cây nguồn đích khi cần thiết	Năm bản sửa lỗi lỗ hổng, khả năng tương thích ABI/mô-đun, hồi quy đơn vị và doanh nghiệp

OpenResty và Tengine là các hệ thống phát hành khác nhau; bảng này chỉ mô tả phương pháp xác minh. không có nghĩa là tất cả các phiên bản của nó đều bị ảnh hưởng cùng lúc với NGINX tiêu chuẩn, cũng như bản vá mã ngược dòng không thể được áp dụng vô điều kiện.

4. Quy trình sửa chữa chính thức

4.1 Kiểm kê các trường hợp thực tế nhận lưu lượng truy cập bên ngoài

Đối chiếu cho mỗi mục ít nhất:

• Tên miền, cân bằng tải/CDN/liên kết proxy biên, phương thức hiển thị trang gốc và giao thức mạng được sử dụng.
• Các sản phẩm NGINX (Mã nguồn mở, Plus, Ingress, v.v.), phiên bản đầy đủ, nguồn kho lưu trữ gói, thông báo hình ảnh.
• nginx -V hiển thị các mô-đun xây dựng và các tham số biên dịch; liệu có njs, Lua, OpenResty và mô-đun động của bên thứ ba hay không.
• Chạy thực tế master/worker PID, Đơn vị dịch vụ/Container/Pod, Bản sao và Nút Worker.
• Các cấu hình http/stream, server, location, include hiệu quả thực tế.
• Có bật HTTP/3, mTLS, SSI/AIO, đường dẫn nhật ký động, map phức tạp và chụp biểu thức chính quy hay không.

Đừng chỉ kiểm tra /etc/nginx/nginx.conf mặc định. Môi trường sản xuất thường tải nhiều trang web, TLS và cấu hình mô-đun thông qua include. Cũng có thể có nhiều đường dẫn cài đặt NGINX hoặc nhiều lớp proxy.

4.2 Kiểm tra phiên bản và thông tin biên dịch

# NGINX 版本及构建选项
nginx -v
nginx -V 2>&1

# Linux：查看实际运行的 NGINX 进程
ps -eo pid,ppid,user,comm,args | grep '[n]ginx'

# Debian / Ubuntu：查看完整已安装包版本、来源
apt-cache policy nginx
# 兼顾 nginx-core / nginx-full / nginx-extras 等实际已安装包
dpkg-query -W 'nginx*' 2>/dev/null

# RPM 系：以实际安装包及仓库公告为准
rpm -qa | grep '^nginx'

nginx -V báo cáo việc xây dựng tệp nhị phân được tìm thấy trên đường dẫn dòng lệnh; nó không chứng minh rằng worker đang chạy đã tải nó. nginx -v có thể bỏ qua hậu tố gói đầy đủ của phân phối, vì vậy hãy kiểm tra cả bản ghi trình quản lý gói hoặc chuỗi cung ứng.

4.3 Xuất cấu hình hiệu quả và thực hiện vòng sàng lọc tĩnh đầu tiên

nginx -T sẽ kiểm tra cấu hình và kết xuất cấu hình đã hợp nhất. Đầu ra có thể chứa thông tin nhạy cảm như thông tin xác thực, đường dẫn chính, tên máy chủ nội bộ, v.v. Bạn nên lưu thiết bị đầu cuối được kiểm soát với quyền root và quyền đối với tệp riêng tư, đồng thời không đăng tệp gốc lên lệnh sản xuất công khai:

sudo sh -c 'umask 077; nginx -T > /root/nginx-effective.conf 2> /root/nginx-config-check.log'

sudo grep -nE \
  'alias|rewrite|map[[:space:]]|request_filename|aio[[:space:]]|ssi[[:space:]]|quic|http3|proxy_request_buffering|ssl_session_cache|ssl_session_ticket_key|ssl_session_tickets|ssl_verify_client|log_format|root[[:space:]]' \
  /root/nginx-effective.conf

Đây chỉ là công cụ định vị đường dẫn ứng viên, không phải là công cụ xác định tự động CVE đáng tin cậy:

1. grep không thể xác định xem các biến có nằm trong cùng một location hay cùng một chuỗi đánh giá yêu cầu hay không, cũng như không thể suy ra mối quan hệ kế thừa cấu hình.
2. proxy_request_buffering on, một số cấu hình bộ đệm và vé có giá trị mặc định và việc không ghi hướng dẫn tương ứng không có nghĩa là rủi ro sẽ biến mất.
3. Cấu hình được tạo bởi proxy ngược, CDN, sidecar container hoặc bộ điều khiển có thể khác với các tệp được kiểm tra thủ công.
4. Các đặc tính của NGINX Plus và các mô-đun động có thể cần được xác nhận bằng các công cụ quản lý chính thức tương ứng.

4.4 Triển khai bản sửa lỗi thông qua các kênh đáng tin cậy

Debian/Ubuntu (kho phân phối chính thức):

sudo apt-get update
apt-cache policy nginx

# 升级发行版仓库中已经安装的 NGINX 及相关包；
# 先确认 Candidate 属于修复版本，再执行升级。
sudo apt-get install --only-upgrade nginx

# 对实际安装的 nginx-core / nginx-full / nginx-extras 等包
# 确认它们的版本和依赖一同达到厂商修复要求。
dpkg-query -W 'nginx*' 2>/dev/null

Bộ lệnh này không thể tự động tạo ra các bản sửa lỗi bảo mật chưa có sẵn. Đặc biệt đối với Debian 12, nếu gói nâng cấp vẫn bị hệ thống theo dõi bảo mật cho là dễ bị tổn thương thì cần phải có các biện pháp sửa chữa, cách ly hoặc di chuyển bổ sung của nhà cung cấp. S13S14S15

Gói chính thức nginx.org:

# 先确认仓库来自 nginx.org、目标分支和候选版本
apt-cache policy nginx
# 经变更审批后再执行对应仓库的升级命令
sudo apt-get install --only-upgrade nginx

Nếu sử dụng OpenResty, Tengine hoặc NGINX Plus tự biên dịch, hãy sử dụng phiên bản sửa lỗi được nhà bảo trì tương ứng hỗ trợ và không kết hợp nginx.org, gói phân phối và kho lưu trữ của bên thứ ba. Các tệp nhị phân/hình ảnh, cấu hình, chữ ký và bảng kê khai triển khai khôi phục gốc phải được giữ nguyên.

Container/Kubernetes: cập nhật hình ảnh bất biến, ghi lại thông báo của nó và thay thế tất cả các bản sao cũ bằng bản giới thiệu theo giai đoạn. kubectl rollout status chỉ xác nhận rằng bộ điều khiển triển khai đã hoàn tất; cũng xác minh thông báo hình ảnh, định tuyến xâm nhập và các bản sao không lành mạnh.

4.5 Xác minh cấu hình và thay thế Worker cũ

sudo nginx -t
# 按服务实际名称、主机高可用和变更窗口执行重启
sudo systemctl restart nginx
sudo systemctl status nginx --no-pager

# 核查真正存在的 master / worker
ps -eo pid,ppid,user,comm,args | grep '[n]ginx'

Không coi nginx -s reload là bằng chứng cho thấy tệp nhị phân mới đang chạy: tải lại cấu hình thông thường cho phép master cũ khởi động các chương trình chạy mới mà không thay thế tệp thực thi của nó. NGINX hỗ trợ quy trình nâng cấp nhị phân trực tuyến chuyên dụng nhưng yêu cầu các bước bổ sung và xác minh. Nếu không có quy trình đã thiết lập, hãy sử dụng bộ chuyển mạch lưu lượng có tính sẵn sàng cao, sau đó khởi động lại dịch vụ hoặc triển khai các vùng chứa thay thế. S22

Nếu bạn quản lý NGINX thông qua ổ cắm systemd, tập lệnh mục nhập vùng chứa hoặc nhiều cài đặt, bạn nên kiểm tra mục tiêu khởi chạy thực tế và đường dẫn xử lý thay vì trực tiếp giả định rằng systemctl restart nginx bao gồm tất cả các phiên bản.

4.6 Chấp nhận và thực hiện hồi quy kinh doanh từ lối vào thực bên ngoài

Nên thực hiện ít nhất:

• HTTPS bình thường, các tuyến đường được viết lại, tài nguyên tĩnh và các trang ánh xạ alias có chính xác không.
• Phân phối map thông thường, đường dẫn root biến đổi, đường dẫn nhật ký truy cập, SNI/định tuyến chứng chỉ và proxy Stream có chính xác không.
• Các nội dung tải lên thông thường, tải lên theo khối, yêu cầu API và giới hạn âm lượng ngược dòng cho HTTP/3 (khi được bật) vẫn như mong đợi.
• mTLS: Yêu cầu chứng chỉ hợp pháp sẽ thành công; Các chứng chỉ bị thiếu, hết hạn hoặc trái phép vẫn bị từ chối và việc nối lại/kết nối lại TLS không được vô tình thay đổi quyền.
• Việc truy cập trang SSI và tệp không đồng bộ có bình thường hay không; nhật ký lỗi không hiển thị yêu cầu bất thường nào về tham chiếu bộ nhớ hoặc sự cố Worker lặp đi lặp lại.
• Sau khi chuyển đổi lưu lượng, quy trình phiên bản cũ và bản sao hình ảnh cũ sẽ thoát.

Việc kiểm tra phải được tiến hành trong môi trường riêng hoặc được ủy quyền. Kiểm tra khói yêu cầu thông thường không thể một mình chứng minh rằng lỗ hổng bộ nhớ đã được khắc phục; cuối cùng, phiên bản cố định, bản vá mã nguồn và thử nghiệm thời gian chạy của nhà cung cấp phải được chấp nhận chung.

5. Biện pháp giảm thiểu khi không thể nâng cấp ngay

Phần này là một tùy chọn giảm thiểu rủi ro, không phải là thay thế bản vá. Tất cả các thay đổi cấu hình tạm thời phải được sao lưu, thực thi nginx -t, phát hành theo đợt và nhanh chóng khôi phục nếu cần. S3S4

5.1 Kiểm soát mức độ ưu tiên lưu lượng truy cập dựa trên mức độ tiếp xúc bên ngoài

Ưu tiên giảm bề mặt tấn công của các dịch vụ không thể nâng cấp kịp thời: trên bề mặt quản lý và nội bộ API Thêm kiểm soát truy cập nguồn đáng tin cậy, cách ly mạng ngược dòng hoặc ngoại tuyến ngắn hạn; thêm giới hạn kết nối, nội dung yêu cầu và tốc độ cho các lối vào có rủi ro cao; đảm bảo rằng xác thực nguồn xảy ra tại NGINX liên quan đến mục nhập trước chuỗi xử lý yêu cầu. Cần lưu ý rằng hầu hết các lỗ hổng đều nằm trong NGINX Bên trong mặt phẳng dữ liệu, Quy tắc WAF truyền thống có thể không xác định chính xác các điều kiện kích hoạt cấu hình tùy chỉnh.

5.2 alias / rewrite: tránh đánh giá $request_filename sau khi viết lại

Đề nghị kiểm tra và điều chỉnh:

• Cố gắng không thực hiện rewrite vì nó sẽ thay đổi URI cùng lúc với location bằng alias.
• Tránh sử dụng $request_filename khi URI đã được viết lại nhưng việc khớp vị trí chính xác vẫn chưa được hoàn thành.
• Kiểm tra các tham chiếu biến gián tiếp trong return, set, if, add_header, định dạng nhật ký truy cập và bao gồm các tệp.
• Sử dụng root/try_files/location độc lập khi doanh nghiệp cho phép, nhưng chỉ thay đổi alias thành root. Nó cũng có thể thay đổi ngữ nghĩa đường dẫn tệp, điều này phải được xác minh từng cái một.

Không sao chép trực tiếp “mẫu viết lại an toàn” phổ biến trên Internet để ghi đè lên cấu hình hiện có. Các tiền tố location khác nhau và các mục tiêu viết lại dẫn đến việc ghép đường dẫn với ý nghĩa hoàn toàn khác nhau. S5

5.3 map/Regex: Giảm trộn trạng thái biến chụp

Bạn nên ưu tiên các bản chụp có tên và giới hạn phạm vi lan truyền của chúng, thay vì cho phép các bản chụp ẩn danh như $1 được sử dụng lại trên các đường dẫn đánh giá biểu thức chính quy khác nhau theo thời gian. Ví dụ:

# 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整
map $host $tenant_root {
    default /srv/www/default;
    ~^(?<tenant>[a-z0-9-]+)\.example\.net$ /srv/www/$tenant;
}

Đoạn mã này chỉ trình bày cấu trúc dễ kiểm tra hơn về quyền sở hữu biến; không có nghĩa là nó đã được chứng minh là có thể loại bỏ độc lập tất cả các đường dẫn kích hoạt CVE-2026-93479 tới. Cụ thể, hãy xem xét xem các biến chụp có được tham chiếu trước bởi root hoặc log_format khác hay không và liệu có volatile, đường dẫn động và chuỗi đánh giá phụ thuộc lẫn nhau hay không. F5/CERT khuyến nghị sử dụng tính năng chụp có tên và giới hạn phạm vi sử dụng ở cấu hình khớp thông thường tương ứng như một biện pháp giải quyết ngắn hạn. S3S6

5.4 AIO + SSI: Tắt các tổ hợp chức năng không cần thiết

Đối với máy chủ/đường dẫn không yêu cầu SSI hoặc I/O tệp không đồng bộ, hãy sử dụng:

# 在适当的 http/server/location 上下文中配置
ssi off;
aio off;

Từ góc độ các điều kiện kích hoạt lỗ hổng bảo mật, việc đóng một trong hai điều kiện thường là đủ để loại bỏ chuỗi cụ thể được mô tả; việc đóng cửa cùng lúc chỉ áp dụng được trong những trường hợp doanh nghiệp không dựa vào khả năng này. Kiểm tra hành vi của include virtual, yêu cầu phụ, bộ đệm và nhóm luồng; khi tải proxy ngược ở mức cao, việc tắt AIO có thể thay đổi độ trễ và hiệu suất I/O. S7

5.5 HTTP/3 Yêu cầu tiêm vào cơ thể: tạm thời đóng lối vào nếu cần thiết

Vô hiệu hóa trình nghe quic liên quan đến HTTP/3, hủy tiêu đề phản hồi Alt-Svc thông báo HTTP/3 và kiểm tra xem lớp cạnh/bộ cân bằng tải có còn gửi yêu cầu QUIC trực tiếp đến NGINX chưa được sửa chữa hay không:

# 示意：保留 HTTPS/TCP；暂时移除此前的 QUIC/UDP listen
server {
    listen 443 ssl;  # 保留 HTTPS/TCP 入口
    # 对支持新版语法的构建，可在此使用 http2 on;
    # 删除原有的 listen 443 quic reuseport;
    # 删除原有的 add_header Alt-Svc ...;（仅限宣传 h3 的那项）
    # 其余证书、server_name、location 等配置保持不变
}

Trên đây chỉ là mô tả về sự khác biệt của thay đổi, không phải là cấu hình máy chủ hoàn chỉnh có thể được kích hoạt riêng lẻ. Cú pháp cài đặt của HTTP/2 có liên quan đến phiên bản NGINX; nếu bạn cần giữ lại HTTP/2, bạn nên sử dụng http2 on; hoặc cú pháp hợp lệ hiện có theo phiên bản tương ứng và kiểm tra với nginx -t. phải được hợp nhất với cấu hình máy chủ hiện có trước khi triển khai, thay vì thay thế toàn bộ phần bằng phần này. cũng kiểm tra tường lửa UDP 443, vị trí chấm dứt HTTP/3 và đường dẫn dự phòng máy khách của CDN/proxy phía trước.

Một loại giảm thiểu ngắn hạn khác là sử dụng proxy_request_buffering off; trên đường dẫn proxy bị ảnh hưởng, nhưng điều này sẽ thay đổi hành vi phát trực tuyến nội dung yêu cầu ngược dòng, thử lại lỗi và một số quy trình tải lên; chỉ được sử dụng sau khi đã kiểm tra đầy đủ và xác nhận rằng lệnh này đã chạm tới đường dẫn proxy HTTP/3 bị ảnh hưởng. S8S18

5.6 TLS Vé phiên: Bảo vệ ưu tiên mTLS Ranh giới xác thực

Nếu không thể nâng cấp và phiên bản dựa vào bộ đệm phiên dùng chung + xoay khóa vé tự động, hãy đánh giá:

# 在 nginx http/server 适当作用域进行配置
ssl_session_tickets off;

Điều này có thể tắt cơ chế Vé phiên TLS, từ đó loại bỏ đường dẫn giả mạo vé được mô tả trong lỗ hổng này; tuy nhiên, nó có thể ảnh hưởng đến hiệu suất nối lại phiên. Bạn không thể tắt xác minh chứng chỉ ứng dụng khách mTLS để “tránh lỗ hổng”, vì điều đó sẽ xóa trực tiếp ranh giới xác thực ban đầu. S9S12

Các tệp ssl_session_ticket_key rõ ràng và xoay vòng an toàn cũng có thể được sử dụng bởi các quy trình quản lý TLS chuyên nghiệp để tránh các điều kiện được tạo tự động, nhưng quyền giám sát khóa, phân phối nút đầy đủ, xoay vòng và vòng đời vé cũ đều cần phải được kiểm tra cẩn thận. Không nên mã hóa cứng khóa có thể tái sử dụng lâu dài trong cấu hình web hoặc tập lệnh thông thường cho các trường hợp khẩn cấp tạm thời. Các dịch vụ quan trọng sử dụng mTLS cần được giám sát bổ sung về hành vi tiếp tục phiên TLS và từ chối các yêu cầu mà không có chứng chỉ ứng dụng khách hợp lệ. S12

5.7 Vai trò của hệ điều hành và bảo vệ biên giới

# Linux：常见值 2 表示进程地址空间随机化处于完整启用状态
sysctl kernel.randomize_va_space

ASLR, nhân viên không phải root, hệ thống tệp chứa chỉ đọc, quyền truy cập tệp tối thiểu và cách ly mạng có thể làm giảm tác động của RCE tiềm năng. ASLR không khắc phục lỗi tràn vùng heap hoặc UAF và không thể đảm bảo rằng các trình chạy sẽ không gặp sự cố. WAF, giới hạn tỷ lệ và giới hạn kích thước nội dung yêu cầu không khắc phục được việc đồng bộ hóa khóa Vé TLS. S4

5.8 Hiểu lầm thường gặp: Các thao tác này không đủ để hoàn thành việc sửa chữa

Hoạt động chung	Tại sao nó không đủ?
“nginx -v trông tương đối mới”	Nhánh mà nó thuộc về, phiên bản gói được chuyển ngược hoàn chỉnh của phiên bản phát hành và quy trình trực tuyến không được kiểm tra.
“Chỉ một trong số các mạng nội bộ được nâng cấp”	Phiên bản gốc Worker/vùng chứa cũ/phiên bản gốc CDN cũ vẫn nhận được yêu cầu
”Trang web không sử dụng PHP/thẻ động”	Lỗi xảy ra trong phân tích cú pháp giao thức hoặc đường dẫn lõi NGINX và không dựa vào việc thực thi PHP.
”Mở WAF/Cloudflare là đủ”	Không thể chứng minh WAF có thể chặn tất cả các lỗi bộ nhớ phụ thuộc vào cấu hình NGINX hoặc các lỗi tiếp tục TLS
”Đã mở ASLR”	Chỉ lợi dụng việc giảm bớt khó khăn; Vẫn có thể thực hiện được DoS với tính năng chèn yêu cầu
”HTTP/3 không được đưa vào mạng công cộng nên không cần phải nâng cấp gì cả”	Bốn CVE còn lại vẫn yêu cầu đánh giá độc lập; và có thể có những kết nối trực tiếp tới nguồn gốc ẩn giấu
“Lỗ hổng map của tháng 7 đã được sửa”	Tháng 10 CVE-2026-93479 liên quan đến các vấn đề hồi quy đánh giá tập lệnh tiếp theo
”Vô hiệu hóa bộ nhớ đệm giải quyết mọi vấn đề”	Chỉ ảnh hưởng đến một số trường hợp bộ đệm TLS hoặc AIO và không bao gồm bí danh, tập lệnh, HTTP/3

6. Các ý tưởng và điểm đánh giá triển khai Bản vá chính thức

Phần này tuân theo các bản sửa lỗi NGINX ngược dòng tháng 10 năm 2026. Các đoạn trích minh họa những thay đổi mang tính đại diện cho việc xem xét bản vá; chúng không phải là các bản sửa lỗi hoàn chỉnh, có thể biên dịch độc lập. Đối với các bản dựng tùy chỉnh, hãy xem lại các cam kết đầy đủ, mã và các thử nghiệm xung quanh, đồng thời ưu tiên một bản phát hành được hỗ trợ hoàn chỉnh. S5S6S7S8S9

6.1 CVE-2026-15176: URI đã được viết lại để bao gồm các điều kiện từ chối ánh xạ đường dẫn alias

Cam kết ngược dòng đã sửa đổi ngx_http_map_uri_to_path() trong src/http/ngx_http_core_module.c:

- if (alias && !r->valid_location) {
+ if (alias && (!r->valid_location || r->uri_changed)) {

tiêu điểm đánh giá: Không thể tiếp tục tính toán đường dẫn hệ thống tệp khi URI đã thay đổi nhưng ngữ nghĩa vị trí tương ứng của alias không còn đáng tin cậy nữa. Đây là một cải tiến cho ràng buộc trước trạng thái. Việc kiểm tra xem yêu cầu URI có chứa các ký tự không hợp lệ không phải là việc đơn giản. S5

6.2 CVE-2026-93479: Phân biệt chính xác giữa độ dài dữ liệu đầu ra và độ dài dự trữ

Cam kết ngược dòng cập nhật src/http/ngx_http_script.c và src/stream/ngx_stream_script.c cùng một lúc. Mục đích cốt lõi có thể được tóm tắt như sau:

- n = len;
+ n = 0;
  /* ...计算实际脚本输出长度... */
- value->len = n;
- value->data = ngx_pnalloc(pool, n);
+ value->len = n + len;
+ value->data = ngx_pnalloc(pool, n + len);

Ở đây, pool là tên tham số minh họa: biểu thức phân bổ HTTP và Stream thực tế khác nhau. Thay đổi này trước tiên sẽ tính toán độ dài đầu ra của tập lệnh, sau đó thêm độ dài dành riêng vào phân bổ cuối cùng để đầu ra không ghi đè lên khoảng trống dành riêng. S6

Khi kiểm tra và backport, bộ đánh giá tương ứng của HTTP/Stream cũng phải được đề cập; chỉ kiểm tra tệp cú pháp cấu hình của map không thể chứng minh rằng lỗi đã được sửa.

6.3 CVE-2026-97205: Đặt ngưỡng an toàn cho số lượng hoạt động không đồng bộ 8 bit

Thượng nguồn được thêm vào tại src/http/ngx_http_request.h:

#define NGX_HTTP_MAX_BLOCKED 250

Và thêm các mục tương tự để đọc tệp không đồng bộ, chờ bộ đệm, lọc đầu ra và vận hành luồng:

if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) {
    /* 使用同步路径，或者拒绝新的异步操作 */
}

trọng tâm đánh giá: Tất cả các đường dẫn mã thực tế sẽ thêm r->main->blocked phải được đề cập. Bạn không thể chỉ ghi hằng số ngưỡng vào tệp tiêu đề. Backport cũng cần kiểm tra sự phối hợp hoàn chỉnh của dự phòng đồng bộ, gọi lại không đồng bộ và trả về lỗi để đảm bảo rằng bế tắc hoặc rò rỉ tham chiếu sẽ không do việc từ chối trực tiếp các tác vụ. S7

6.4 CVE-2026-95101: Duy trì trạng thái skip riêng biệt cho các khung không xác định

Thượng nguồn thêm trường skip trong cấu trúc trạng thái trình phân tích cú pháp HTTP/3 và thực hiện phân tách trạng thái:

if (st->type != NGX_HTTP_V3_FRAME_DATA && st->length > 0) {
    st->skip = st->length;
    st->length = 0;
    st->state = sw_skip;
}
/* ... */
rc = ngx_http_v3_parse_skip(b, &st->skip);

Điều quan trọng không phải là “vô hiệu hóa các khung HTTP/3 không xác định”, mà là để đảm bảo rằng qua nhiều lần đọc, số byte bị bỏ qua và độ dài tải trọng DATA luôn được quản lý bởi các trạng thái độc lập. Các bài đánh giá nên tập trung vào phân mảnh bộ đệm chéo khung không xác định và tính nhất quán cuối cùng của client_max_body_size. S8

6.5 CVE-2026-97629: Đồng bộ hóa mảng khe khóa TLS hoàn chỉnh

Những thay đổi ngược dòng được đặt tại src/event/ngx_event_openssl.c:

  ngx_memcpy(keys->elts, cache->ticket_keys,
-            2 * sizeof(ngx_ssl_ticket_key_t));
+            keys->nelts * sizeof(ngx_ssl_ticket_key_t));

Hình ảnh gốc chứa ba khe khóa, nhưng chỉ có hai khe khóa đầu tiên được sao chép. Thay vào đó, hãy đồng bộ hóa dựa trên số lượng phần tử mảng thực tế để đảm bảo rằng bộ khóa biểu quyết của Worker nhất quán với bộ nhớ dùng chung. Khi xem xét, hãy xác nhận rằng logic phân bổ, khởi tạo, khóa chia sẻ và xoay mảng là nhất quán, thay vì chỉ kiểm tra sửa đổi độ dài memcpy một lần. S9

6.6 Tại sao không nên chỉ áp dụng các mảnh vá rải rác?

Năm sửa đổi này lần lượt bao gồm src/http, src/stream, src/http/v3 và src/event, đồng thời các phiên bản cũ hơn có thể có cổng lùi bảo mật và tiện ích mở rộng không chính thức. Backporting sẽ tạo thành ma trận kiểm tra sau:

Kiểm tra đối tượng	Những gì phải được xác nhận
nguồn vá	Đệ trình chính thức, phù hợp với phiên bản mục tiêu, bản vá hoàn chỉnh và xác minh chữ ký
Bộ bản vá gốc	Không xung đột với các sửa đổi lịch sử như CVE-2026-42533, cổng sau phân phối, v.v.
đường dẫn mã	Tập lệnh HTTP + Stream, AIO/luồng, HTTP/3, OpenSSL đều được áp dụng
Biên soạn tương thích	OpenSSL, PCRE, mô-đun ABI, mô-đun động và các phần phụ thuộc liên kết đều nhất quán
hồi quy hàm	Viết lại alias, nhật ký động, SSI/AIO, tải lên HTTP/3, nối lại phiên mTLS
thời gian chạy	Tất cả Worker/Pod đều chạy các bản dựng mới đã được xác minh, không còn hình ảnh cũ nào

Đối với các nhóm duy trì bản phát hành của riêng mình, nên giữ ID bản vá, phiên bản gói, nhật ký bản dựng và báo cáo hồi quy cho mỗi CVE có thể kiểm tra được; đối với hoạt động và bảo trì thông thường, giải pháp an toàn nhất là cài đặt các bản cập nhật bảo mật hoàn chỉnh của nhà cung cấp.

7. Truy ngược lỗ hổng lịch sử, các nhánh cũ và các sản phẩm khác

Lỗ hổng cốt lõi 7.1 NGINX đáng được xác nhận đồng thời từ tháng 5 đến tháng 9 năm 2026

Nhiều phiên bản NGINX lâu ngày không được cập nhật không chỉ bị ảnh hưởng bởi sự cố mới trong tháng 10. Sau đây là các nút sửa chữa tiêu biểu trong thời gian tới: S1S2

CVE	Bản sửa lỗi đầu tiên	Những rủi ro và điều kiện chính cần kiểm toán
CVE-2026-42945	Stable 1.30.1 / Mainline 1.31.0, ngày 13 tháng 5	rewrite Logic thay thế và thu thập biểu thức chính quy ẩn danh kích hoạt tràn vùng lưu trữ, RCE tiềm năng; có những báo cáo công khai về những nỗ lực tấn công ngoài ý muốn
CVE-2026-9256	Stable 1.30.2 / Mainline 1.31.1, ngày 22 tháng 5	Việc ước tính độ dài và thu thập biểu thức chính quy chồng chéo trong rewrite dẫn đến tràn
CVE-2026-42055	Stable 1.30.3 / Mainline 1.31.2, ngày 17 tháng 6	HTTP/2 Cấu hình cụ thể cho ngược dòng hoặc gRPC, điều kiện tiêu đề yêu cầu lớn sẽ gây ra lỗi tràn bộ đệm
CVE-2026-42530	Mainline 1.31.2, ngày 17 tháng 6	HTTP/3 Sử dụng miễn phí; nhãn hiệu chính thức bị ảnh hưởng phạm vi 1.31.0–1.31.1
CVE-2026-42533	Stable 1.30.4 / Mainline 1.31.3, ngày 15 tháng 7	Đánh giá biến chụp map + biểu thức chính quy gây ra lỗi tràn vùng nhớ heap và các bản vá tiếp theo có mối tương quan hồi quy với CVE-2026-93479 vào tháng 10
CVE-2026-60005	Stable 1.30.4 / Mainline 1.31.3, ngày 15 tháng 7	Nội dung bộ nhớ ngx_http_slice_module bị rò rỉ trong các điều kiện cập nhật bộ đệm và biến cụ thể
CVE-2026-56434	Stable 1.30.4 / Mainline 1.31.3, ngày 15 tháng 7	SSI có liên quan đến UAF; nguyên nhân không giống root như lỗ hổng đếm AIO của tháng 10
CVE-2026-90439	Stable 1.30.5 / Mainline 1.31.6, ngày 15 tháng 9	Tràn vùng nhớ heap hạn chế của HTTP/3 + tổ hợp phiên bản OpenSSL cụ thể, chủ yếu được biểu hiện dưới dạng sự cố/hỏng bộ nhớ hạn chế

Các lỗ hổng khác như NGINX Core, HTTP/2, bộ ký tự và SMTP được công bố vào năm 2026 cũng cần được điều tra theo các bản tin bảo mật chính thức; bảng này có chủ ý tập trung vào các sự kiện điển hình có liên quan nhất đến việc triển khai proxy ngược công khai NGINX hiện tại và có ý nghĩa về an toàn bộ nhớ hoặc tính toàn vẹn của yêu cầu. không phải là tất cả các CVE vào năm 2026. Danh sách. S1

Tại sao phải đặc biệt chú ý đến CVE-2026-42945

Có các bản tin bảo mật từ các cơ quan chính phủ ghi lại các hoạt động khai thác lộ liễu và thông tin mã khai thác công khai cho lỗ hổng rewrite này vào tháng 5. Do đó, đối với các trường hợp chưa được vá trong một thời gian dài từ tháng 5 đến nay và có các biểu thức chính quy phức tạp mở được viết lại trên mạng công cộng, ngoài việc hoàn tất việc sửa chữa, sự cố Worker bất thường, nhật ký truy cập và các thay đổi đáng ngờ tại thời điểm đó cần được xem xét bổ sung. S23

“Đã xảy ra một nỗ lực tấn công” không tự động chứng minh rằng kẻ tấn công đã thực thi các lệnh một cách đáng tin cậy trên mọi mục tiêu; khi liên quan đến phản hồi sự cố, các dấu hiệu xâm phạm và sự cố quy trình phải được điều tra tách biệt khỏi bằng chứng thực sự về việc leo thang hoặc duy trì đặc quyền.

7.2 Khắc phục các phiên bản cũ hơn và các bản phân phối ngược

NGINX Các nhánh khác nhau có chu kỳ hỗ trợ riêng và thời gian giới thiệu lỗ hổng khác nhau. Năm bản vá mới không thể được triển khai cho tất cả các cây nguồn ban đầu mà không được xem xét.

bối cảnh	Chiến lược được đề xuất
Phiên bản phát hành đã công bố bản vá bảo mật đầy đủ	Sử dụng các gói của nhà cung cấp và ghi lại các phiên bản gói hoàn chỉnh; tránh thay thế bằng các tệp nhị phân trần ngược dòng không tương thích
Debian 12 và các bản phát hành bị ảnh hưởng khác chưa được tất cả các CVE trong đợt này bao gồm	Gửi yêu cầu công việc rủi ro, hạn chế tiếp xúc bên ngoài và kiểm tra trạng thái nhà cung cấp/ELTS; di chuyển hoặc sử dụng chuỗi phát hành bảo trì có thể kiểm chứng khi cần thiết
Các nhánh lịch sử đã kết thúc hỗ trợ ngược dòng	Ưu tiên di chuyển sang các phiên bản được hỗ trợ; nếu cần phải thực hiện backport ngắn hạn, người bảo trì sẽ đánh giá các phần phụ thuộc và khả năng tương thích của bản vá, đồng thời viết các bài kiểm tra hoàn chỉnh.
Đi kèm với phuộc NGINX (OpenResty, Tengine, cổng tùy chỉnh)	Trước tiên, hãy xác định xem đường dẫn mã tương ứng có được bao gồm hay không, sau đó sử dụng câu lệnh bảo mật của người duy trì nhánh rẽ. Nó không thể tương đương trực tiếp với phiên bản ngược dòng.
Các bản vá bảo mật dẫn đến những thay đổi trong chức năng kinh doanh	Áp dụng triển khai theo giai đoạn, chuyển đổi lưu lượng giữa các phiên bản và điều chỉnh cấu hình; việc khôi phục phiên bản chưa cố định của mạng công cộng mà không cách ly là không phù hợp.

7.3 Khắc phục riêng biệt cho njs, Ingress và NGINX Core

• njs: Ngoài chương trình chính NGINX, bạn cũng cần kiểm tra phiên bản của chính mô-đun JavaScript NGINX. njs 1.0.2 khắc phục sự cố cạn kiệt bộ nhớ phân tích cú pháp XML và sự cố không nhất quán về xác thực XML vào tháng 10 năm 2026 với các thuộc tính tham chiếu thực thể. Đối với các hoạt động triển khai liên quan đến xác minh chữ ký XML bằng nginx-saml, bạn nên đọc thêm hướng dẫn chính thức về njs cho các tình huống bổ trợ. S20
• F5 NGINX Plus / NGINX Bộ điều khiển xâm nhập: Ngoài ra, bộ điều khiển và Gateway Fabric đều có thể có các bản tin bảo mật bổ sung, các phiên bản đóng gói khác nhau và các lỗ hổng chính sách riêng. Nâng cấp một lớp không có nghĩa là tự động cập nhật lớp khác. S19
• Cộng đồng Kubernetes ingress-nginx: Các quan chức của Kubernetes đã thông báo rằng bộ điều khiển đã ngừng bảo trì vào tháng 3 năm 2026 và không thể nhầm lẫn kho của nó với bộ điều khiển F5. Các doanh nghiệp bị ảnh hưởng nên lập kế hoạch di chuyển suôn sẻ và xác minh các chú thích Ingress cũng như sự khác biệt về ngữ nghĩa của Gateway API thay vì chờ đợi phiên bản bảo mật mới. S21

8. Tiêu chí chấp nhận và kiểm tra tiếp theo

Nên sử dụng danh sách sau làm điều kiện chấp nhận cho các lệnh sản xuất thay đổi:

dự án	Tiêu chuẩn trình độ	Bằng chứng có thể được lưu giữ
Bảo hiểm tài sản và cổng thông tin	Tất cả các phiên bản bên ngoài và được kết nối trực tiếp có thể vượt qua CDN đã được kiểm kê.	Tên miền, LB, IP, danh sách Pod/container
Nguồn gói và phạm vi sửa chữa	Sử dụng các phiên bản đã được xác nhận để bao gồm tất cả các CVE hiện hành	Tư vấn bảo mật ngược dòng, USN/DSA, phiên bản gói, thông báo hình ảnh
quá trình cũ thoát	Tất cả các thùng chứa master/worker/container cũ đã được thay thế	PID/thời gian bắt đầu, trạng thái triển khai luân phiên, hình ảnh đang chạy
Kiểm tra cấu hình	Các kết hợp rủi ro cao đã bị loại bỏ hoặc được che phủ bởi các bản vá và các mối quan hệ kế thừa đã được xác minh	bản tóm tắt và kiểm toán được biên tập lại của nginx -T
TLS/mTLS	Chứng chỉ tin cậy được thông qua; chứng chỉ không hợp lệ hoặc bị thiếu sẽ bị từ chối; việc nối lại phiên không bỏ qua xác thực	Kiểm tra ủy quyền âm tính/dương tính, kết quả kiểm tra TLS được kiểm soát
Nội dung yêu cầu HTTP/3	Kích hoạt đường dẫn cố định; nội dung yêu cầu ngược dòng và điều chỉnh hoạt động chính xác	HTTP/3, tải lên proxy, kiểm tra hồi quy giới hạn âm lượng
SSI/AIO	Chức năng đáp ứng yêu cầu, Worker không có hiện tượng dừng bất thường	Giám sát hồi quy kinh doanh, sự cố và tỷ lệ lỗi
Giám sát vận hành và bảo trì	Không có ngoại lệ rõ ràng 5xx, SIGSEGV, quá trình thoát liên tục	Các chỉ báo và nhật ký dịch vụ trước và sau khi thay đổi
Chiến lược quay lui	Nếu cần khôi phục, trước tiên hãy hạn chế tiếp xúc và duy trì ranh giới bảo mật	Thay đổi đơn đặt hàng, quy trình khẩn cấp và kế hoạch cách ly
vòng đời tiếp theo	Xác định đăng ký bản tin bảo mật, tần suất cập nhật vùng chứa và kế hoạch di chuyển chi nhánh	Nâng cấp sổ cái, người chịu trách nhiệm và ngày kiểm toán tiếp theo

8.1 Bạn nên tập trung vào điều gì trong nhật ký và trạng thái đang chạy?

Khắc phục sự cố bất thường trên các máy chủ đã tồn tại trong một thời gian dài worker process exited on signal 、 SIGSEGV, lỗi yêu cầu tăng đột biến, tập hợp quyền truy cập nguồn bất thường, thành công nối lại/xác thực phiên TLS không mong muốn và hành vi nội dung yêu cầu phụ trợ bất thường. Các chỉ số này chỉ có thể được sử dụng làm manh mối điều tra và không đủ bằng chứng để chứng minh trực tiếp rằng một CVE nào đó đã bị khai thác. ;Việc thiếu nhật ký liên quan không chứng tỏ rằng chưa có cuộc tấn công nào.

8.2 Từ ngữ kết luận rủi ro cuối cùng được đề xuất

Báo cáo nghiệm thu đối với môi trường sản xuất phải sử dụng biểu thức chính xác sau:

Nguồn gói phần mềm và lối vào dịch vụ bên ngoài NGINX đã được xác định. Tất cả các phiên bản hiện hành đã được nâng cấp lên phiên bản bảo mật chính thức ngược dòng hoặc cổng sau được nhà cung cấp bản phát hành xác nhận đã được hoàn thành; Worker cũ và các container cũ đã được thay thế. Bí danh/viết lại/bản đồ, nội dung yêu cầu AIO/SSI, HTTP/3 và các cấu hình liên quan đến Vé phiên TLS/mTLS đã được kiểm tra và vượt qua các bài kiểm tra hồi quy tính toàn vẹn của yêu cầu, xác thực và chức năng. Đối với các trường hợp chưa hoàn thành việc nâng cấp thì đăng ký bổ sung khu vực bị ảnh hưởng, biện pháp bồi thường, người chịu trách nhiệm và thời hạn hoàn thành.

Nếu bản vá cho Debian 12 hoặc các bản phát hành khác vẫn chưa hoàn thiện thì việc đánh giá toàn bộ biểu mẫu chấp nhận là “đã hoàn thành” là không phù hợp; CVE chưa được giải quyết, có cấu hình kích hoạt tương ứng hay không, trạng thái cách ly và lộ trình nâng cấp cuối cùng phải được ghi lại rõ ràng.

---

Phụ lục: Nguồn và link được trích dẫn

Mô tả: Các số [Sx] trong văn bản đều tương ứng với phần này. Phần sau đây ưu tiên các thông báo bảo mật dự án thượng nguồn, cam kết mã, thông báo phát hành của nhà cung cấp và thông tin của cơ quan an ninh quốc gia. Mức độ nghiêm trọng của các lỗ hổng được trích dẫn được mô tả theo tiêu chí đánh giá của từng tổ chức phát hành; ngày xác minh dữ liệu là ngày 27 tháng 10 năm 2026.

S1 — Bản tin bảo mật chính thức của NGINX Open Source

• https://nginx.org/en/security_advisories.html

Chứa các phiên bản bị ảnh hưởng ngược dòng, các nhánh sửa lỗi và mức độ nghiêm trọng chính thức của 5 CVE tháng 10, đồng thời cũng bao gồm các lỗ hổng lịch sử cho đến năm 2026.

S2 — Bản ghi phát hành phiên bản chính thức của NGINX

• https://nginx.org/news.html
• https://nginx.org/en/CHANGES-1.30

Xác nhận 1.30.6 / 1.31.7 của 2026-10-14, 1.31.8 của 2026-10-21 và các mốc phát hành bảo mật quan trọng từ tháng 5 đến tháng 9.

S3 - Cơ quan An ninh mạng Singapore: F5 NGINX Ba lỗ hổng nghiêm trọng

• https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-150/

Mô tả điểm số CVSS v4.0 9.2, điều kiện cấu hình bắt buộc và đề xuất giảm nhẹ tạm thời cho CVE-2026-15176, CVE-2026-93479 và CVE-2026-97205.

S4 - NHS England: F5 NGINX Khuyến cáo rủi ro cao

• https://digital.nhs.uk/cyber-alerts/2026/cc-4872

Mô tả tác động của DoS/RCE tiềm ẩn của các vấn đề về an toàn bộ nhớ và các hạn chế như ASLR bị tắt hoặc bỏ qua.

S5 — Cam kết nguồn chính thức: CVE-2026-15176

• https://github.com/nginx/nginx/commit/f8a23425bd6840c4c36b4264edf576ba3646156f

Tương ứng với kiểm tra trạng thái của alias và r->uri_changed trong ngx_http_map_uri_to_path().

S6 - Cam kết nguồn chính thức: CVE-2026-93479

• https://github.com/nginx/nginx/commit/6aa4b3fdd4fdc156153f2981eb4070690624447c

Tương ứng với độ dài tập lệnh HTTP/Stream và logic phân bổ bộ đệm dành riêng.

S7 - Cam kết nguồn chính thức: CVE-2026-97205

• https://github.com/nginx/nginx/commit/6adfc05ece48f92446383ec1f145446848694698

Tương ứng với ngưỡng đếm r->main->blocked NGX_HTTP_MAX_BLOCKED 250 và dự phòng đường dẫn không đồng bộ.

S8 — Cam kết nguồn chính thức: CVE-2026-95101

• https://github.com/nginx/nginx/commit/1c173a2d8767730e678c27446138d7ae5dd6fd64

Việc phân tách trạng thái tương ứng với độ dài còn lại của khung không xác định HTTP/3 và độ dài nội dung yêu cầu DATA.

S9 — Cam kết nguồn chính thức: CVE-2026-97629

• https://github.com/nginx/nginx/commit/1916f26e6ca49296568633d309777e36527e5bb2

Tương ứng với tất cả các khe khóa trong quá trình đồng bộ hóa Vòng quay vé phiên TLS.

S10 — F5: CVE-2026-15176 Thông báo của nhà cung cấp

• https://my.f5.com/manage/s/article/K000162416

Liệt kê các yếu tố kích hoạt như alias, rewrite, $request_filename và nhật ký truy cập.

S11 — F5: CVE-2026-93479 Thông báo của nhà cung cấp

• https://my.f5.com/manage/s/article/K000162607

Liệt kê bản đồ thu thập biểu thức chính quy, đường dẫn root và các điều kiện đánh giá biến nhật ký.

S12 — Tài liệu mô-đun TLS/SSL chính thức của NGINX

• https://nginx.org/en/docs/http/ngx_http_ssl_module.html

Mô tả ssl_session_cache, ssl_session_tickets, ssl_session_ticket_key và xác thực chứng chỉ ứng dụng khách cũng như các hướng dẫn khác.

S13 — Tư vấn bảo mật: Ubuntu USN-8955-1 (2026-10-26)

• https://ubuntu.com/security/notices/USN-8955-1

Cung cấp gói phần mềm hoàn chỉnh phiên bản cố định và phạm vi phân phối của Ubuntu 22.04 / 24.04 / 26.04 / 26.10.

S14 — Tư vấn bảo mật: Debian DSA-6575-1 (2026-10-21)

• https://lists.debian.org/debian-security-announce/2026/msg00490.html

Xác nhận gói sửa lỗi bảo mật 1.26.3-3+deb13u10 cho Debian 13 / trixie và ghi lại liên kết cổng sau cho CVE-2026-93479.

S15 — Theo dõi lỗ hổng: Debian Security Tracker: CVE-2026-15176

• https://security-tracker.debian.org/tracker/CVE-2026-15176

Được sử dụng để xác minh trạng thái sửa lỗi phân phối của Debian 12 / bookworm và Debian 13 / trixie. Trạng thái này có thể thay đổi với các bản cập nhật bảo mật trong tương lai.

S16 — Theo dõi lỗ hổng: Debian Security Tracker: CVE-2026-95101

• https://security-tracker.debian.org/tracker/CVE-2026-95101

Xác nhận bổ sung về trạng thái bảo mật của lỗ hổng HTTP/3 trên các nhánh Debian khác nhau.

S17 — Tư vấn bảo mật: Red Hat: CVE-2026-93479

• https://access.redhat.com/security/cve/cve-2026-93479

Hiểu biết bổ sung về mối tương quan giữa lỗ hổng hồi quy tháng 10 và bản sửa lỗi cho CVE-2026-42533 tháng 7.

S18 — Tài liệu mô-đun proxy ngược chính thức của NGINX

• https://nginx.org/en/docs/http/ngx_http_proxy_module.html
• https://nginx.org/en/docs/http/ngx_http_core_module.html

Truy vấn ngữ nghĩa và giá trị mặc định của các cấu hình như proxy_request_buffering, client_max_body_size, alias, aio, v.v.

S19 — Ghi chú phát hành chính thức của NGINX Plus

• https://docs.nginx.com/nginx/releases/

Liệt kê các nhánh, phiên bản, bản vá lỗi và lời nhắc nâng cấp về khả năng tương thích của CR/LTS.

S20 — Bản tin bảo mật chính thức của NGINX JavaScript / njs

• https://nginx.org/en/docs/njs/security.html
• https://nginx.org/en/docs/njs/changes.html

Chứa njs 1.0.2 tháng 10 năm 2026 và các vấn đề về xác thực XML, cạn kiệt bộ nhớ.

S21 — Kubernetes: Hướng dẫn nghỉ hưu chính thức của cộng đồng ingress-nginx

• https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/
• https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/

Xin lưu ý rằng dự án đã dừng các bản phát hành và bản sửa lỗi bảo mật mới vào tháng 3 năm 2026 và bạn nên di chuyển bộ điều khiển được bảo trì hoặc Gateway API.

S22 — Hướng dẫn nâng cấp nhị phân trực tuyến và kiểm soát dịch vụ chính thức của NGINX

• https://nginx.org/en/docs/control.html

Phân biệt các phương pháp tải lại cấu hình, khởi động lại và nâng cấp tệp thực thi trực tuyến để chấp nhận chuyển đổi quy trình.

S23 - Thông báo bảo mật của chính phủ: Lỗ hổng viết lại NGINX tháng 5 năm 2026

• https://its.ny.gov/2026-051
• https://www.govcert.gov.hk/en/alerts_detail.php?id=1881

Cung cấp các đề xuất cập nhật bảo mật và bối cảnh rủi ro lịch sử cho CVE-2026-42945; các phán quyết liên quan đến việc khai thác ngoài tự nhiên phải dựa trên thông báo của cơ quan vào thời điểm đó và bằng chứng vụ việc khác.

S24 — F5: CVE-2026-95101 và CVE-2026-97629 Thông báo của nhà cung cấp

• https://my.f5.com/manage/s/article/K000162613
• https://my.f5.com/manage/s/article/K000162606

Bao gồm các rủi ro về việc chèn nội dung yêu cầu HTTP/3 và xoay khóa Vé TLS tự động tương ứng.

S25 — F5: CVE-2026-97205 Thông báo của nhà cung cấp

• https://my.f5.com/manage/s/article/K000162608

Mô tả Các điều kiện kích hoạt SSI/AIO và nguy cơ hỏng bộ nhớ tiềm ẩn.

Cập nhật bảo mật NGINX: kiểm tra cấu hình, nâng cấp và xác minh