본문 바로가기
Tiếng Việt/.NET

[.NET] CVE-2026-88092 là gì? Lỗi request smuggling ở Kestrel, cần cập nhật runtime

by Kor-IT 2026. 10. 28.
반응형

Lỗ hổng CVE-2026-88092 request smuggling ở Kestrel trong ASP.NET Core

 

CVE-2026-88092 là lỗ hổng trong Kestrel, web server mặc định của ASP.NET Core. Khi một kết nối HTTP/1 bị ngắt đột ngột, Kestrel có thể hiểu phần thân yêu cầu (request body) còn chưa đọc thành một yêu cầu mới. Sau reverse proxy, lỗi này có thể dẫn tới HTTP request smuggling. Điểm CVSS là 9,4. Bạn sửa bằng cách cập nhật runtime ASP.NET Core lên 8.0.32, 9.0.21 hoặc 10.0.13 trở lên rồi khởi động lại ứng dụng.

 

Bài viết đối chiếu thông báo bảo mật .NET (dotnet/announcements #472), Microsoft Security Update Guide (MSRC), GitHub Security Advisory và ghi chú phát hành tháng 10. Muốn biết máy chủ của bạn có bị ảnh hưởng không, xem phần “Ứng dụng nào bị ảnh hưởng”. Các bước xử lý nằm ở phần “Cần làm gì ngay”.

 

Đọc bằng ngôn ngữ khác: 한국어 · English · 日本語

 

 

CVE-2026-88092 qua một bảng

Bảng dưới chỉ gồm thông tin đã được công bố chính thức.

 

Cập nhật đến ngày 28/10/2026, dựa trên thông báo .NET #472 và trang MSRC.

 

Mục Nội dung
Công bố Thứ Ba, 13/10/2026 (bản cập nhật định kỳ)
Vị trí lỗi Kestrel (ASP.NET Core)
Phân loại CWE-444, HTTP request smuggling
Điểm CVSS 3.1: 9,4 (Critical)
MSRC Important, Tampering
Điều kiện Không cần xác thực, không cần người dùng thao tác
Phiên bản .NET 8, 9, 10 và .NET 11 RC1 trở xuống
Khai thác Chưa công khai, chưa bị khai thác (theo MSRC, tại thời điểm công bố)
Xử lý Cập nhật runtime, khởi động lại ứng dụng

 

Thông báo chỉ đích danh thành phần Microsoft.AspNetCore.Server.Kestrel.Core, và người báo cáo lỗi được ghi là thegoldmandm. Trong 46 thông báo bảo mật .NET ngày 13/10/2026, đây là lỗi có điểm CVSS cao thứ hai, đồng thời cao nhất trong số các thông báo có tên ASP.NET Core.

 

 

Lỗi nằm ở đâu: phần thân còn sót sau khi kết nối bị ngắt

Với HTTP/1.1, một kết nối có thể gửi nhiều yêu cầu nối tiếp nhau. Máy chủ phải biết thân của yêu cầu trước kết thúc ở đâu thì mới tìm được điểm bắt đầu của yêu cầu sau. Nếu reverse proxy và máy chủ hiểu ranh giới này khác nhau, kẻ tấn công có thể dùng kỹ thuật HTTP request smuggling: giấu thêm một yêu cầu vào luồng.

 

Theo thông báo, lỗi của Kestrel như sau: khi một kết nối HTTP/1 bị ngắt đột ngột (abort), nếu vẫn còn byte của thân yêu cầu chưa đọc, Kestrel có thể phân tích lại các byte đó thành một yêu cầu khác. Dữ liệu vốn thuộc thân của yêu cầu trước trở thành một yêu cầu mới.

 

Điều xảy ra sau reverse proxy (sơ đồ khái niệm)
1
Yêu cầu có chủ đích
Kẻ tấn công chưa xác thực gửi yêu cầu HTTP/1.1 qua reverse proxy
2
Proxy chuyển tiếp
Proxy chuyển yêu cầu này cho Kestrel như bình thường
3
Kestrel ngắt kết nối
Việc xử lý kết thúc khi vẫn còn byte thân chưa đọc
4
Ranh giới yêu cầu bị lệch
Byte còn sót bị hiểu thành yêu cầu mới, nên một yêu cầu ngoài ý muốn có thể chen vào
Nguồn: Thông báo bảo mật .NET #472, FAQ của MSRC

 

Theo FAQ của MSRC, đường tấn công là các yêu cầu đi qua reverse proxy tới máy chủ bị ảnh hưởng. Kẻ tấn công không cần tài khoản, và cũng không ai phải bấm vào gì cả. Một yêu cầu HTTP/1.1 được tạo có chủ đích có thể khiến proxy và Kestrel hiểu ranh giới yêu cầu khác nhau, và chính khoảng lệch đó cho phép một yêu cầu ngoài ý muốn chen vào.

 

Nói chung, request smuggling nguy hiểm vì yêu cầu được chèn vào có thể không đi qua bước kiểm tra của proxy. Thông báo .NET xếp lỗi này vào nhóm “vượt qua tính năng bảo mật”, MSRC gọi là “Tampering”, và cả hai nguồn đều đánh giá tác động lên tính bí mật và tính toàn vẹn ở mức cao (High). Tuy vậy, thông báo không nêu ví dụ cụ thể về thiệt hại.

 

 

Ứng dụng nào bị ảnh hưởng

Runtime ASP.NET Core của .NET 8, 9, 10 và các bản xem trước đến RC1 của .NET 11 bị ảnh hưởng. Thông báo chỉ đích danh Kestrel, còn đường tấn công mà MSRC mô tả là máy chủ đứng sau reverse proxy.

 

Cần xem gì theo cách triển khai
Kestrel sau proxy Đường tấn công
Ứng dụng nhận yêu cầu bằng Kestrel sau reverse proxy như Nginx, YARP hoặc IIS out-of-process
Cần làm
Cập nhật runtimeKhởi động lại
MSRC chỉ ghi “reverse proxy”. Tên sản phẩm chỉ là ví dụ
Triển khai tự chứa self-contained
Ứng dụng đóng gói sẵn runtime, và các image container
Cần làm
Publish lại bằng SDK mớiBuild lại image
Cập nhật runtime trên máy chủ không thay đổi bản đóng gói
Thông báo không nhắc tới Chưa nêu ảnh hưởng
ASP.NET Core 2.3 (.NET Framework) không có trong danh sách. Thông báo không nói IIS in-process hay HTTP.sys có bị ảnh hưởng không
Cần làm
Vẫn cập nhật runtime nếu ở phiên bản bị ảnh hưởng
Danh sách là dải phiên bản runtime, không phải danh sách các kiểu hosting
Nguồn: Thông báo bảo mật .NET #472, MSRC, Microsoft Learn

 

Phiên bản bị ảnh hưởng và phiên bản đã sửa theo thông báo (tính theo runtime):

 

Dòng Bị ảnh hưởng Đã sửa
.NET 8 8.0.0 – 8.0.31 8.0.32 (SDK 8.0.426)
.NET 9 9.0.0 – 9.0.20 9.0.21 (SDK 9.0.319)
.NET 10 10.0.0 – 10.0.12 10.0.13 (SDK 10.0.402)
.NET 11 preview.1 – RC1 RC2

 

  • IIS in-process: theo Microsoft Learn, chế độ in-process dùng IIS HTTP Server thay cho Kestrel và là mặc định trên IIS từ ASP.NET Core 3.0. Tuy vậy, thông báo không nói IIS in-process có bị ảnh hưởng hay không. Bản cập nhật áp dụng cho cả shared runtime, nên bạn vẫn cập nhật bất kể dùng máy chủ nào
  • ASP.NET Core 2.3: bản chạy trên .NET Framework không có trong danh sách lần này
  • Visual Studio: bảng của MSRC có cả Visual Studio 2022 (17.14.42) và 2026 (18.10.4). Thông báo hướng dẫn cập nhật SDK cài qua Visual Studio bằng cách cập nhật Visual Studio

 

반응형

 

Cần làm gì ngay

Thông báo yêu cầu cài runtime hoặc SDK .NET mới nhất rồi khởi động lại ứng dụng. Ứng dụng triển khai tự chứa phải biên dịch và triển khai lại.

 

# Xem các runtime ASP.NET Core đã cài trên máy chủ
dotnet --list-runtimes
# Đã sửa: 8.0.32 / 9.0.21 / 10.0.13 trở lên

# Triển khai tự chứa: publish lại bằng SDK đã cập nhật
dotnet publish -c Release -r linux-x64 --self-contained

 

  1. Cập nhật runtime và SDK: cập nhật cả máy chủ chạy ứng dụng lẫn máy build. Máy chủ IIS cập nhật bằng Hosting Bundle (cài cả .NET runtime và ASP.NET Core Module). Tính đến ngày 28/10/2026, bản tải về mới nhất là bản ngoài chu kỳ (out-of-band) ngày 25/10/2026 (8.0.33, 9.0.22, 10.0.14). Các bản này cao hơn dải bị ảnh hưởng của thông báo (8.0.31, 9.0.20, 10.0.12 trở xuống)
  2. Khởi động lại ứng dụng: thông báo ghi rõ phải khởi động lại sau khi cài runtime. Tiến trình đang chạy vẫn dùng runtime cũ
  3. Triển khai tự chứa và container: theo Microsoft Learn, khi publish tự chứa, SDK đóng gói runtime bản vá mới nhất có trên máy publish. Bạn phải publish lại bằng SDK mới. Nếu đã cố định RuntimeFrameworkVersion, hãy sửa cả giá trị đó. Với container, kéo lại image nền mcr.microsoft.com/dotnet/aspnet rồi build lại

 

Gói được nêu trong thông báo có tên Microsoft.AspNetCore.App.Runtime.<nền tảng>. Đây là runtime pack được đóng vào ứng dụng khi publish tự chứa. Thông báo cũng ghi: nếu dự án tham chiếu trực tiếp gói này, hãy nâng tham chiếu lên bản đã sửa.

 

Phần lớn dự án không tham chiếu trực tiếp nên ba bước trên là đủ. Bạn có thể tìm Microsoft.AspNetCore.App.Runtime trong file .csproj để chắc chắn.

 

Theo Microsoft Learn, .NET được cập nhật qua Microsoft Update chứ không phải Windows Update. Windows Server không nhận cập nhật tự động theo mặc định: bạn phải phân phối qua WSUS hoặc Microsoft Update Catalog, hoặc bật khóa registry AllowAUOnServerOS. Vì vậy hãy tự kiểm tra bằng dotnet --list-runtimes trên từng máy chủ.

 

Thông báo và MSRC không đưa ra biện pháp tạm thời bằng cấu hình. Nếu chưa cập nhật được ngay, hãy ưu tiên trước các ứng dụng Kestrel sau proxy mở ra Internet. Đây là cách sắp thứ tự ưu tiên, không phải biện pháp giảm thiểu chính thức.

 

 

Đã có tấn công thực tế chưa

MSRC đánh giá lỗ hổng này là chưa công khai, chưa bị khai thác và ít có khả năng bị khai thác (Exploitation Less Likely, tại thời điểm công bố). Chỉ số tạm thời (temporal) cũng ghi mã khai thác chưa được chứng minh (E:U) và đã có bản sửa chính thức (RL:O), nên điểm tạm thời là 8,2.

 

Điểm cơ bản vẫn cao, 9,4, vì có thể tấn công qua mạng và không cần xác thực hay người dùng thao tác. Nếu thành công, thiệt hại về tính bí mật và toàn vẹn là lớn. Dịch vụ mở ra Internet nên được cập nhật trước, bất kể đánh giá khả năng khai thác.

 

 

Dành cho lập trình viên Việt Nam: tài liệu và cách kiểm tra

Bài này dựa trên thông báo chính thức của Microsoft và .NET (bằng tiếng Anh). Đến ngày 28/10/2026, chưa thấy cảnh báo nào của cơ quan an toàn thông tin Việt Nam về CVE này, nhưng chưa kiểm tra được trực tiếp trang của các cơ quan đó, nên bạn không nên hiểu là chưa có cảnh báo.

 

Bạn có thể tự tra trên trang cảnh báo của Trung tâm Giám sát an toàn không gian mạng quốc gia (NCSC).

 

Tài liệu Kestrel trên Microsoft Learn chưa có bản tiếng Việt. Mở bằng địa chỉ vi-vn vẫn chuyển sang trang tiếng Anh. Khi đọc, bạn sẽ gặp các thuật ngữ tiếng Anh như reverse proxy, request body, self-contained. Bài này giữ nguyên các từ đó để bạn dễ đối chiếu.

 

Những chỗ nên kiểm tra trong dự án:

 

  • Máy chủ: kết quả dotnet --list-runtimes (hoặc dotnet --info)
  • Dockerfile: tag của image nền mcr.microsoft.com/dotnet/aspnet, nhất là khi đã ghim một bản vá cụ thể
  • CI/CD: phiên bản SDK cố định trong global.json hoặc pipeline. Image và ứng dụng tự chứa được tạo từ runtime thấp hơn 8.0.32, 9.0.21 hoặc 10.0.13 sẽ không tự thay đổi
  • Không nhầm với .NET Framework: các bài KB tiếng Việt về .NET Framework là vấn đề khác. CVE này chỉ thuộc ASP.NET Core 8, 9, 10 và 11

 

Những điểm dễ nhầm

  • Có hai tên gọi: thông báo .NET và ghi chú phát hành gọi là “Security Feature Bypass” (vượt qua tính năng bảo mật), còn MSRC và bản ghi CVE gọi là “Tampering”. Đây là cùng một lỗi
  • Có hai mức độ: theo CVSS là Critical (9,4), còn mức nghiêm trọng tối đa của MSRC là Important. Hai mức này dùng tiêu chí khác nhau. Đó vẫn là một lỗi và điểm vẫn là 9,4
  • Khác với CVE-2025-55315 năm ngoái: tháng 10/2025 cũng có lỗi request smuggling trong ASP.NET Core (CVSS 9,9), và lỗi đó còn ảnh hưởng cả ASP.NET Core 2.3. Lỗi lần này có số mới và không gồm bản 2.3
  • Thường là cập nhật runtime, không phải gói: lỗi debug Blazor cùng đợt tháng 10 (CVE-2026-102870) phải nâng gói NuGet. Lần này Kestrel nằm trong shared runtime, nên cập nhật runtime và khởi động lại là đủ (trừ triển khai tự chứa)
  • Bản sửa tối thiểu là 8.0.32, 9.0.21 hoặc 10.0.13; bản mới hơn cũng được: bản ngày 25/10/2026 không liệt kê CVE này nhưng cao hơn dải bị ảnh hưởng. Thông báo #472 chưa được sửa đổi (V1.0)

 

반응형

 

Câu hỏi thường gặp

Dưới đây là bốn câu hỏi hay gặp, kèm câu trả lời ngắn.

 

CVE-2026-88092 là lỗ hổng gì?

Đây là lỗi Kestrel trong ASP.NET Core: khi kết nối HTTP/1 bị ngắt, phần thân yêu cầu chưa đọc có thể được hiểu thành một yêu cầu mới. Ranh giới yêu cầu giữa reverse proxy và máy chủ bị lệch, nên kẻ tấn công có thể chèn yêu cầu. Điểm CVSS 3.1 là 9,4.

 

Cần cập nhật lên phiên bản nào?

Cập nhật runtime ASP.NET Core lên 8.0.32, 9.0.21 hoặc 10.0.13 trở lên. Bản xem trước .NET 11 cần RC2 trở lên. Các bản mới nhất tính đến ngày 28/10/2026 (8.0.33, 9.0.22, 10.0.14) cũng cao hơn mức này.

 

Không dùng proxy thì có an toàn không?

Đường tấn công mà MSRC mô tả là yêu cầu đi qua reverse proxy. Tuy nhiên, thông báo không nói cấu hình không có proxy thì nằm ngoài phạm vi. Nếu đang ở phiên bản bị ảnh hưởng, hãy cập nhật bất kể cấu hình.

 

Có cần sửa gói NuGet không?

Phần lớn là không. Gói trong thông báo là runtime pack dùng khi triển khai tự chứa, nên chỉ cần cập nhật runtime trên máy chủ và khởi động lại ứng dụng. Nếu file .csproj tham chiếu trực tiếp gói Microsoft.AspNetCore.App.Runtime.*, hãy nâng tham chiếu đó lên bản đã sửa.

 

 

Tóm tắt

  • CVE-2026-88092 là lỗi Kestrel có thể hiểu phần thân còn sót của kết nối HTTP/1 bị ngắt thành yêu cầu mới, dẫn tới request smuggling sau reverse proxy
  • Điểm CVSS 9,4, nằm trong nhóm điểm cao của các thông báo .NET tháng 10; chưa ghi nhận bị khai thác (theo MSRC, tại thời điểm công bố)
  • Cập nhật runtime ASP.NET Core lên 8.0.32, 9.0.21, 10.0.13 trở lên và khởi động lại ứng dụng; build lại ứng dụng tự chứa và container

 

Tham khảo

 

Bài viết liên quan

 

반응형

댓글