SSRF của Azure MCP Server có thể làm rò rỉ Managed Identity Token của nó đến một URL

Microsoft đã công bố CVE-2026-26118 vào ngày 10 tháng 3 năm 2026: một lỗ hổng giả mạo yêu cầu phía máy chủ trong Azure MCP Server Tools, gói cho phép các tác nhân AI và ứng dụng khách MCP thao tác trên tài nguyên Azure bằng ngôn ngữ tự nhiên. Kẻ tấn công có thể tương tác với một tác nhân được hỗ trợ bởi MCP có thể gửi một URL độc hại thay cho mã định danh tài nguyên Azure thông thường; máy chủ sau đó sẽ gửi một yêu cầu ra ngoài đến địa chỉ đó và, theo cách diễn đạt của Microsoft, “có thể bao gồm mã thông báo danh tính được quản lý của nó” — trao cho bên gọi một thông tin xác thực mà đáng lẽ nó không được phép nhìn thấy. Microsoft đã chấm lỗ hổng này CVSS 8.8 và xếp hạng nó là Important, và các gói chứa bản sửa lỗi là 1.0.2 và 2.0.0-beta.17. Khuyến cáo không ghi nhận việc khai thác nào và không có công bố công khai trước bản vá, và không có thiệt hại thực tế nào được ghi nhận cho lỗ hổng này. Sự cố này là một mục trong the Orca AI Incident Archive, nơi lưu giữ hồ sơ đầy đủ cùng các nguồn được trích dẫn, mức độ nghiêm trọng và đánh giá độ tin cậy.

Bản khuyến cáo thực sự nói gì

Bản ghi của Trung tâm Ứng phó Bảo mật Microsoft rất ngắn gọn, và gần như mọi chi tiết đã công bố về lỗ hổng này đều bắt nguồn từ đó hoặc từ các câu trả lời của Microsoft cho một số câu hỏi tiếp theo. Mô tả đầy đủ: “Server-side request forgery (ssrf) trong Azure MCP Server cho phép kẻ tấn công được cấp quyền nâng cao đặc quyền qua mạng.” Bản ghi CVE đã đặt trước mã định danh vào ngày 11 tháng 2 năm 2026 và công bố công khai vào ngày 10 tháng 3 lúc 14:00 UTC; ghi chú phát hành của Microsoft và mục của NVD đều ghi ngày đó. NVD đã phân tích bản ghi và công bố nó lúc 18:18 UTC cùng chiều hôm đó. Thông báo duy nhất từ cơ quan quản lý được tìm thấy cho bài viết này đến từ Maroc: đơn vị maCERT của DGSSI đã đưa CVE-2026-26118 vào một bản tin ngày 11 tháng 3 năm 2026, liệt kê Azure MCP Server Tools trong số các sản phẩm bị ảnh hưởng ở mức rủi ro Important của riêng mình, không có điểm số riêng và có liên kết trỏ về bản phát hành của Microsoft.

Điểm yếu được ánh xạ tới CWE-918, giả mạo yêu cầu phía máy chủ, và phân loại tác động là leo thang đặc quyền. Điểm cơ sở của Microsoft là 8.8 trên vectơ CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, với điểm tạm thời là 7.7 trên E:U/RL:O/RC:C — thành phần E:U nghĩa là Microsoft chưa biết mã khai thác nào khi điểm được đặt, và RL:O nghĩa là đã có bản vá chính thức. NVD có cùng điểm cơ sở và xếp nó vào mức High; thang ba bước của chính Microsoft gọi nó là Important.

