Lạm dụng GitHub MCP: Truy cập kho lưu trữ riêng tư thông qua MCP

• Chỉ cần một MCP agent được kết nối với tài khoản GitHub đọc Issue công khai cũng có thể mở ra đường rò rỉ dữ liệu từ kho lưu trữ riêng tư
• Cuộc tấn công bắt đầu khi prompt injection gián tiếp được cài trong Issue của kho lưu trữ công khai làm thay đổi luồng sử dụng công cụ của agent
• Trong bản demo, Issue độc hại trong ukend0464/pacman thông qua tích hợp Claude 4 Opus và GitHub MCP đã đưa thông tin kho lưu trữ riêng tư ra một PR công khai
• Cốt lõi vấn đề không nằm ở lỗi mã của GitHub MCP server, mà ở cấu trúc trong đó công cụ đáng tin cậy được dùng cùng với nội dung bên ngoài không đáng tin cậy
• Các hệ thống agent cần quyền tối thiểu theo từng kho lưu trữ, giới hạn truy cập theo phiên, và giám sát bảo mật runtime như MCP-scan

---

Cuộc tấn công GitHub MCP bắt đầu từ Issue độc hại

• Invariant đã phát hiện một lỗ hổng trong GitHub MCP integration được sử dụng rộng rãi, cho phép kẻ tấn công chiếm quyền agent của người dùng và làm rò rỉ dữ liệu kho lưu trữ riêng tư
  • GitHub MCP server này là dự án có 14k stars trên GitHub
  • Lỗ hổng là một trong những trường hợp Toxic Agent Flows ban đầu được bộ phân tích bảo mật của Invariant phát hiện
• Toxic Agent Flow là luồng trong đó prompt injection gián tiếp khiến agent thực hiện một trình tự sử dụng công cụ ngoài ý muốn
  • Có thể dẫn đến các hành vi như rò rỉ dữ liệu hoặc thực thi mã độc
• Trong bối cảnh coding agent và IDE được triển khai nhanh chóng, các cuộc tấn công tương tự có thể phơi bày người dùng các công cụ phát triển phần mềm cốt lõi trước rủi ro

Cấu trúc tấn công

• Người dùng đang sử dụng một MCP client như Claude Desktop và đã kết nối GitHub MCP server với tài khoản GitHub của mình
• Kịch bản tấn công giả định hai loại kho lưu trữ
  • <user>/public-repo: kho lưu trữ công khai nơi bất kỳ ai cũng có thể tạo Issue và báo cáo lỗi
  • <user>/private-repo: kho lưu trữ riêng tư chứa mã độc quyền hoặc dữ liệu nội bộ công ty
• Theo các quy tắc quyền thông thường của GitHub, kẻ tấn công có thể tạo Issue độc hại trong kho lưu trữ công khai
• Khi người dùng gửi cho agent một yêu cầu bình thường như Have a look at the open issues in <user>/public-repo, agent sẽ lấy các Issue của kho lưu trữ công khai và bị phơi nhiễm với prompt injection
• Sau đó agent có thể đưa dữ liệu kho lưu trữ riêng tư vào context và làm rò rỉ dữ liệu thông qua một PR được tự động tạo trong kho lưu trữ công khai

Luồng rò rỉ được xác nhận trong demo

• Bản demo sử dụng kho lưu trữ công khai ukend0464/pacman và nhiều kho lưu trữ riêng tư
  • ukend0464/pacman: kho lưu trữ công khai chứa phần triển khai một trò chơi Pacman đơn giản, có thể xem trên GitHub
  • Các kho lưu trữ riêng tư chứa dự án cá nhân và thông tin nhạy cảm của người dùng
• Kẻ tấn công đặt một Issue độc hại trong kho lưu trữ công khai
  • Issue này chứa payload sẽ được thực thi ngay khi agent truy vấn danh sách Issue của kho lưu trữ công khai
• Người dùng gửi yêu cầu tới Claude 4 Opus để kích hoạt cuộc tấn công
  • Theo mặc định, Claude Desktop yêu cầu người dùng xác nhận từng lệnh gọi công cụ riêng lẻ
  • Nhiều người dùng khi dùng agent chọn chính sách xác nhận “Always Allow” và ngừng giám sát từng hành động riêng lẻ
• Agent duyệt qua danh sách Issue, phát hiện payload tấn công, đưa dữ liệu kho lưu trữ riêng tư vào context, rồi làm rò rỉ chúng trong pull request của kho lưu trữ pacman
• PR công khai chứa thông tin riêng tư của người dùng ukend0464
  • Thông tin về kho lưu trữ riêng tư như Jupiter Star
  • Kế hoạch chuyển tới Nam Mỹ
  • Thông tin lương
• Toàn bộ quá trình suy luận của agent và trình tự sử dụng công cụ có thể xem trong trace đầy đủ trên Invariant Explorer

Toxic Agent Flow xảy ra ngay cả với công cụ đáng tin cậy

