Trong thế giới phát triển web, một lỗ hổng mới được phát hiện trong ASP.NET Core đã gây chấn động cộng đồng trong khi đồng thời châm ngòi cho một cuộc tranh luận gay gắt về cách chúng ta đo lường các mối đe dọa an ninh. Được chỉ định là CVE-2025-55315, lỗ hổng HTTP request smuggling này mang điểm số CVSS báo động là 9.9 trên 10 — đặt nó vào danh mục cực kỳ nghiêm trọng. Việc tiết lộ này khiến các nhà phát triển phải vội vàng vá lỗi hệ thống của họ trong khi các chuyên gia bảo mật đặt câu hỏi liệu những điểm số cao như vậy dành cho lỗ hổng trong thư viện có cung cấp hướng dẫn ý nghĩa hay chỉ đơn thuần tạo ra sự hoảng loạn không cần thiết.
Bản Chất Kỹ Thuật Của Lỗ Hổng
Ở cốt lõi, CVE-2025-55315 đại diện cho một lỗ hổng HTTP request smuggling ảnh hưởng đến cách ASP.NET Core diễn giải mã hóa phân đoạn (chunked encoding) trong các yêu cầu HTTP. Sự không nhất quán trong việc phân tích cú pháp này có thể cho phép kẻ tấn công bỏ qua các biện pháp kiểm soát bảo mật khi các điều kiện cụ thể trùng khớp. Lỗ hổng trở nên đặc biệt nguy hiểm trong các tình huống mà một máy chủ proxy xử lý xác thực trước khi chuyển tiếp yêu cầu đến Kestrel, máy chủ web của ASP.NET Core. Khi proxy và Kestrel diễn giải các ranh giới phân đoạn khác nhau, một người dùng đã được xác thực có thể đưa lén một yêu cầu độc hại được xử lý với các đặc quyền cao hơn dự định. Biện pháp khắc phục liên quan đến việc cập nhật cách ASP.NET Core xử lý các phần mở rộng phân đoạn, với bài kiểm thử đơn vị RejectsInvalidChunkExtensions được thiết kế đặc biệt để giải quyết vấn đề phân tích cú pháp.
Lưu ý: HTTP request smuggling xảy ra khi các thành phần khác nhau trong chuỗi xử lý yêu cầu diễn giải các thông điệp HTTP khác nhau, có khả năng cho phép kẻ tấn công bỏ qua các biện pháp kiểm soát bảo mật.
Đây là một cách chấm điểm ngu ngốc cho lỗi. Bản thân lỗi không kích hoạt bất kỳ điều nào trong số đó. Một ứng dụng sử dụng thư viện đó mới có thể có lỗ hổng đó.
Cuộc Tranh Cãi Lớn Về Điểm Số CVSS
Cộng đồng bảo mật đã bùng nổ tranh luận về quyết định của Microsoft khi gán điểm số CVSS 9.9 cho lỗ hổng thư viện này. Những người chỉ trích lập luận rằng CVSS được thiết kế cho các hệ thống hoàn chỉnh, không phải cho các thành phần riêng lẻ, và việc chấm điểm các thư viện theo cách này tạo ra các ưu tiên gây hiểu lầm. Mối quan ngại là cách tiếp cận chấm điểm này về lý thuyết có thể gán nhãn mọi lỗi logic trong bất kỳ thư viện nào là nghiêm trọng nếu ai đó tưởng tượng ra một kịch bản triển khai tồi tệ nhất. Các nhóm bảo mật hiện phải đối mặt với áp lực từ ban quản lý để ngay lập tức giải quyết lỗ hổng nghiêm trọng này, ngay cả trong các triển khai mà rủi ro thực tế có thể thấp hơn đáng kể do các lớp bảo mật hiện có và các lựa chọn kiến trúc.
Thực Tế Triển Khai Và Chiến Lược Vá Lỗi
Đối với các tổ chức đang chạy các ứng dụng ASP.NET Core bị ảnh hưởng, quá trình vá lỗi tiết lộ những khác biệt quan trọng trong các mô hình triển khai. Các ứng dụng được triển khai dưới dạng phụ thuộc khung (framework-dependent) có thể chỉ cần cập nhật thời gian chạy .NET và khởi động lại — một quy trình mà các nhóm DevOps có thể xử lý nhanh chóng mà không cần xây dựng lại hoặc triển khai lại toàn bộ ứng dụng. Tuy nhiên, các ứng dụng sử dụng triển khai tự chứa (self-contained deployment) đòi hỏi phải xây dựng lại và triển khai lại hoàn toàn. Sự khác biệt này có ý nghĩa đáng kể đối với các tổ chức khi cân nhắc phản ứng của họ đối với lỗ hổng này, đặc biệt là những tổ chức sử dụng triển khai dạng container nơi chiến lược cập nhật có thể khác với triển khai máy chủ truyền thống.
Các Mô Hình Triển Khai và Yêu Cầu Vá Lỗi
- Triển khai phụ thuộc framework: Cập nhật runtime và khởi động lại ứng dụng
- Triển khai độc lập: Xây dựng lại và triển khai lại toàn bộ ứng dụng
- Triển khai container: Cập nhật base image và triển khai lại các container
- Việc để lộ trực tiếp Kestrel làm tăng rủi ro so với các triển khai được bảo vệ bởi proxy
Sự Nhầm Lẫn Về Đặt Tên .NET Làm Phức Tạp Phản Ứng
Việc tiết lộ lỗ hổng đã vô tình làm nổi bật sự nhầm lẫn đang diễn ra xung quanh quy ước đặt tên .NET của Microsoft. Mặc dù lỗ hổng cụ thể ảnh hưởng đến ASP.NET Core, sự khác biệt giữa .NET Core, .NET Framework và .NET hiện đại (không có hậu tố Core) đã gây ra nhầm lẫn trong việc xác định các hệ thống bị ảnh hưởng. Điều rõ ràng là các phiên bản ASP.NET Core từ 2.3 đến 9.0 bị ảnh hưởng, với các bản vá có sẵn trong các phiên bản 8.0.21 và 9.0.10 được phát hành vào ngày 14 tháng 10 năm 2025. Sự nhầm lẫn về tên gọi nhấn mạnh những thách thức mà các doanh nghiệp phải đối mặt trong việc duy trì danh mục rõ ràng về tài sản phần mềm của họ để quản lý lỗ hổng.
Các Phiên bản Bị Ảnh hưởng và Bản Vá
- ASP.NET Core từ phiên bản 2.3 đến 9.0
- Đã được sửa trong các phiên bản 8.0.21 và 9.0.10 (phát hành ngày 14 tháng 10 năm 2025)
- Điểm CVSS: 9.9 NGHIÊM TRỌNG
- Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L
- CWE: CWE-444 (Diễn giải Không nhất quán các Yêu cầu HTTP)
Tác Động Ngành Và Các Mẫu Phản Ứng
Việc tiết lộ đã kích hoạt các mẫu hình quen thuộc trên toàn ngành — các bảng câu hỏi bảo mật bay qua bay lại giữa nhà cung cấp và khách hàng, các Giám đốc An ninh Thông tin (CISO) yêu cầu hành động ngay lập tức, và các nhóm phát triển đánh giá mức độ phơi nhiễm thực tế của họ. Nhiều tổ chức đang chọn cách vá lỗi bất chấp đánh giá ít có khả năng bị khai thác của Microsoft, nhận ra rằng chỉ riêng điểm số CVSS cao sẽ thu hút sự chú ý từ cả các nhóm bảo mật và những kẻ tấn công tiềm năng. Thực tế là trong khi lỗ hổng này nghiêm trọng, khả năng khai thác của nó phụ thuộc nhiều vào các cấu hình triển khai cụ thể, đặc biệt là liệu Kestrel có được tiếp xúc trực tiếp với internet hay nằm phía sau một proxy có thể tạo ra sự khác biệt trong phân tích cú pháp cần thiết cho việc khai thác.
Sự xuất hiện của CVE-2025-55315 đóng vai trò như một lời nhắc nhở rằng ngay cả các framework web trưởng thành cũng chứa các lỗ hổng phân tích cú pháp tinh vi có thể có những hệ lụy bảo mật nghiêm trọng. Quan trọng hơn, nó làm nổi bật sự căng thẳng ngày càng tăng giữa các hệ thống chấm điểm lỗ hổng và việc áp dụng thực tế của chúng vào các thành phần thư viện. Như một chuyên gia bảo mật nhận xét, tình huống này đại diện cho toàn bộ cỗ máy công nghiệp lỗ hổng thu nhỏ — nơi các rủi ro lý thuyết gặp gỡ thực tế triển khai, và các hệ thống chấm điểm được thiết kế cho các hệ thống hoàn chỉnh đang vật lộn để đại diện chính xác cho các lỗ hổng ở cấp độ thành phần. Cuộc trò chuyện xung quanh lỗ hổng này rất có thể sẽ tiếp tục diễn ra rất lâu sau khi các bản vá được áp dụng, ảnh hưởng đến cách chúng ta chấm điểm và ưu tiên các lỗ hổng thư viện trong tương lai.
Tham khảo: CVE-2025-55315 Detail