Hai trường quan trọng ngang với điểm số. Hồ sơ của Microsoft ghi Đã bị khai thác: Không và Được công bố công khai: Không. Bản ghi quyết định SSVC của CISA trên mục NVD, có dấu thời gian ngày 5 tháng 3 năm 2026, đồng ý về việc khai thác — không có — trong khi đánh giá tác động kỹ thuật là toàn phần và khả năng tự động hóa là không. Mô hình FIRST EPSS đặt xác suất bị khai thác trong 30 ngày tới vào khoảng 1,0%, ở phân vị thứ 62,8, trong một lần kéo dữ liệu ngày 3 tháng 11 năm 2026. Đây là một lỗ hổng đã được phát hiện và khắc phục, không phải lỗ hổng được biết là đã bị sử dụng.

Cách một định danh tài nguyên trở thành yêu cầu gửi đi

Azure MCP Server là cách triển khai của Microsoft cho Model Context Protocol, giao diện mà các tác nhân AI sử dụng để gọi công cụ. Các công cụ của nó nhận các tham số do tác nhân cung cấp — tên tài khoản lưu trữ, mã định danh đăng ký, tên cơ sở dữ liệu — và chuyển chúng thành các lệnh gọi tới các mặt phẳng quản lý và dữ liệu của Azure. Tài liệu của Microsoft mô tả máy chủ này xác thực thông qua Entra ID bằng “thông tin đăng nhập người dùng Azure hoặc danh tính được quản lý của bạn”, với quyền truy cập được giới hạn bởi kiểm soát truy cập dựa trên vai trò của Azure.

Lỗ hổng nằm ở điểm mà tại đó một tham số đáng lẽ phải chỉ định tên một tài nguyên Azure lại được chấp nhận như một URL. Lời giải thích của chính Microsoft: kẻ tấn công “có thể khai thác vấn đề này bằng cách gửi đầu vào được tạo đặc biệt tới một công cụ Azure Model Context Protocol (MCP) Server có chấp nhận các tham số do người dùng cung cấp. Nếu kẻ tấn công có thể tương tác với tác nhân được hỗ trợ bởi MCP, họ có thể gửi một URL độc hại thay cho một định danh tài nguyên Azure thông thường.” Sau đó, máy chủ gửi yêu cầu đến nơi nó được bảo gửi, thay vì nơi công cụ dự định.

Phần biến một chuyện phiền toái thành leo thang đặc quyền chính là thứ đi kèm. Microsoft cho biết yêu cầu gửi ra “có thể bao gồm token danh tính được quản lý của nó”, điều này cho phép kẻ tấn công thu giữ token đó “mà không cần quyền truy cập quản trị.” Token danh tính được quản lý là một thông tin xác thực dạng bearer: bất kỳ ai giữ nó đều có thể xuất trình nó cho các dịch vụ Azure mà danh tính đó được cấp quyền, cho đến khi nó hết hạn. Nửa giảm thiểu của cùng đoạn văn cũng quan trọng không kém — kẻ tấn công có được “các quyền liên kết với danh tính được quản lý của MCP Server” và, theo lời Microsoft, “không có được các quyền cấp tenant hoặc quản trị viên rộng hơn; chỉ những quyền gắn với danh tính được quản lý bị xâm phạm.” Phạm vi ảnh hưởng là bất cứ thứ gì ai đó đã cấp cho danh tính đó, mà trên thực tế thường nhiều hơn mức một công cụ đơn lẻ cần.

Microsoft không nêu tên công cụ hoặc tham số bị ảnh hưởng, và không có nguồn nào được xem xét cho bài viết này nêu tên. Việc bỏ sót đó tự nó là một chi tiết: bản khuyến cáo mô tả một lớp công cụ — loại công cụ chấp nhận các tham số do người dùng cung cấp và có thể bị dụ để tải một URL — chứ không phải một điểm cuối đơn lẻ.

Bản sửa lỗi, và những gói đã mang nó

Đây không phải là bản cập nhật Windows. Azure MCP Server Tools được phát hành dưới dạng gói NuGet cho .NET, gói npm và gói Python trên PyPI, và bản sửa lỗi là việc tăng phiên bản trong gói mà một triển khai đang sử dụng. Thông báo của Microsoft liệt kê các phạm vi bị ảnh hưởng là 1.0.0 đến trước 1.0.2 (không bao gồm 1.0.2), và 2.0.0-beta.1 đến trước 2.0.0-beta.17 (không bao gồm 2.0.0-beta.17), trên các bản phân phối NuGet, npm và PyPI.

