Một bình luận vô hình duy nhất trong Pull Request (PR) của Azure DevOps có thể biến AI coding agent của chính người đánh giá thành công cụ chống lại họ, điều khiển nó xâm nhập vào các dự án mà kẻ tấn công không có quyền truy cập và âm thầm rò rỉ những gì nó tìm thấy.
Lỗ hổng này nằm trong Azure DevOps MCP server chính thức của Microsoft. Nó hoạt động vì một trong các công cụ của server này trả về mô tả Pull Request mà không có rào cản chống Prompt Injection - thứ mà công ty đã áp dụng cho các công cụ khác.
Công ty an ninh mạng Manifold Security đã chi tiết hóa lỗi "confused-deputy" (người đại diện bị nhầm lẫn) này trong tuần này. Microsoft cung cấp server này để các AI agent có thể đọc và vận hành Azure DevOps thay cho người dùng, từ Pull Request, pipeline, wiki đến các hạng mục công việc (work items), tất cả đều sử dụng quyền hạn của chính người dùng đó. Đây chính là vấn đề cốt lõi: nội dung do người khác viết có thể trở thành chỉ dẫn mà agent thực hiện theo.
Các mô tả PR trong Azure DevOps hỗ trợ Markdown, cho phép sử dụng các bình luận HTML. Trên giao diện web, một bình luận HTML (<!-- ... -->) sẽ không hiển thị gì, vì vậy người đánh giá khi xem mô tả sẽ chỉ thấy một thay đổi bình thường. Tuy nhiên, REST API lại trả về nguyên văn đoạn mã đó, và server sẽ gửi thẳng văn bản đó cho AI agent.
Sự khác biệt giữa những gì con người nhìn thấy và những gì mô hình AI nhận được chính là cơ chế tấn công: kẻ tấn công không bao giờ trực tiếp nói chuyện với agent nhưng lại gài các chỉ dẫn vào nội dung mà chúng biết agent sẽ đọc sau đó.
Khi người đánh giá yêu cầu agent của họ xem xét PR, văn bản ẩn có thể viết lại mục tiêu của agent. Vì agent đang mang theo thông tin xác thực (credentials) của người đánh giá, nó có thể hoạt động trên các dự án mà kẻ tấn công vốn không có quyền tiếp cận.
Manifold cho biết quyền truy cập này có thể chạm tới mã nguồn, các bí mật (secrets) và hạng mục công việc, chứ không chỉ dừng lại ở trang wiki như trong bản thử nghiệm (Proof of Concept - PoC) của họ. Công ty gọi đây là một trường hợp leo thang đặc quyền điển hình, vì người đánh giá thường có cấp bậc cao hơn người mở Pull Request. Kẻ tấn công không đạt được gì trực tiếp; chúng "mượn" quyền truy cập của người đánh giá thông qua văn bản mà người đó không bao giờ nhìn thấy.
Lỗ hổng do thiếu cơ chế bảo vệ trong luồng Pull Request
Điều khiến lỗ hổng này nghiêm trọng hơn một cảnh báo Prompt Injection thông thường là Microsoft thực tế đã có giải pháp phòng vệ cho nó. Khi đọc mã nguồn của server, Manifold nhận thấy nó sử dụng "spotlighting", một kỹ thuật từ hướng dẫn của Microsoft về tấn công indirect prompt injection: nó bao bọc nội dung không tin cậy trong các dấu phân cách để mô hình có thể phân biệt dữ liệu với các chỉ dẫn cần tuân theo.
Công ty đã thêm nó vào PR #1062, nơi các công cụ đọc trang wiki và nhật ký xây dựng (build-log) chuyển đầu ra của chúng qua một hàm hỗ trợ chung là createExternalContentResponse. Tuy nhiên, công cụ trả về Pull Request, repo_get_pull_request_by_id, không bao giờ gọi hàm này, do đó nó trả về mô tả ở dạng thô (raw) - chính xác là bề mặt mà kẻ tấn công có thể khai thác.
Tờ The Hacker News đã xác nhận rằng đường dẫn này vẫn chưa được bảo vệ trong mã nguồn hiện tại tính đến ngày 21 tháng 7.
Trong bản PoC của Manifold chạy trên bản build cục bộ v2.7.0, một người đóng góp cho dự án mở một PR trông có vẻ bình thường nhưng bình luận ẩn bên trong mang theo mã độc (payload). Ngay khi agent bắt đầu đánh giá, nó chạy một chuỗi lệnh: kích hoạt một pipeline trong một dự án khác, đọc một trang wiki bảo mật mà kẻ tấn công không thể mở, và đăng trang đó dưới dạng bình luận trên PR để kẻ tấn công có thể đọc.
"Vấn đề nằm ở trình tự và ý đồ, được thúc đẩy bởi văn bản mà con người không bao giờ nhìn thấy." - Các nhà nghiên cứu viết.
Nhóm nghiên cứu đã tái hiện thành công cuộc tấn công này với cả Copilot CLI và Claude Code, chứng tỏ nó không phụ thuộc vào một loại agent cụ thể nào.
Tuy nhiên, chuỗi tấn công này cần một số điều kiện tiên quyết: văn bản PR do kẻ tấn công viết, một quy trình làm việc đưa nội dung đó cho agent, một người đánh giá có quyền truy cập cao hơn kẻ tấn công và một agent được phép chạy các công cụ mà không cần hỏi ý kiến.
"Bộ ba chết chóc" trong bảo mật AI
Mô hình tấn công này không mới. Vào tháng 5 năm 2025, Invariant Labs đã chỉ ra lớp tấn công tương tự đối với GitHub MCP server. Trường hợp đó là một ví dụ mà Simon Willison đã chỉ ra khi gọi tên lethal trifecta (bộ ba chết chóc): một agent có quyền truy cập vào dữ liệu riêng tư, tiếp xúc với nội dung không tin cậy và có cách để gửi dữ liệu ra ngoài.
Người phát ngôn của Microsoft đã cảm ơn Manifold vì đã báo cáo hành vi này và gọi đây là "một lớp rủi ro AI đã biết" mà công ty đang tiếp tục nghiên cứu các biện pháp bảo vệ. Microsoft không cho biết liệu họ có thay đổi mã nguồn hay chỉ định mã lỗi CVE hay không.
Công ty lưu ý rằng cuộc tấn công yêu cầu kẻ tấn công phải có quyền ghi vào dự án và người dùng thứ hai phải kích hoạt công cụ AI trên nội dung đó. Họ khuyến nghị khách hàng nên giới hạn quyền truy cập dự án và "xem xét các thay đổi đề xuất trước khi yêu cầu công cụ AI thực hiện". Tuy nhiên, điểm yếu ở đây là payload hoàn toàn vô hình đối với con người trong giao diện đánh giá.
Các biện pháp phòng ngừa được khuyến nghị
- Cung cấp cho agent các token có quyền hạn tối thiểu (least-privilege) và giới hạn phạm vi trong dự án đang được đánh giá.
- Chỉ tải các MCP domains mà tác vụ cần; server cục bộ có thể thu hẹp chúng bằng cờ
-d. - Loại bỏ các quyền chạy pipeline, đọc wiki và đăng bình luận khỏi bộ công cụ đánh giá mã nguồn nếu không cần thiết.
- Kiểm tra dấu vết công cụ (tool traces) của agent để tìm các hoạt động bất thường giữa các dự án.
- Quét các mô tả PR để tìm các bình luận HTML ẩn.
Cơ chế "spotlighting" chỉ hoạt động khi có người nhớ thêm nó vào. Nó bao bọc nội dung không tin cậy theo từng đường dẫn phản hồi, vì vậy hệ thống phòng thủ chỉ mạnh bằng mắt xích yếu nhất của nó. Trên một bề mặt công cụ không ngừng mở rộng, những khoảng trống như thế này sẽ xuất hiện nhanh hơn khả năng kiểm tra của bất kỳ ai.
