AIDiveStack agent của bạn có một mắt xích yếu
Một máy chủ MCP độc hại có thể đánh cắp khóa SSH của bạn mà không cần viết ra một lệnh độc hại hoàn chỉnh nào. Nhóm nghiên cứu ASSET đã chứng minh điều đó: khi lệnh đánh cắp được đưa cho mô hình trong một khối, các mô hình lớn hầu như đều từ chối. Nhưng chia cùng lệnh đó thành các mảnh trông vô hại, thì GPT-4o, Gemini 2.0 Flash và Llama 3.3 tuân theo trong 100% các trường hợp thử nghiệm.
Trong khi đó, hầu hết các nhà phát triển thêm một máy chủ MCP mới cho agent của mình mỗi tuần, sao chép một dòng config tìm thấy trên GitHub. Mỗi máy chủ đó nắm giữ một phần quyền truy cập của bạn: token API, khóa cloud, tài khoản dịch vụ. MCP hữu ích — không ai phủ nhận điều đó. Nhưng máy chủ MCP đã trở thành mắt xích yếu nhất trong toàn bộ stack agent.
Bài viết này nói về cách một máy chủ MCP làm rò rỉ bí mật của bạn mà không bị phát hiện, cuộc tấn công GhostSplice vượt qua sự từ chối của mô hình bằng cách chia nhỏ lệnh, và các biện pháp phòng thủ cụ thể, từ Cloudflare WriteGuard đến những quy tắc bạn có thể áp dụng cho setup của mình ngay hôm nay.
Máy chủ MCP thực sự nắm giữ những gì
Một máy chủ MCP là cầu nối giữa agent của bạn và một công cụ bên ngoài: database, GitHub, Slack, cloud của bạn. Để làm công việc cầu nối đó, nó lưu trữ mọi thứ cần thiết để đăng nhập thay bạn — token, khóa API, thông tin đăng nhập tài khoản dịch vụ — ở dạng văn bản thô, trong một file config trên ổ đĩa của bạn, thường không hề mã hóa.
Một chi tiết giao thức quan trọng cho phần sau. Khi agent kết nối với máy chủ MCP, máy chủ gửi lại danh sách công cụ của nó, mỗi công cụ kèm một mô tả dạng văn bản tự do nói cho mô hình biết khi nào và cách nào để dùng nó. Các mô tả đó đi thẳng vào context của mô hình, với trọng lượng ngang bằng chỉ dẫn của chính bạn, và kết quả mà các công cụ trả về cũng đi vào đó. Một máy chủ MCP nói chuyện với agent của bạn liên tục, bằng văn bản không ai từng đọc lại. Đó chính xác là thứ khiến cuộc tấn công GhostSplice trở nên khả thi.
Hệ sinh thái cũng bùng nổ nhanh hơn hẳn các rào chắn của nó:
| Tín hiệu | Con số |
|---|---|
| Máy chủ trong đăng ký MCP chính thức | 9.600+ |
| Tăng trưởng triển khai máy chủ từ xa từ tháng 5/2025 | 5× |
Ai cũng có thể công bố một máy chủ, không có kiểm duyệt trung tâm, và agent của bạn tin từng cái y như một công cụ chính thức. NSA đã công bố một hướng dẫn bảo mật riêng cho MCP vào tháng 5, nói rằng việc áp dụng giao thức đã vượt xa tốc độ xây dựng các biện pháp bảo vệ. Khi một cơ quan tình báo viết hướng dẫn về công cụ dev bạn yêu thích, hiếm khi đó là để khen ngợi bạn.
Đó là bối cảnh: hàng nghìn máy chủ, không kiểm duyệt, và khóa của bạn nằm ở giữa.
Bí mật rò rỉ từ đâu
Lỗ hổng đầu tiên là thông tin xác thực được lưu dưới dạng văn bản thô. The Hacker News đã công bố một phân tích chi tiết về cơ chế rò rỉ vào ngày 17 tháng 8, và điểm khởi đầu rất thẳng thắn: token bị dán thẳng vào các chuỗi cấu hình và vẫn đọc được trên ổ đĩa. Chỉ một commit hơi vội cũng đủ để đẩy config của bạn lên một repo Git với khóa nằm bên trong. Mọi thứ tệ hơn với thứ mà bài viết gọi là sprawl: cùng một khóa bị lặp lại trên nhiều file config, biến môi trường, và các bản sao ở dev, staging, production. Sau một thời gian không ai còn biết bí mật nằm ở đâu, nên không ai xoay vòng chúng — và một khóa tĩnh không bao giờ đổi là một khóa đang chờ kẻ tấn công.
Lỗ hổng thứ hai là cấp quyền quá mức. Trong lúc phát triển bạn cấp cho máy chủ quyền rộng để tránh lỗi phân quyền, và những quyền rộng đó đi thẳng lên production mà không thay đổi. Một lần bị xâm phạm duy nhất sau đó phơi bày nhiều hơn hẳn mức sử dụng thực tế từng cần đến.
Lỗ hổng thứ ba là chuỗi cung ứng. CVE-2025-6514 đã tấn công mcp-remote, một proxy OAuth được tải xuống hơn 400.000 lần, và cho phép một máy chủ độc hại kích hoạt command injection trên máy của người dùng — chạy code và mang theo thông tin xác thực. Một gói npm phổ biến, chỉ cài trong một dòng, và cánh cửa đã mở.
Lỗ hổng thứ tư là tinh vi nhất: prompt injection. Một agent đọc mọi thứ mà công cụ của nó mang về — một trang web, một ticket, một tài liệu nội bộ. Nếu một trong số đó chứa một lệnh ẩn giấu, agent có thể làm theo như thể lệnh đó đến từ bạn, và dùng chính các công cụ hợp lệ của nó để lộ ra thứ đáng lẽ nó phải bảo vệ. Rò rỉ đó không đi qua một lỗ hổng kỹ thuật nào; nó đi qua sự cả tin của mô hình.
Trước bất kỳ cuộc tấn công tinh vi nào, cuộc sống bình thường của một máy chủ MCP — config văn bản thô, quyền quá lớn, phụ thuộc chưa kiểm tra, nội dung chưa lọc — đã phơi bày bí mật của bạn.
GhostSplice: cuộc tấn công đi từng mảnh
GhostSplice là tên mà nhóm nghiên cứu ASSET đặt cho một kỹ thuật khiến chính agent của bạn thực hiện việc đánh cắp dữ liệu, với sự hợp tác đầy đủ của nó. Nguyên lý gói gọn trong một câu: thay vì viết lệnh đánh cắp đầy đủ, máy chủ độc hại chia nó thành nhiều mảnh, đặt một mảnh vào mô tả của một công cụ, và mảnh kia vào kết quả mà công cụ đó trả về. Mỗi mảnh, đọc riêng lẻ, đều trông vô hại. Nhưng agent kết hợp mọi thứ đi vào context làm việc của nó: nó dựng lại lệnh đầy đủ và thực thi nó với thiện chí hoàn toàn — theo góc nhìn của nó, đó chỉ là điền vào form mà công cụ yêu cầu.
Các con số thử nghiệm mới là câu chuyện thật:
| Mô hình | Lệnh trong một khối | Lệnh bị chia mảnh |
|---|---|---|
| GPT-4o | Từ chối 100% | Tuân theo 100% |
| Gemini 2.0 Flash | Từ chối 100% | Tuân theo 100% |
| Llama 3.3 | Từ chối 100% | Tuân theo 100% |
| Claude Haiku 4.5 | Từ chối qua API | Tuân theo 100% trong thử nghiệm ba mảnh bên trong Cursor |
Chi tiết về Claude phá vỡ mọi kết luận dễ dàng: cùng một mô hình có thể từ chối ở client này và đánh cắp dữ liệu ở client khác, tùy vào các biện pháp bảo vệ mà client đó thêm vào hay không.
Những gì GhostSplice đánh cắp trong các thử nghiệm: khóa SSH, bí mật môi trường, mã nguồn, dữ liệu khách hàng. Các nhà nghiên cứu làm việc trên các dự án cô lập với khóa giả, không phải trên nạn nhân thật, nhưng phương pháp này đã được công bố và có thể tái tạo lại.
GhostSplice không phải là lần thử đầu tiên. Cùng phòng lab đó đã công bố Ghostcommit vào tháng 6, một cuộc tấn công giấu lệnh của nó trong các file PNG được quy ước dự án tham chiếu đến, rồi mã hóa các bí mật đánh cắp được thành số nguyên trong mã nguồn. Chia nhỏ lệnh là một họ tấn công đang định hình, không phải một hiện tượng đơn lẻ.
Hai điều để giữ mọi thứ trong tầm nhìn đúng đắn. Cuộc tấn công có hai điều kiện tiên quyết: máy chủ độc hại đã được kết nối vào agent của bạn, và agent có quyền đọc các file mục tiêu. Đó chính xác là lý do vì sao nguồn gốc lại quan trọng đến vậy — máy chủ của bạn đến từ đâu là tuyến phòng thủ đầu tiên của bạn. Và hãy nhớ cơ chế này: sự căn chỉnh của mô hình không bảo vệ bạn, vì cuộc tấn công không bao giờ yêu cầu bất cứ điều gì bị cấm trong một mảnh duy nhất.
Shadow MCP: những máy chủ không ai duyệt
GhostSplice giả định rằng một máy chủ độc hại đã được kết nối sẵn. Nhưng ai quyết định cái gì được kết nối vào? Trong một nhóm, câu trả lời thật là không ai cả. Đó là vấn đề mà Cloudflare gọi là shadow MCP: tất cả những máy chủ mà các nhà phát triển kết nối vào agent của họ mà không qua bất kỳ kiểm tra bảo mật nào. Cho đến gần đây, lưu lượng đó vẫn vô hình — một request MCP trông giống hệt bất kỳ cuộc gọi HTTPS nào khác.
Cloudflare đã thay đổi điều đó bằng công nghệ phát hiện ở tầng giao thức. Kể từ khi cập nhật spec, mọi MCP client tuân thủ đều gửi một header MCP-Protocol-Version trên các request của nó, và Gateway kiểm tra header đó trên toàn bộ lưu lượng TLS mà nó giải mã. Một đội bảo mật giờ đây có thể thấy mọi máy chủ MCP được dùng trong công ty, với một dashboard riêng: số máy chủ duy nhất, người dùng, khối lượng request. Cách tiếp cận dựa trên header này vượt trội hơn việc lọc theo tên miền, vì một máy chủ MCP không có lý do gì phải tự gọi mình là mcp-gì đó — giao thức bị phát hiện bởi những gì nó nói, không phải bởi những gì nó tự nhận là.
Đội cũng có thể hành động: một bộ chọn is_mcp cho phép bạn chặn bất kỳ lưu lượng MCP nào không đi qua một portal đã duyệt. Portal là nửa còn lại của thiết lập — một điểm truy cập duy nhất gom các máy chủ đã kiểm định đằng sau xác thực danh tính.
Phiên bản spec mới nhất đẩy khả năng quan sát đi xa hơn nữa. Các header Mcp-Method và Mcp-Name mới lộ ra thao tác được yêu cầu và công cụ đang được gọi, mà firewall không cần phải mở nội dung request. Vậy nên một đội có thể phân biệt một agent đang đọc một ticket với một agent đang xóa năm mươi ticket, ngay ở tầng mạng.
Cloudflare thực sự chia điều này thành hai trường hợp: shadow MCP thuần túy, một máy chủ chưa từng được duyệt, và bỏ qua portal, một máy chủ đã được duyệt nhưng bị truy cập trực tiếp vòng qua trạm kiểm soát. Cả hai đều bị chặn bằng cùng một quy tắc cơ bản. Logic rất đơn giản: mọi thứ đi qua portal đều được biết đến và ghi log, mọi thứ khác đều bị chặn. Với một công ty, đó là dấu chấm hết cho máy chủ MCP ma được cài đặt vào một đêm thứ Sáu.
WriteGuard: phân quyền theo từng công cụ
Ngay cả một máy chủ đã được duyệt cũng có thể gây hại, vì một agent thừa hưởng toàn bộ quyền của người dùng nó cùng một lúc. Đó là lúc WriteGuard xuất hiện, thứ mà Cloudflare vừa mở ở dạng private beta. Ý tưởng: phân loại mọi công cụ của mọi máy chủ MCP vào một cấp rủi ro, và áp dụng một chính sách khác nhau cho mỗi cấp.
- Một thao tác đọc đi qua không gặp cản trở.
- Một thao tác ghi có giới hạn, như đăng một bình luận, đi qua nhưng có bổ sung: hành động được ký như đến từ một agent, thay mặt một người cụ thể, và một sự kiện audit được gửi đến log trung tâm.
- Một hành động quan trọng — merge code, deploy lên production, xóa hàng loạt — bị chặn trước khi máy chủ kịp xử lý nó.
Ví dụ về GitLab trong bài viết của Cloudflare cho thấy rõ sự phân cấp này: đọc một merge request thì đi qua, bình luận vào đó thì đi qua kèm quy trách nhiệm, và merge nó thì bị từ chối cho đến khi một con người tự làm điều đó.
Phần thú vị nhất là mô hình danh tính. Agent giữ quyền của nhân viên mà nó phục vụ, nhưng mỗi lần ghi giờ đây mang hai chữ ký: người đó, và phiên agent đang hành động thay họ. Các hệ thống phía sau cuối cùng cũng có thể phân biệt một thay đổi thủ công với một thay đổi do máy tạo ra, và audit được gửi bất đồng bộ đến một log trung tâm, đã được xóa dữ liệu nhạy cảm. Cho đến nay một agent không thể phân biệt được với con người của nó trong log; với một cuộc audit sự cố, điều đó thay đổi mọi thứ — một truy vấn duy nhất cho bạn biết liệu lần merge đáng ngờ hôm thứ Ba có phải đến từ một đồng nghiệp vội vàng hay một phiên agent trở nên sáng tạo.
Cloudflare không đang bán một lý thuyết; họ mô tả cách dùng nội bộ của chính mình: portal của họ kết nối 27 máy chủ MCP, tăng từ 13 hồi tháng 4. Con số đó nói lên câu chuyện thật — ngay cả tại Cloudflare, số lượng máy chủ cũng tăng gấp đôi trong vài tháng, và đó chính xác là lý do vì sao kiểm soát theo từng công cụ trở nên cần thiết. Hướng đi mà ngành công nghiệp đang chọn rất rõ ràng: ngừng tin tưởng cả một máy chủ, và quyết định từng hành động một xem agent được phép làm gì.
Giới hạn: những gì vẫn chưa được khắc phục
Những giới hạn cần được nói thẳng ra. WriteGuard là một private beta đứng sau một form đăng ký, và công nghệ phát hiện của Gateway cần một triển khai Cloudflare Zero Trust với tính năng kiểm tra TLS được bật: với một nhà phát triển đơn lẻ hoặc một nhóm nhỏ, đó đơn giản không phải là hạ tầng của bạn. Ngay cả trong một công ty, công nghệ phát hiện cũng chỉ thấy được lưu lượng mạng mà nó giải mã — một máy chủ MCP cục bộ chạy qua stdio, được khởi chạy như một tiến trình bình thường trên máy của bạn, vẫn vô hình với Gateway. Đó chính xác là cách hầu hết các máy chủ mà nhà phát triển cài đặt thực sự vận hành.
Trên hết, không công cụ nào trong số này sửa được cơ chế cốt lõi mà GhostSplice đã phơi bày: chừng nào một agent còn tự do kết hợp bất cứ thứ gì đi vào context của nó, các mảnh vô hại sẽ tiếp tục ghép lại thành các lệnh thù địch. Các nhà nghiên cứu ASSET tự nói điều này: cách khắc phục đòi hỏi phải coi kết quả công cụ là dữ liệu, không bao giờ là lệnh, và sự tách biệt đó chưa tồn tại một cách tự nhiên trong các agent hiện nay.
Trong lúc chờ đợi, khuyến nghị của họ gói gọn trong ba bước: ngăn giá trị ra từ một công cụ đưa thẳng vào tham số của công cụ khác mà không kiểm tra, giữ khả năng từ chối mỗi lần gọi công cụ bằng tay, và mặc định coi mọi chú thích từ một máy chủ chưa được kiểm định là thù địch. Không cái nào trong ba điều này tự động diễn ra hôm nay: bạn áp dụng chúng, hoặc không ai làm cả. Hãy coi mọi thứ mà Cloudflare đưa ra ở đây như dây an toàn, không phải phanh — nó giới hạn thiệt hại, nó không ngăn được va chạm.
Những gì chúng tôi áp dụng cho setup của mình
Những gì cần làm, bắt đầu từ hôm nay:
- Kiểm kê. Liệt kê những máy chủ MCP thực sự được kết nối vào agent của bạn, và gỡ bỏ những cái bạn không còn dùng.
- Sắp xếp theo nguồn gốc. Một máy chủ chính thức từ một nhà cung cấp uy tín, có. Một repo GitHub 40 sao tìm thấy trong một thread, không — trừ khi bạn đã đọc nó làm gì với dữ liệu của bạn.
- Giới hạn phạm vi quyền. Cấp cho mỗi máy chủ một token riêng với phạm vi tối thiểu, không bao giờ dùng master key của bạn, và xoay vòng những token đó như bạn sẽ làm với bất kỳ hệ thống production nào.
- Giữ quyền kiểm soát các hành động nhạy cảm. Một agent ghi, merge, hay xóa phải quay lại qua bạn — phiên bản thủ công của thứ mà WriteGuard công nghiệp hóa.
- Áp dụng quy tắc GhostSplice hằng ngày. Khi agent của bạn xâu chuỗi các hành động công cụ mà bạn không yêu cầu, hãy dừng nó lại và đọc những gì máy chủ đã nói với nó.
Mọi agent client đều có thể liệt kê các máy chủ đã kết nối và công cụ của chúng, và danh sách đó chỉ mất ba mươi giây để đọc. Ba mươi giây đó là tỷ lệ thời gian trên bảo mật tốt nhất trong toàn bộ setup của bạn.
Nếu bạn ở trong một công ty, hãy thêm lớp mạng: công nghệ phát hiện MCP của Gateway và các portal đáng để triển khai, vì shadow MCP đã tồn tại trong tổ chức của bạn rồi, dù bạn có thấy nó hay không.
MCP không phải là vấn đề — tốc độ mà chúng ta đã trao khóa cho nó mới chính là vấn đề.
