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

Nhà nghiên cứu bảo mật độc lập Syed Anas Mohiuddin đã tiết lộ trong cập nhật nghiên cứu tháng 10 năm 2026 rằng lỗi thực thi yêu cầu phía máy chủ (server-side request forgery) tương tự trong các máy chủ Model Context Protocol đã được xác nhận và khắc phục bởi các đội bảo mật của năm tổ chức không liên quan: Google, JPMorgan Chase, Weaviate, cơ quan 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, four months later”, kiểm chứng dự đoán mà Mohiuddin đã đưa ra vào tháng 5 năm 2026: nếu điểm yếu là mang tính cấu trúc chứ không chỉ là một triển khai sơ suất duy nhất, thì lỗi tương tự 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ã nguồn, ngành công nghiệp, quốc gia hoặc chủ sở hữu. Ông báo cáo rằng mỗi trong năm tổ chức đã xác nhận trường hợp của mình thông qua đội 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 tổng hợp năm tổ chức đã khắc phục cùng một SSRF, hai CVE đã được công bố, và năm phát hiện trên các máy chủ MCP liên bang Hoa Kỳ vẫn còn mở.

Mohiuddin mô tả hai chế độ thất bại đằng sau mẫu này. Đầu tiên là server-side request forgery: một máy chủ MCP tạo một yêu cầu outbound từ URL, đường dẫn hoặc endpoint do một tác nhân cung cấp mà không kiểm tra nơi nó được phân giải, vì vậy tác nhân thực tế quyết định máy chủ sẽ giao tiếp với mạng nào. Thứ hai là việc xử lý dữ liệu upstream không an toàn, đáng chú ý nhất là ghi toàn bộ phản hồi API upstream vào nhật ký trung tâm mà không thực hiện việc xóa thông tin nhạy cảm, và các lỗi thông thường đã đủ để kích hoạt vấn đề này. Ông truy nguyên cả hai về một giả định duy nhất, rằng dữ liệu vượt qua ranh giới MCP được tin cậy vì nó xuất phát từ bên trong hệ thống, điều mà ông cho rằng không còn đúng trong một pipeline có tính năng tác nhân.

CVE-2026-14540 trong MCP Toolbox của Google

Theo mục nhập Cơ sở dữ liệu Khuyến nghị GitHub cho CVE-2026-14540, được công bố bởi Cơ sở dữ liệu Lỗ hổng Quốc gia, 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. Vì client 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 ra có thể chuyển hướng các yêu cầu outbound của toolbox tới các điểm cuối nội bộ hoặc bên ngoài tùy ý. Khuyến nghị đánh giá lỗi này có mức độ nghiêm trọng cao với điểm CVSS là 8.0; nó được công bố vào ngày 31 tháng 7 năm 2026 và lần cập nhật cuối vào ngày 8 tháng 8 năm 2026. Mohiuddin cho biết CVE đã được đặt trước vào ngày 3 tháng 7 năm 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 googleapis/mcp-toolbox, vào ngày 18 tháng 6 năm 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 việc kiểm tra địa chỉ và kết nối, thêm các thuộc tính cấu hình cho phép mạng riêng tư (allowPrivateNetworks), dải IP được phép (allowedIpRanges) và dải IP bị chặn tùy chỉnh (customBlockedIpRanges), xác thực BaseURL đã cấu hình tại thời điểm khởi tạo thay vì khi yêu cầu đầu tiên, và cảnh báo rõ ràng về rủi ro người trung gian (man-in-the-middle) khi việc xác minh SSL bị tắt. Yêu cầu kéo 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 như một triển khai tham chiếu cho một SSRF guard thực tế.

Bốn trường hợp xác nhận khác