• Lỗ hổng này khác với các cuộc tấn công nhiễm bẩn công cụ truyền thống, vốn đòi hỏi chính công cụ MCP phải bị xâm phạm
• Khi một agent được kết nối với nền tảng bên ngoài như GitHub bị phơi nhiễm với thông tin không đáng tin cậy, vấn đề vẫn có thể xảy ra ngay cả khi công cụ hoàn toàn đáng tin cậy
• Việc hiểu, phân tích và giảm thiểu các luồng như vậy trong hệ thống agent rất khó thực hiện thủ công ở quy mô lớn
• Invariant đã phát triển phương pháp tự động hóa phát hiện Toxic Agent Flow để giúp tổ chức nhận diện và mô hình hóa các mối đe dọa tiềm ẩn trước khi chúng bị tác nhân độc hại khai thác

Phạm vi ảnh hưởng và biện pháp giảm thiểu

• Thử nghiệm tập trung vào Claude Desktop, nhưng lỗ hổng không giới hạn ở một agent hay MCP client cụ thể
• Mọi agent dùng GitHub MCP server đều có thể bị ảnh hưởng, bất kể mô hình nền tảng hay cách triển khai
• Điểm quan trọng là vấn đề này không phải là lỗi trong chính mã của GitHub MCP server
  • Đây không phải là lỗ hổng mà GitHub có thể tự giải quyết chỉ bằng bản vá phía server
  • Đây là vấn đề mang tính cấu trúc cần được xử lý ở cấp hệ thống agent

• Kiểm soát quyền chi tiết

  • Khi sử dụng tích hợp MCP như GitHub, cần giới hạn quyền truy cập của agent vào các kho lưu trữ cần thiết
  • Quyền dựa trên token truyền thống cung cấp một phần bảo vệ, nhưng có thể tạo ra các ràng buộc cứng nhắc làm hạn chế chức năng của agent
  • Invariant khuyến nghị một lớp bảo mật runtime động được thiết kế cho hệ thống agent
  • Invariant Guardrails cung cấp kiểm soát truy cập nhận biết context, thích ứng với workflow của agent
  • Chính sách ví dụ giới hạn mỗi phiên chỉ được truy cập một kho lưu trữ, qua đó ngăn rò rỉ thông tin giữa các kho lưu trữ
  • Nếu các lệnh gọi công cụ liên quan đến kho lưu trữ đối với repo hoặc owner khác nhau diễn ra nối tiếp, chúng sẽ bị xử lý là vi phạm
  • Chính sách đầy đủ có thể xem tại github_policy.txt
  • Cách áp dụng có trong MCP-scan documentation
  • Có thể kiểm thử chính sách trước khi triển khai tại Guardrails Playground

• Giám sát bảo mật liên tục

  • Cùng với biện pháp phòng ngừa, cần có giám sát để phát hiện và ứng phó mối đe dọa theo thời gian thực
  • Invariant khuyến nghị triển khai các scanner bảo mật chuyên dụng như MCP-scan để liên tục kiểm tra tương tác giữa agent và hệ thống MCP
  • proxy mode của MCP-scan cho phép quét kết nối MCP theo thời gian thực mà không cần sửa đổi hạ tầng agent hiện có
  • Bằng cách định tuyến lưu lượng MCP qua proxy, có thể có được khả năng quan sát và quét vi phạm bảo mật theo thời gian thực
  • Giám sát toàn diện tạo ra audit trail, giúp xác nhận trạng thái bảo vệ trước các lỗ hổng tiềm ẩn, nỗ lực khai thác và các cuộc tấn công mới

Chỉ căn chỉnh mô hình là chưa đủ

• Thử nghiệm sử dụng Claude 4 Opus, vốn đã được áp dụng các quy trình căn chỉnh và huấn luyện bảo mật mới nhất
• Dù được huấn luyện an toàn mạnh, agent vẫn có thể bị thao túng bởi prompt injection tương đối đơn giản
• Nhiều cơ chế phòng thủ phát hiện prompt injection có sẵn cũng không bắt được cuộc tấn công này
• Bảo mật hệ thống agent phụ thuộc vào context và môi trường
  • Huấn luyện căn chỉnh mô hình nói chung không thể dự đoán mọi kịch bản triển khai hay yêu cầu bảo mật riêng của từng tổ chức
  • Các biện pháp bảo mật cấp hệ thống cần bổ sung cho cơ chế bảo vệ ở cấp mô hình

Những bài toán còn lại trong bảo mật agent

• Agent dùng GitHub MCP server có thể bị thao túng thông qua Issue GitHub độc hại để làm rò rỉ dữ liệu kho lưu trữ riêng tư sang kho lưu trữ công khai
• Lỗ hổng này đặc thù với GitHub MCP, nhưng các cuộc tấn công tương tự vẫn đang tiếp tục xuất hiện trong những môi trường khác
  • Legit Security gần đây đã báo cáo lỗ hổng prompt injection từ xa trong GitLab Duo
• Để triển khai có trách nhiệm ở quy mô lớn, các tích hợp MCP và hệ thống agent cần scanner bảo mật chuyên dụng và kiểm soát chính sách như MCP-scan và Guardrails

[crawler]

Nghe thì to tát nhưng thực ra chỉ là vấn đề phát sinh do prompt injection cộng với việc MCP có quá nhiều quyền có thể dùng.
Vì vậy cũng tạo cảm giác như đang quảng bá một công cụ có thể kiểm soát quyền của MCP từ bên ngoài.
Sẽ tốt hơn nếu quyền mà MCP có thể dùng được tách khác nhau giữa prompt nhận từ bên ngoài và prompt chỉ được nhập ở bên trong.