Nhà nghiên cứu tiết lộ lỗ hổng MCP tương tự tại Google, JPMorgan và hai chính phủ.

An ninh mạng Nhà nghiên cứu tiết lộ cùng một lỗ hổng MCP tại Google, JPMorgan và hai chính phủ Đăng ngày 5/10/2026 Bởi Miles Okada, Chuyên viên nghiên cứu AI & An ninh mạng AI Thêm Unite.AI vào các nguồn tin ưa thích của bạn trên Google Nhà nghiên cứu bảo mật độc lập Syed Anas Mohiuddin đã tiết lộ trong bản cập nhật nghiên cứu tháng 10/2026 rằng cùng một lỗi giả mạo yêu cầu phía máy chủ (SSRF) trong các máy chủ Giao thức Ngữ cảnh Mô hình (Model Context Protocol - MCP) đã được xác nhận và khắc phục bởi các nhóm bảo mật tại năm tổ chức không liên quan: Google, JPMorgan Chase, Weaviate, Tổng cục Kỹ thuật số liên bộ của Pháp và chính quyền thành phố Tangerang ở Indonesia. Bản cập nhật, có tiêu đề “Protocol Pivoting, bốn tháng sau”, kiểm tra một dự đoán mà Mohiuddin đã đưa ra vào tháng 5/2026: nếu điểm yếu mang tính cấu trúc chứ không phải là một lỗi triển khai bất cẩn đơn lẻ, thì cùng một lỗi sẽ xuất hiện trong các máy chủ được viết bởi các nhóm không chia sẻ mã, ngành, quốc gia hoặc chủ sở hữu. Ông báo cáo rằng mỗi trong số năm tổ chức đã xác nhận trường hợp của mình thông qua nhóm bảo mật riêng, và nhà cung cấp bảo mật Rapid7 đã riêng biệt công bố một CVE cho một lỗi khác nhưng có liên quan. Bản cập nhật liệt kê năm tổ chức đã khắc phục cùng một lỗi SSRF, hai CVE đã được công bố và năm phát hiện trong các máy chủ MCP liên bang Hoa Kỳ vẫn đang chờ xử lý. Mohiuddin mô tả hai chế độ lỗi đằng sau mô hình này. Đầu tiên là giả mạo yêu cầu phía máy chủ: một máy chủ MCP xây dựng một yêu cầu gửi đi từ một URL, đường dẫn hoặc điểm cuối được cung cấp bởi một tác nhân mà không kiểm tra nơi nó phân giải, do đó tác nhân có thể quyết định hiệu quả những gì danh tính mạng của máy chủ sẽ giao tiếp. Thứ hai là xử lý dữ liệu đầu vào không an toàn, rõ ràng nhất là ghi toàn bộ phản hồi API đầu vào vào các nhật ký tập trung mà không che giấu, điều mà các lỗi thông thường cũng đủ để kích hoạt. Ông truy nguyên cả hai lỗi này từ một giả định, rằng dữ liệu đi qua ranh giới MCP được tin cậy vì nó đến từ bên trong hệ thống, điều mà ông lập luận là không đúng trong một quy trình tác nhân. CVE-2026-14540 trong MCP Toolbox của Google Theo mục nhập Cơ sở dữ liệu Tư vấn GitHub cho CVE-2026-14540, được công bố bởi Cơ sở dữ liệu Lỗ hổng Quốc gia (National Vulnerability Database), một lỗ hổng SSRF tồn tại trong các thành phần nguồn HTTP chung và công cụ của Google mcp-toolbox phiên bản 0.3.0 đến 1.4.0. Do máy khách HTTP không có chính sách chuyển hướng hạn chế và không bao giờ xác thực địa chỉ IP đích, một tham số đường dẫn được tạo thủ công có thể chuyển hướng các yêu cầu gửi đi của toolbox đến các điểm cuối nội bộ hoặc bên ngoài tùy ý. Bản tư vấn đánh giá mức độ nghiêm trọng của lỗ hổng là Cao với điểm CVSS là 8.0; nó được công bố vào ngày 31/7/2026 và cập nhật lần cuối vào ngày 8/8/2026. Mohiuddin cho biết CVE đã được đặt trước vào ngày 3/7/2026 và hồ sơ ghi nhận ông là người phát hiện. Google đã hợp nhất bản sửa lỗi, yêu cầu kéo #3448 trong kho lưu trữ googleapis/mcp-toolbox, vào ngày 18/6/2026, và nó đã được phát hành trong mcp-toolbox v1.5.0. Yêu cầu kéo này triển khai một SSRFGuard để ngăn chặn các cuộc tấn công DNS-rebinding trong khoảng thời gian giữa kiểm tra địa chỉ và kết nối, thêm các thuộc tính có thể cấu hình allowPrivateNetworks, allowedIpRanges và customBlockedIpRanges, xác thực BaseURL đã cấu hình khi khởi tạo thay vì theo yêu cầu đầu tiên, và cảnh báo rõ ràng về rủi ro tấn công trung gian (man-in-the-middle) khi xác minh SSL bị vô hiệu hóa. PR ghi nhận Mohiuddin là người báo cáo, và Mohiuddin mô tả biện pháp khắc phục của Google là một triển khai tham chiếu của một SSRF guard thực sự. Bốn trường hợp được xác nhận khác Mohiuddin báo cáo rằng kho lưu trữ mã nguồn mở jpmorgan-payments/ai của JPMorgan Chase bao gồm một máy chủ MCP tìm kiếm tài liệu mà công cụ read_documentation của nó áp dụng một danh sách cho phép tên miền trước khi tìm nạp, trong khi công cụ liên quan (related()) của nó tìm nạp một URL do người gọi cung cấp phía máy chủ mà không có bất kỳ hạn chế nào. Ông cho biết thành phần này được phân nhánh từ một dự án AWS mà bản gốc chưa bao giờ hủy tham chiếu. địa chỉ URL của người gọi, và nhóm Phụ trách Công bố của ngân hàng đã xác nhận phát hiện này là hợp lệ, đồng thời một bản vá đã được triển khai. Ông được nêu tên trên trang công nhận công bố có trách nhiệm công khai của JPMorgan Chase và đánh giá mức độ nghiêm trọng của phát hiện là trung bình, lưu ý rằng không có thông tin xác thực nào đi kèm với yêu cầu giả mạo. Weaviate, theo báo cáo của ông, đã hợp nhất một yêu cầu kéo (pull request) nhằm hạn chế các cài đặt apiEndpoint, region và location của mô-đun Google chỉ dành cho các máy chủ API của Google, và liệt kê tên ông trong mục Vinh danh An ninh công khai (Security Hall of Fame) của mình, có ngày 25/8/2026. Dự án datagouv/datagouv-mcp đã hợp nhất yêu cầu kéo #126, “feat: harden SSRF on external APIs”, vào ngày 4/9/2026, và yêu cầu kéo này mở đầu bằng việc ghi nhận Mohiuddin là người báo cáo. Theo yêu cầu kéo, một trường machinedocumentationurl được cung cấp bởi bất kỳ nhà sản xuất đã đăng ký nào của data.gouv.fr đã được tìm nạp phía máy chủ và có thể trỏ đến các địa chỉ loopback, mạng riêng hoặc siêu dữ liệu đám mây, với việc tái liên kết DNS (DNS rebinding) có thể hoán đổi mục tiêu giữa kiểm tra và kết nối, và một chuyển hướng 302 có thể dẫn đến một máy chủ nội bộ. Bản sửa lỗi xác thực IP đích tại thời điểm kết nối, kiểm tra lại mọi bước chuyển hướng và từ chối các proxy. Mohiuddin xác định dự án này là máy chủ MCP chính thức cho nền tảng dữ liệu mở quốc gia của Pháp, được duy trì bởi DINUM, cục kỹ thuật số liên bộ của chính phủ. Một Cảnh báo An ninh GitHub (GitHub Security Advisory) được công bố vào ngày 3/9/2026 bởi những người duy trì INFOKOM-KI/Wazuh-MCP-Server, được xếp hạng Cao, ghi nhận rằng tính năng bảo vệ SSRF được quảng cáo của công cụ blueteamcheckwebshell chỉ từ chối các địa chỉ IP cố định và không bao giờ phân giải tên máy chủ, do đó bất kỳ tên DNS nào trỏ đến một địa chỉ riêng tư, loopback hoặc liên kết cục bộ, bao gồm siêu dữ liệu phiên bản đám mây, đều có thể vượt qua. Cảnh báo lưu ý rằng đảm bảo được ghi trong tài liệu của công cụ, “Bảo vệ SSRF: Các IP riêng tư/dành riêng trong máy chủ URL bị từ chối,” đã không đúng đối với các URL dựa trên tên máy chủ. Lỗ hổng đã được vá trong commit 2bbfe12, và cảnh báo ghi nhận Mohiuddin là người báo cáo. Mohiuddin cho biết ông đã báo cáo vào ngày 2/9/2026, rằng những người duy trì đã phản hồi từ một địa chỉ tangerangkota.go.id, và dự án được duy trì bởi chính quyền thành phố Tangerang ở Indonesia. Mục cơ sở dữ liệu lỗ hổng của Rapid7 cho CVE-2026-9722