Mohiuddin báo cáo rằng kho 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, trong đó công cụ read_documentation áp dụng danh sách trắng miền trước khi lấy dữ liệu, trong khi công cụ related() đồng hành lại lấy 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 fork từ một dự án AWS mà bản gốc không bao giờ tham chiếu ngược lại URL của người gọi, đội chịu trách nhiệm Tiết lộ có trách nhiệm của ngân hàng đã xác nhận phát hiện này là hợp lệ, và một bản sửa đã được triển khai. Ông được liệt kê bằng tên trên trang công nhận Tiết lộ 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 ông, đã hợp nhất một yêu cầu kéo giới hạn các cài đặt apiEndpoint, region và location của mô-đun Google chỉ tới các máy chủ API của Google, và liệt kê tên ông trong mục Hall of Fame Bảo mật công khai của họ, ngày 25 tháng 8 năm 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 tháng 9 năm 2026, và yêu cầu kéo mở đầu bằng việc ghi nhận Mohiuddin là người báo cáo. Theo PR, một trường machinetài liệuurl do bất kỳ nhà sản xuất data.gouv.fr đã đăng ký cung cấp sẽ được lấy phía máy chủ và có thể trỏ tới địa chỉ loopback, mạng riêng tư hoặc siêu dữ liệu đám mây, với khả năng DNS rebinding có thể thay đổi mục tiêu giữa việc kiểm tra và kết nối và một chuyển hướng 302 có thể đưa đến máy chủ nội bộ. Bản sửa này 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 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ơ quan kỹ thuật số liên bộ của chính phủ.

Một GitHub Security Advisory được công bố vào ngày 3 tháng 9 năm 2026 bởi các nhà bảo trì INFOKOM-KI/Wazuh-MCP-Server, được xếp hạng Cao, ghi nhận rằng công cụ blueteamkiểm trawebshell tuyên bố có biện pháp bảo vệ SSRF chỉ từ chối địa chỉ IP nguyên văn và không bao giờ giải quyết tên máy chủ, do đó bất kỳ tên DNS nào trỏ tới địa chỉ riêng, loopback hoặc link‑local, bao gồm siêu dữ liệu phiên bản đám mây, đều có thể vượt qua. Bản báo cáo lưu ý rằng cam kết được tài liệu của công cụ, “SSRF Protection: Private/reserved IPs in the URL host are rejected,” không áp dụng cho các URL dựa trên tên máy chủ. Lỗi đã được sửa trong commit 2bbfe12, và bản báo cáo ghi công Mohiuddin là người báo cáo. Mohiuddin cho biết ông đã báo cáo vào ngày 2 tháng 9 năm 2026, các nhà bảo trì đã phản hồi từ địa chỉ tangerangkota.go.id, và dự án được duy trì bởi chính phủ Thành phố Tangerang ở Indonesia.

Rapid7’s mục nhập cơ sở dữ liệu lỗ hổng cho CVE-2026-97228 ghi lại một lỗ hổng tiêm truy vấn GraphQL trong Rapid7 Bulk Export MCP các phiên bản 0.2.5 đến 0.6.1, trong đó một đối số id của công cụ MCP được chèn trực tiếp vào truy vấn GraphQL. Rapid7 đánh giá mức độ 2.7, Thấp, trên thang CVSS 3.1, công bố bản ghi vào ngày 25 tháng 9 năm 2026, và ghi chú rằng các truy vấn đã chèn thực thi trong phạm vi API của người vận hành và không thể vượt qua ranh giới tenant; phiên bản 0.6.2 khắc phục vấn đề bằng cách truyền exportid dưới dạng biến tham số. Mohiuddin cho biết Rapid7 đã công nhận anh là người phát hiện.

Ngoài những trường hợp trên, Mohiuddin cho biết tính đến bản cập nhật, có 16 thông báo bảo mật GitHub do các nhà duy trì dự án tự công bố ghi công ông là người báo cáo, bao gồm SSRF cũng như tiêm lệnh, lỗ hổng xác thực, chiếm đoạt phiên, rò rỉ thông tin đăng nhập và việc vượt qua các bản sửa trước, và ông đã có các bản sửa được hợp nhất trong các dự án như github-mcp-server, mongodb-mcp-server và salesforce-mcp-server.

Những phát hiện của chính phủ chưa được giải quyết

Mohiuddin cho biết đã nộp năm phát hiện dưới dạng các Thông báo Bảo mật GitHub riêng tư vào ngày 2 tháng 9 năm 2026, liên quan đến các máy chủ MCP thuộc Dịch vụ Chuyển đổi Công nghệ của GSA: một máy chủ yêu cầu lợi ích của Bộ Cựu chiến binh, một máy chủ CMS Blue Button, một máy chủ regulations.gov, một máy chủ USASpending và một máy chủ CDC PLACES. Ông nói rằng cả năm đều vẫn ở giai đoạn triage, chưa được khắc phục và không được trình bày như các kết quả đã xác nhận.