Dữ liệu ngày tháng trên registry npm cho thấy các bản dựng đã sửa lỗi đã có trên registry trước khi có khuyến cáo. Phiên bản 1.0.2 của @azure/mcp được phát hành vào ngày 6 tháng 3 năm 2026, bốn ngày trước khi CVE được công bố; 2.0.0-beta.17 được phát hành vào ngày 6 tháng 2 năm 2026, năm ngày trước khi Microsoft đăng ký mã định danh CVE và một tháng trước khi khuyến cáo xuất hiện. Dù trình tự bên trong Microsoft như thế nào, mã đã được vá không phải được viết để phản ứng với ngày công bố. NVD và cơ sở dữ liệu khuyến cáo của GitHub nhất trí về các giới hạn trên đó. Chúng khác nhau đôi chút ở cận dưới của phạm vi PyPI — NVD nói 2.0.0-beta.1, khuyến cáo của GitHub nói 2.0.0b14 — một sự khác biệt mà hai bản ghi đã mang theo kể từ khi công bố và chỉ ảnh hưởng đến việc một triển khai Python cần nhìn ngược lại bao xa.

Bản khuyến cáo itself? Wait need translate "The advisory itself" = Bản thân bản khuyến cáo đã được sửa đổi vào ngày 20 tháng 3 năm 2026, mười ngày sau khi công bố, kèm theo ghi chú rằng Microsoft đã “thêm các sản phẩm vào bảng Security Updates để ghi rõ các phương thức đóng gói khác nhau được dùng để phân phối Azure MCP Server Tools.” Nói cách khác, phiên bản đầu tiên của bản khuyến cáo có nêu tên sản phẩm nhưng không nêu mọi kênh mà sản phẩm được phân phối qua, điều này có ý nghĩa khi biện pháp khắc phục là “nâng cấp gói” thay vì “cài đặt KB này.”

Điều gì chưa được thiết lập

Ai đã phát hiện ra nó. Cả khuyến cáo của Microsoft lẫn hồ sơ CVE.org đều không nêu tên người báo cáo; trường ghi công trên CVE để trống. Đó không phải là bằng chứng rằng không ai được ghi công một cách riêng tư, mà chỉ cho thấy không có ghi công công khai nào.

Bất kỳ hành vi khai thác nào.Microsoft ghi nhận không có trường hợp nào, đánh giá SSVC của CISA đồng tình, và không có nguồn nào được xem xét cho bài viết này mô tả một danh tính bị xâm phạm trong thực tế. Trường tác hại thực tế của bản ghi là false, nhất quán với điều đó. EPSS thấp là một dự báo, không phải một phát hiện, và việc không có sự cố nào được báo cáo không phải là bằng chứng rằng không có sự cố nào đã xảy ra.

Liệu có tồn tại một mã khai thác công khai hay không. Đây là chỗ phạm vi bao phủ thứ cấp phân tách. Một bài đăng tháng 3 năm 2026 trên blog của Blueinfy nêu rằng có “các mã khai thác proof-of-concept công khai, chẳng hạn như những mã trên GitHub” và cảnh báo về “việc vũ khí hóa nhanh chóng”, nhưng không đưa ra liên kết, payload hay hướng dẫn từng bước nào, và không chứng minh được lỗ hổng. Hồ sơ của Microsoft cho biết lỗ hổng đã không được công bố công khai trước bản vá. Một tìm kiếm kho lưu trữ GitHub cho mã định danh CVE vào ngày 4 tháng 11 năm 2026 chỉ trả về một kho lưu trữ — một phòng thí nghiệm phát hiện Microsoft Sentinel được công bố ngày 17 tháng 3 năm 2026, không phải mã khai thác — và trang lỗ hổng của Mallory nêu rằng hai mã khai thác ứng viên đã được sàng lọc và bị loại. Tuyên bố về mã khai thác công khai có thể hoạt động, xét theo bằng chứng hiện có, là không có cơ sở; tuyên bố rằng chưa ai thử nghiệm cũng chưa được chứng minh tương tự.

