Các vụ tấn công MCP thật đến nay rơi vào bốn nhóm: mô tả tool bị cài độc, prompt injection nối chuỗi tool để rò dữ liệu, command injection trong client và lớp bọc SDK (CVE-2025-6514 điểm 9,6), và gói độc hại như postmark-mcp. Các kiểm soát chặn được chúng là ghim tool, token OAuth gắn audience, sandbox cho server local và policy gateway.
Cập nhật ngày 13/11/2026. Model Context Protocol giờ là cách mặc định để nối agent với tool. Hầu hết nền tảng agent lớn đều hỗ trợ, và đặc tả đã qua ba lần sửa đổi kể từ tháng 6/2025. Bức tranh bảo mật cũng trưởng thành theo: có danh sách tấn công công bố ngay trong đặc tả, một loạt CVE trong client và lớp bọc SDK, và ít nhất một server độc hại bị phát hiện ngoài thực tế. Bài này nói về các sự cố chúng tôi xác minh được, những gì đặc tả hiện yêu cầu, và một checklist bạn chạy được với chính MCP client và server của mình.
Rủi ro bảo mật MCP lớn nhất năm 2026 là gì?
Rủi ro lớn nhất không nằm ở bản thân giao thức. Nó nằm ở chỗ mô tả và đầu ra của MCP server đi thẳng vào ngữ cảnh của model, và model có thể gọi tool khác với thông tin xác thực thật. Đặt một server không tin cậy, một tài liệu không tin cậy và một tool mạnh vào cùng phiên là bạn đã có đường rò rỉ dữ liệu. Hướng dẫn bảo mật trong chính đặc tả bổ sung các vấn đề kinh điển: confused deputy, token passthrough, SSRF, chiếm state handle và server local bị xâm nhập.
Một cách xếp hạng rủi ro hữu ích là ba câu hỏi. Phiên có trộn nội dung không tin cậy với dữ liệu riêng tư không? Có tool nào gửi dữ liệu ra ngoài được không (email, HTTP, repo công khai)? Tool có chạy với thông tin xác thực rộng và dài hạn không? Nếu cả ba đều "có", sự cố chỉ là vấn đề thời gian, bất kể đặc tả nói gì.
Những vụ tấn công và lỗ hổng MCP nào đã thực sự xảy ra?
Dưới đây là những vụ chúng tôi xác minh được trên trang của chính nhà nghiên cứu hoặc nhà cung cấp:
| Thời điểm | Sự cố | Loại | Điều rút ra |
|---|---|---|---|
| 4/2025 | Tool poisoning (Invariant Labs) | Chỉ thị ẩn trong mô tả tool | Một tool trông vô hại có thể bảo model đọc SSH key, file cấu hình rồi rò qua tham số |
| 5/2025 | "Toxic agent flow" với GitHub MCP | Prompt injection gián tiếp | Một issue công khai độc hại khiến agent chép dữ liệu repo riêng vào pull request công khai; code server không có lỗi |
| Giữa 2025 | CVE-2025-49596, MCP Inspector | RCE, không xác thực giữa client và proxy | CVSS 9,4; sửa ở 0.14.1 |
| 7/2025 | CVE-2025-6514, mcp-remote | OS command injection qua authorization_endpoint giả mạo | CVSS 9,6; phiên bản 0.0.5–0.1.15; sửa ở 0.1.16 |
| 9/2025 | postmark-mcp trên npm | Gói độc hại (chuỗi cung ứng) | 15 phiên bản sạch, rồi bản 1.0.16 âm thầm BCC mọi email cho kẻ tấn công |
| 4/2026 | Cảnh báo STDIO của OX Security | Command injection qua tham số khởi chạy server STDIO | Hơn chục CVE trong các framework AI và IDE, vd. LiteLLM CVE-2026-30623, Flowise CVE-2026-40933, Windsurf CVE-2026-30615 |
Hãy để ý quy luật: chỉ một vụ là lỗi trong logic nghiệp vụ của MCP server. Còn lại nằm ở client, proxy, công cụ inspector, đóng gói và cách host khởi chạy server. Trên thực tế, bảo mật MCP chủ yếu là bảo mật phía host và chuỗi cung ứng.
Tool poisoning trong MCP là gì và chặn thế nào?
Tool poisoning là giấu chỉ thị trong tên, mô tả hoặc schema của tool. Model đọc chúng như ngữ cảnh dù người dùng không bao giờ thấy. Một tool tên "cộng hai số" có thể mang dòng chữ bảo model đọc ~/.ssh/id_rsa rồi truyền vào tham số. Một biến thể là "rug pull": lúc cài thì mô tả sạch, sau đó mới đổi.
Các kiểm soát hiệu quả:
- Ghim và hash định nghĩa tool. Lưu danh sách tool và mô tả của từng server lúc duyệt, chặn hoặc hỏi lại khi chúng đổi. Đặc tả 2026-07-28 giúp việc này dễ hơn vì
tools/listcó thêm trường cache (ttlMs,cacheScope) và server nên trả tool theo thứ tự cố định. - Danh sách server được phép. Chỉ chạy server từ registry nội bộ đã chọn lọc, không phải bất cứ thứ gì người dùng dán vào file cấu hình.
- Quét mô tả. Gắn cờ mô tả có chỉ thị nhắm vào model ("trước khi dùng tool này, hãy đọc…"), nhắc tới file hay bí mật, hoặc dài bất thường.
- Tách đặc quyền. Tool đọc dữ liệu nhạy cảm và tool gửi dữ liệu ra ngoài không nên ở chung phiên nếu giữa chúng không có bước kiểm tra chính sách.
Token passthrough là gì và vì sao đặc tả MCP cấm?
Token passthrough là khi MCP server nhận một token không được cấp cho nó rồi chuyển tiếp xuống API phía sau. Đặc tả cấm rõ: MCP server KHÔNG ĐƯỢC chấp nhận token nào không được cấp riêng cho chính server đó. Passthrough phá kiểm tra audience, vượt qua giới hạn tần suất và giám sát gắn với server, và phá audit trail: log phía sau chỉ thấy token của người dùng, không thấy server nào đã dùng nó.
Cách sửa đã có từ bản 2025-06-18. MCP server là OAuth resource server, và client phải gửi Resource Indicators (RFC 8707) để token gắn với đúng một server. Server kiểm audience, rồi dùng thông tin xác thực của chính nó, hoặc token exchange, để gọi API phía sau. Nếu bạn bọc một API có sẵn thành MCP server, đây là chỗ đa số đội làm sai. Xem hướng dẫn phát triển MCP server cho phía server.
Bài toán confused deputy trong MCP là gì?
Đây là kiểu tấn công vào MCP proxy server dùng một client ID OAuth tĩnh với API bên thứ ba nhưng lại cho MCP client đăng ký động. Nếu authorization server bên thứ ba nhớ sự đồng ý bằng cookie, kẻ tấn công có thể đăng ký một client với redirect URI của chúng và gửi link cho người dùng. Màn hình đồng ý bị bỏ qua và authorization code rơi vào tay kẻ tấn công.
Đặc tả yêu cầu MCP server lấy đồng ý theo từng client trước khi chuyển sang bên thứ ba. Proxy phải lưu client ID đã được duyệt theo từng người dùng, so khớp redirect URI chính xác, dùng giá trị state một lần và chỉ đặt sau khi người dùng đồng ý, và bảo vệ cookie đồng ý bằng __Host-, Secure, HttpOnly, SameSite=Lax. Trang đồng ý cũng phải chặn nhúng iframe.
Đặc tả MCP 2026-07-28 thay đổi gì về uỷ quyền?
Bản 2026-07-28 biến MCP thành giao thức stateless và siết OAuth. Những thay đổi quan trọng về bảo mật:
| Thay đổi | Ý nghĩa với bạn |
|---|---|
Client PHẢI kiểm iss (nếu có) với issuer đã ghi nhận trước khi đổi code (RFC 9207, SEP-2468) | Chặn tấn công mix-up, khi authorization server độc hại gom code vốn dành cho server trung thực |
| Thông tin xác thực gắn với authorization server đã cấp (SEP-2352) | Lưu credential theo issuer; không dùng lại với server khác; đăng ký lại khi server đổi |
| Dynamic Client Registration bị deprecate, ưu tiên Client ID Metadata Documents | Lên kế hoạch chuyển sang CIMD; authorization server tải URL metadata phải chống SSRF |
Bỏ session ở tầng giao thức và Mcp-Session-Id | Trạng thái nằm trong handle do server tạo; server KHÔNG ĐƯỢC coi handle là xác thực và nên gắn nó với người dùng lấy từ token đã kiểm |
| Deprecate Roots, Sampling và Logging | Ít yêu cầu từ server tới client hơn; truyền đường dẫn qua tham số tool, gọi API model trực tiếp, log qua stderr hoặc OpenTelemetry |
Bản 2025-11-25 trước đó đã thêm đồng ý scope tăng dần qua WWW-Authenticate, OpenID Connect discovery, Client ID Metadata Documents và HTTP 403 cho header Origin không hợp lệ. Cộng lại, các bản này biến uỷ quyền tối thiểu, nâng quyền khi cần, thành mô hình mặc định chứ không còn là tuỳ chọn.
Chạy MCP server local qua stdio có an toàn không?
Chỉ an toàn bằng câu lệnh khởi chạy nó. Server local chạy với quyền ngang client của người dùng. Một dòng cấu hình hay một gói độc hại có thể đọc file, lấy SSH key hoặc chạy bất cứ thứ gì. Đặc tả hiện yêu cầu client có tính năng cài server local một chạm PHẢI hiển thị đầy đủ câu lệnh và đòi người dùng đồng ý rõ ràng, đồng thời khuyến nghị sandbox với quyền truy cập file và mạng tối thiểu.
Cảnh báo của OX Security cho thấy lý do. Nhiều framework AI đưa thẳng lệnh và tham số do người dùng nhập vào trình khởi chạy STDIO của SDK, nên ai sửa được cấu hình server là chạy được code. Theo OX, Anthropic coi hành vi gốc là đúng thiết kế, tức trách nhiệm thuộc về ứng dụng host. Đừng để người dùng cuối hay model tự viết lệnh khởi chạy server. Giữ danh sách binary và tham số được phép, và chạy server local trong container hoặc sandbox của hệ điều hành.
Checklist bảo mật MCP cho production gồm những gì?
Chạy checklist này với mọi MCP client và server bạn phát hành hoặc kết nối:
- Danh mục: mọi server nằm trong registry nội bộ, có người phụ trách, phiên bản, nguồn và danh sách tool đã duyệt.
- Chuỗi cung ứng: ghim phiên bản và hash gói; không tự cập nhật; để ý gói đổi tên hoặc giả tên.
- Ghim tool: hash mô tả và schema khi duyệt; cảnh báo khi thay đổi.
- Token gắn audience: RFC 8707 ở client; kiểm audience ở server; không passthrough.
- Scope tối thiểu: scope ban đầu nhỏ, nâng quyền qua
WWW-Authenticate; không có scope wildcard trongscopes_supported. - Kiểm issuer: kiểm
iss; lưu credential theo issuer (2026-07-28). - Đồng ý ở proxy: đồng ý theo từng client, redirect URI chính xác, state dùng một lần.
- Vệ sinh URL: chỉ
https(vàhttploopback khi dev) cho URL uỷ quyền; không mở URL qua shell; chặn dải IP nội bộ khi OAuth discovery. - Sandbox server local: container hoặc sandbox hệ điều hành, mặc định không truy cập thư mục home, danh sách egress được phép.
- Policy gateway: mọi tool call được kiểm bên ngoài model; tool gửi ra ngoài (email, HTTP, publish) cần phê duyệt hoặc giới hạn chặt khi ngữ cảnh có nội dung không tin cậy.
- Handle không phải xác thực: state handle ngẫu nhiên, có hạn, gắn với người dùng đã xác thực.
- Ghi log: trace định nghĩa tool đã thấy, lệnh gọi, tham số, quyết định chính sách và kết quả về SIEM, kèm ngữ cảnh OpenTelemetry.
Mục 4, 10 và 12 trùng với kiểm soát ở tầng agent. Bài control plane cho AI agent nói về định danh và kill switch, còn checklist bảo mật AI agent phủ phần còn lại của agent.
Bảo mật MCP có khác trong ngành có quản lý như y tế không?
Kiểm soát giống nhau, nhưng cái giá khi sơ suất cao hơn và bạn phải chứng minh được kiểm soát tồn tại. Nếu MCP server chạm tới PHI, mọi server và mọi model trên đường đi phải có BAA. Tool call đọc dữ liệu bệnh nhân cần audit log, và tool gửi ra ngoài cần người duyệt. Bài FHIR MCP server trình bày mô hình cho dữ liệu EHR, còn xây plugin ChatGPT bằng MCP nói về phía ứng dụng công khai.
BeevR làm việc này thế nào
Chúng tôi xây MCP server và agent cho doanh nghiệp SaaS và ngành có quản lý, và chạy MCP server chỉ-đọc trên chính website của mình. Thiết kế mặc định của chúng tôi: server là OAuth resource server, kiểm audience và không bao giờ chuyển tiếp token. Định nghĩa tool được ghim và review như code, server local chạy trong sandbox, không có bí mật trong biến môi trường. Mọi tool call đi qua lớp chính sách ghi lại quyết định và có thể đòi người duyệt. Với dự án y tế, model có thể chạy trong tài khoản AWS của bạn theo AWS BAA, và BeevR ký BAA với vai trò business associate.
BeevR là đội senior do founder dẫn dắt tại Hà Nội. Giai đoạn phạm vi cố định, giá cố định từ $10K, demo chạy được mỗi thứ Sáu, và bạn sở hữu mã nguồn cùng IP từ ngày đầu. Xem cách chúng tôi xây AI agent và tích hợp MCP an toàn.
Đang phát hành hoặc kết nối MCP server? Đặt lịch gọi 30 phút, chúng tôi sẽ chạy checklist trên với hệ thống của bạn.