Trong trường hợp VA, mà ông chỉ mô tả ở mức lớp, máy chủ ghi lại toàn bộ nội dung lỗi benefits‑API phía trên ở mức ERROR mà không thực hiện che giấu; các nội dung này có thể chứa tên của cựu chiến binh, số An sinh xã hội, ngày sinh và địa chỉ, và ông cho biết các lỗi xác thực thường xuyên đã đủ để kích hoạt việc ghi log trong hoạt động bình thường. Ông đang giữ lại chi tiết cấp mã cho đến khi các máy chủ được vá.

Ông cũng cho biết vào ngày 1 tháng 9 năm 2026, ông đã thông báo cho JPCERT rằng jgrants-mcp-server của Cơ quan Kỹ thuật số Nhật Bản không có xác thực, và vào ngày 7 tháng 9 năm 2026, ông đã mở một pull request công khai yêu cầu người dùng phải đồng ý rõ ràng để ràng buộc máy chủ với bất kỳ địa chỉ nào ngoài loopback và giới hạn kích thước ghi đính kèm. Pull request này chưa được hợp nhất, và ông không trình bày nó như một kết quả đã xác nhận.

Pivot Giao Thức và Bài Thuyết Trình MCPCon

Mohiuddin định nghĩa Pivot Giao Thức là một cuộc tấn công đa bước trong đó kẻ tấn công xâm nhập qua một giao thức, khai thác các giả định tin cậy mà các giao thức đặt lên nhau, và leo thang tới các khả năng chỉ có thể đạt được qua một giao thức khác. Ví dụ cụ thể của ông đặt văn bản dạng hướng dẫn nhiệm vụ A2A vào đầu ra của công cụ MCP; một tác nhân điều phối chuyển nó cho một tác nhân phụ như một ủy quyền bình thường, và tác nhân phụ, tin tưởng vào người điều phối, thực thi nó.

bản preprint chính thức, “Protocol Pivoting: Cross-Protocol Attack Escalation in Agentic AI Systems,” đã được công bố trên Zenodo vào ngày 24 tháng 5 năm 2026. Nó trình bày ba kịch bản: leo thang đặc quyền MCP‑to‑A2A thông qua ủy quyền tin cậy ngầm, tiêm khả năng A2A‑to‑MCP thông qua việc mạo danh tác nhân độc hại, và chuỗi tiêm lệnh qua giao thức. Nó cũng phân tích lý do các biện pháp phòng thủ hiện có không ngăn chặn lớp này và đề xuất một khung bảo mật đa giao thức thống nhất với mô hình ranh giới tin cậy chính thức và ba biện pháp giảm thiểu không phụ thuộc vào giao thức.

Công việc vào tháng Năm bắt đầu với playwright-mcp của Microsoft, trong đó công cụ browser_navigate chấp nhận bất kỳ URL nào mà tác nhân cung cấp mà không có biện pháp bảo vệ SSRF, cho phép một tác nhân được dẫn tới dịch vụ siêu dữ liệu phiên bản AWS tại 169.254.169.254 và các thông tin xác thực của nó. Mohiuddin lưu ý rằng ông đã đăng vấn đề này như một issue công khai trên GitHub, rằng không có CVE và không có xác nhận từ nhà cung cấp, và mức độ nghiêm trọng là đánh giá của riêng ông.

Mohiuddin lập luận rằng các công cụ phân tích thành phần phần mềm và máy quét phụ thuộc không phát hiện lớp này vì đầu vào nguy hiểm đến qua truyền tải dưới dạng một đối số công cụ được mô tả trong bản manifest công cụ mà máy quét không bao giờ đọc, do đó đồ thị gọi dừng lại ở ranh giới truyền tải. Ông cho biết đã xây dựng mcp-safeguard, một công cụ quét mã nguồn mở kiểm tra các máy chủ MCP thông qua bề mặt công cụ được phơi bày mà không cần mã nguồn, nhằm tìm sáu loại: SSRF, quyền quá mức, bề mặt tiêm lệnh, rò rỉ thông tin, lỗ hổng xác thực và vòng đời bị bỏ qua. Ông cũng cho biết các công cụ khớp mẫu, bao gồm cả công cụ của mình, bỏ sót một phần lớn của lớp này.

Mohiuddin cho biết ông sẽ trình bày mẫu đa nhà cung cấp vào ngày 23 tháng 10 năm 2026 tại MCPCon North America ở San Jose, bao gồm bất kỳ phát hiện nào đã được khắc phục đến thời điểm đó, và các phát hiện liên bang sẽ vẫn được giữ riêng tư cho đến khi chúng được vá.