Cách đóng khung. Một trang trên PolicyLayer, một trang web tóm tắt sự cố của nhà cung cấp, đã diễn giải lại CVE-2026-26118 thành một chuỗi thực thi mã từ xa không cần xác thực, kết thúc bằng việc chiếm toàn bộ tenant, ghi công một nhà nghiên cứu có tên và một buổi trình diễn tại RSAC 2026. Các nguồn được chính trang đó trích dẫn lại có tiêu đề là SSRF, ngày tháng của trang không khớp với dòng thời gian của CVE, và cả khuyến cáo của Microsoft lẫn bài đưa tin của SecurityWeek ngày 10 tháng 3 đều không mô tả việc thực thi mã. Bài viết này coi cách giải thích SSRF và token là cách đã được xác lập và không lặp lại cách đóng khung RCE.

Vì sao token, chứ không phải yêu cầu, mới là phát hiện

Giả mạo yêu cầu phía máy chủ là một trong những lớp lỗi lâu đời nhất trong phần mềm web, và tự thân nó thường là cách để chạm tới những hệ thống mà kẻ tấn công không thể truy cập trực tiếp. Điều khiến bản ghi này đáng được lưu giữ là thông tin xác thực gắn với yêu cầu. Máy chủ MCP vốn được thiết kế như một confused deputy: nó nắm giữ một danh tính để một tác nhân có thể hành động thay mặt người dùng, và mọi tham số mà tác nhân truyền vào, theo quan điểm của máy chủ, đều là văn bản chịu ảnh hưởng từ kẻ tấn công. Khi một trong những tham số đó trở thành đích đến thay vì một cái tên, deputy sẽ mang theo quyền uỷ quyền của chính nó tới đích đó.

Tài liệu của Microsoft làm rõ hơn nơi rủi ro đó tập trung. Tài liệu mô tả máy chủ cục bộ là “chỉ dành riêng cho mục đích sử dụng của nhà phát triển trong tổ chức của bạn”, trong khi đồng thời xuất bản hướng dẫn triển khai cho các máy chủ từ xa tự lưu trữ trong Microsoft Foundry và Copilot Studio — những cấu hình mà thông thường danh tính được quản lý, thay vì thông tin đăng nhập của chính nhà phát triển, là thông tin xác thực được sử dụng. Đường dẫn đánh cắp mã thông báo trong bản khuyến cáo đề cập cụ thể đến danh tính được quản lý. Bản khuyến cáo không nói rằng mọi bản cài đặt đều bị phơi nhiễm, và cũng không nói có bao nhiêu bản bị phơi nhiễm.

Bài học chung chính là bài học mà Tiêu chuẩn Xác minh An ninh AI của OWASP hiện dùng vụ việc này để truyền đạt. Chương điều phối của AISVS dẫn CVE-2026-26118 trong số các ví dụ thực hành của mình và rút ra kết luận rằng “các tham số công cụ MCP phải được coi là do kẻ tấn công kiểm soát, và các yêu cầu gửi ra từ máy chủ MCP phải đi qua đúng các chính sách lưu lượng ra và nguồn gốc mà bất kỳ I/O nào do tác nhân điều khiển khác cũng được kỳ vọng tuân theo.” Đó là một khuyến nghị về kiểm soát, không phải là một phát hiện về sự cố này, nhưng nó là câu trả lời cụ thể nhất mà bất kỳ ai đã công bố cho câu hỏi về việc cần thay đổi điều gì.

Điều gì đã thay đổi sau

Ba điều, và không điều nào trong số đó gây kịch tính. Microsoft đã phát hành các gói đã được sửa trong cả ba hệ sinh thái và cập nhật khuyến cáo để nêu tên chúng. Hệ sinh thái tình báo lỗ hổng đã tiếp nhận nó một cách lặng lẽ: điểm EPSS thấp, và một bản ghi NVD được sửa đổi lần cuối vào ngày 17 tháng 6 năm 2026. Và cộng đồng tiêu chuẩn đã áp dụng nó như một tình huống giảng dạy, một hình thức ứng phó chậm hơn và bền vững hơn so với một bản vá.

Đối với bất kỳ ai vẫn đang chạy bản dựng bị ảnh hưởng, cách khắc phục vẫn không thay đổi và chẳng có gì hào nhoáng: hãy chuyển sang 1.0.2 trở lên trên nhánh ổn định, hoặc 2.0.0-beta.17 trở lên trên nhánh xem trước, trong mọi trình quản lý gói mà bản triển khai có tác động tới. Ngoài ra, logic của chính bản khuyến cáo hàm ý ba biện pháp kiểm soát — hạn chế những gì máy chủ có thể kết nối ra ngoài, chỉ cấp cho danh tính được quản lý những vai trò mà các công cụ của nó thực sự cần, và coi mọi tham số công cụ có thể biến thành URL là đầu vào độc hại. Không biện pháp nào trong số đó là điều kiện bắt buộc để vượt qua CVE-2026-26118. Mỗi biện pháp sẽ làm giảm giá trị mà biện pháp tiếp theo mang lại cho kẻ tấn công.

Kho lưu trữ phân loại mục này như thế nào

Bản ghi được ghi nhận là một lỗ hổng — thứ được phát hiện, không phải thứ đã biết là bị khai thác — với mức độ tin cậy được xếp hạng A, nghĩa là được ghi chép đầy đủ với các nguồn sơ cấp đồng thuận, và không được đánh dấu là đang tranh chấp. Trường tác hại thực tế là false và mức độ liên quan đến AI được xác nhận, vì sản phẩm bị ảnh hưởng là cầu nối giữa một tác nhân AI và mặt phẳng điều khiển đám mây chứ không phải một dịch vụ đa dụng tình cờ nằm gần đó. Ngày được ghi nhận với độ chính xác đến ngày, 10 tháng 3 năm 2026, không có ngày kết thúc, vì đây là một thời điểm đơn lẻ chứ không phải một chiến dịch. Khu vực là toàn cầu và cờ mốc là false.

Một trường hiển thị khác với điểm số đã công bố. Mức độ nghiêm trọng của kho lưu trữ được ghi là trung bình, theo thang điểm riêng của nó; con số mà cả Microsoft và NVD công bố là 8.8, mà Microsoft gọi là Important và NVD xếp vào nhóm High. Phần tóm tắt của bản ghi mở đầu bằng con số 8.8 đó, và sự khác biệt là do cách phân nhóm chứ không phải do dữ kiện.

Điều mà hồ sơ không thể truyền đạt là có bao nhiêu phần của câu chuyện này là một sự vắng mặt. Có một lỗ hổng trao danh tính đám mây cho bất kỳ ai yêu cầu nó với hình dạng sai. Có một bản sửa lỗi, được phát hành trước thông báo. Không có người phát hiện nào được ghi nhận, không có công cụ nào được nêu tên, không có khai thác nào được xác nhận và không có cách nào để người ngoài biết liệu có bất kỳ triển khai được lưu trữ nào từng chạy bản dựng dễ bị tổn thương trong khi nắm giữ một danh tính mạnh hay không. Bản khuyến cáo nói chính xác về điều lỗ hổng làm và im lặng về gần như mọi thứ khác, và sự im lặng đó là điều hữu ích nhất để nhận ra về nó.