Cách thức tấn công hoạt động

Các nhà nghiên cứu mô tả mẫu GitHub Agentic Workflow dễ bị tấn công là mẫu có các đặc điểm sau:

• Kích hoạt dựa trên sự kiện issues.assigned
• Đọc tiêu đề và nội dung của issue
• Đăng bình luận bằng công cụ agent như add-comment
• Chạy với quyền truy cập đọc vào các repository khác trong tổ chức, bao gồm cả repository riêng tư

Cuộc tấn công diễn ra theo bốn bước:

1. Kẻ tấn công tạo một GitHub Issue có vẻ vô hại trong một repository công khai thuộc về tổ chức đang sử dụng mẫu Agentic Workflow dễ bị tấn công.
2. Ẩn bên trong nội dung issue là các lệnh tiếng Anh đơn giản hướng dẫn AI agent tìm nạp tệp tin từ các repository riêng tư.
3. Khi quá trình tự động hóa của GitHub gán issue, workflow được kích hoạt bởi sự kiện khiến agent tìm nạp dữ liệu từ các repository mà nó có thể truy cập, bao gồm cả repository riêng tư.
4. Agent đăng nội dung đã tìm nạp lên dưới dạng bình luận công khai trên issue, có khả năng để lộ dữ liệu cho bất kỳ ai có thể xem issue đó.

Điểm yếu kiến trúc cốt lõi

Sai sót cốt lõi là sự thất bại trong việc duy trì ranh giới tin cậy chặt chẽ giữa các hướng dẫn cấp hệ thống và dữ liệu người dùng không đáng tin cậy trong cửa sổ ngữ cảnh của AI agent. Như Sasi Levi từ Noma đã phát biểu: "Cửa sổ ngữ cảnh của agent cũng chính là bề mặt tấn công của nó. Bất kỳ nội dung nào agent đọc — dù là issue, pull request, bình luận hay tệp tin — đều có thể bị vũ khí hóa nếu agent coi nội dung đó như đầu vào chỉ dẫn."

Các agent dựa trên LLM gặp khó khăn trong việc phân biệt giữa dữ liệu và hướng dẫn khi cả hai xuất hiện trong cùng một ngữ cảnh hoặc đầu ra của công cụ. Đây không chỉ đơn thuần là một lỗi lập trình thông thường mà là một rủi ro mang tính cấu trúc trong các workflow AI agent, nơi nội dung không đáng tin cậy có thể ảnh hưởng đến hành vi của agent nếu workflow không cô lập hoặc hạn chế chúng.

Các nhà nghiên cứu đã chính thức phân loại loại lỗ hổng này là Agentic Workflow Injection (AWI), xác định hai mẫu cốt lõi: Prompt-to-Agent (P2A), nơi nội dung không đáng tin cậy đến ranh giới prompt của agent, và Prompt-to-Script (P2S), nơi ảnh hưởng của kẻ tấn công lan truyền qua các đầu ra do mô hình tạo ra vào các script phía sau.

Kỹ thuật vượt qua rào chắn bảo vệ: Từ khóa "Additionally"

GitHub đã có các rào chắn bảo vệ nhằm ngăn chặn việc trích xuất dữ liệu, nhưng các nhà nghiên cứu của Noma báo cáo rằng họ có thể vượt qua chúng bằng một kỹ thuật đơn giản đến bất ngờ. Việc thêm từ "Additionally" vào các hướng dẫn đã tiêm nhiễm được cho là đã khiến mô hình thay đổi cách hiểu về đầu ra thay vì từ chối yêu cầu, cho phép việc rò rỉ dữ liệu diễn ra như thể đó là sự tiếp nối được ủy quyền hợp pháp của tác vụ.

Cách tiếp cận này phù hợp với các nghiên cứu rộng hơn về tiêm nhiễm prompt, cho thấy rằng cách diễn đạt cụ thể hoặc văn bản trả về từ công cụ có thể khiến các mô hình làm theo các hướng dẫn độc hại mà đáng lẽ chúng không nên làm theo. Việc vượt qua rào chắn này phản ánh các mẫu hình đã thấy trong các sự cố trước đó, chẳng hạn như lỗ hổng GitHub MCP được Invariant Labs tiết lộ, nơi một issue độc hại có thể chiếm quyền agent của người dùng để làm rò rỉ dữ liệu từ các repository riêng tư.

Các biện pháp giảm thiểu được khuyến nghị cho tổ chức

Dựa trên các phát hiện của GitLost và hướng dẫn bảo mật workflow agent rộng hơn, các tổ chức bị ảnh hưởng nên thực hiện các biện pháp kiểm soát sau:

• Áp dụng zero-trust cho đầu vào agent — không bao giờ coi nội dung do người dùng kiểm soát là đầu vào hướng dẫn đáng tin cậy, và cô lập dữ liệu người dùng không đáng tin cậy khỏi các prompt hệ thống cốt lõi.
• Áp dụng nguyên tắc đặc quyền tối thiểu chặt chẽ bằng cách loại bỏ quyền truy cập chéo repository không cần thiết và hạn chế khả năng của các agent trong việc để lộ dữ liệu qua các đầu ra công khai.
• Sử dụng danh sách cho phép đối với các công cụ thay vì danh sách chặn, và yêu cầu cổng phê duyệt của con người trước khi agent thực hiện các hành động nhạy cảm như đăng bình luận hiển thị bên ngoài hoặc truy cập các repository nhạy cảm.
• Kiểm toán các tích hợp AI agent trong CI/CD và các workflow tự động hóa repository, đặc biệt là nơi ngữ cảnh sự kiện GitHub không đáng tin cậy được đưa vào prompt hoặc đầu vào của agent.
• Cô lập về mặt logic đầu vào của người dùng không đáng tin cậy khỏi các chỉ thị cấp hệ thống, coi văn bản do người dùng tạo ra là dữ liệu không đáng tin cậy chứ không phải hướng dẫn có thẩm quyền.

Các tổ chức cũng nên áp dụng nguyên tắc đặc quyền tối thiểu cho các bí mật (secrets) của agent và triển khai giám sát bảo mật liên tục để phát hiện các nỗ lực tiêm nhiễm prompt.

Phản hồi của GitHub (tính đến ngày 7 tháng 7)

Theo Dark Reading và dòng thời gian tiết lộ của Noma Security:

• Noma đã tiết lộ có trách nhiệm lỗ hổng cho GitHub.
• GitHub cho Noma biết họ đã cập nhật tài liệu liên quan đến mẫu workflow dễ bị tấn công, và các nhà nghiên cứu báo cáo rằng cấu hình dễ bị tấn công không còn tồn tại khi họ kiểm tra lần cuối.
• Tính đến ngày 7 tháng 7, GitHub chưa đưa ra tuyên bố chính thức nào trước công chúng hoặc CVE cho GitLost.
• Lỗ hổng này dường như đã được xử lý một phần thông qua việc xóa bỏ hoặc sửa đổi tài liệu và mẫu workflow cho phép, thay vì thông qua một bản vá bảo mật cấp nền tảng được ghi nhận rõ ràng.

Bức tranh toàn cảnh: Một rủi ro mang tính hệ thống

GitLost không phải là một sự cố cá biệt. Nó đại diện cho một loại lỗ hổng đang gia tăng, nơi các AI agent có quyền truy cập vào dữ liệu nhạy cảm bị phơi bày trước nội dung người dùng không đáng tin cậy. Các vấn đề tương tự đã ảnh hưởng đến các tích hợp GitHub MCP, workflow Gemini CLI của Google (lỗ hổng TrustIssues) và Claude Code GitHub Actions. Điểm chung là các agent dựa trên LLM thiếu khả năng cố hữu để phân biệt giữa dữ liệu và hướng dẫn khi cả hai xuất hiện trong cùng một cửa sổ ngữ cảnh — một thách thức kiến trúc cơ bản mà không một bản vá nền tảng đơn lẻ nào có thể giải quyết triệt để.

Cách thức tấn công hoạt động

Các nhà nghiên cứu mô tả mẫu GitHub Agentic Workflow dễ bị tấn công là mẫu có các đặc điểm sau:

• Kích hoạt dựa trên sự kiện issues.assigned
• Đọc tiêu đề và nội dung của issue
• Đăng bình luận bằng công cụ agent như add-comment
• Chạy với quyền truy cập đọc vào các repository khác trong tổ chức, bao gồm cả repository riêng tư

Cuộc tấn công diễn ra theo bốn bước:

1. Kẻ tấn công tạo một GitHub Issue có vẻ vô hại trong một repository công khai thuộc về tổ chức đang sử dụng mẫu Agentic Workflow dễ bị tấn công.
2. Ẩn bên trong nội dung issue là các lệnh tiếng Anh đơn giản hướng dẫn AI agent tìm nạp tệp tin từ các repository riêng tư.
3. Khi quá trình tự động hóa của GitHub gán issue, workflow được kích hoạt bởi sự kiện khiến agent tìm nạp dữ liệu từ các repository mà nó có thể truy cập, bao gồm cả repository riêng tư.
4. Agent đăng nội dung đã tìm nạp lên dưới dạng bình luận công khai trên issue, có khả năng để lộ dữ liệu cho bất kỳ ai có thể xem issue đó.

Điểm yếu kiến trúc cốt lõi

Sai sót cốt lõi là sự thất bại trong việc duy trì ranh giới tin cậy chặt chẽ giữa các hướng dẫn cấp hệ thống và dữ liệu người dùng không đáng tin cậy trong cửa sổ ngữ cảnh của AI agent. Như Sasi Levi từ Noma đã phát biểu: "Cửa sổ ngữ cảnh của agent cũng chính là bề mặt tấn công của nó. Bất kỳ nội dung nào agent đọc — dù là issue, pull request, bình luận hay tệp tin — đều có thể bị vũ khí hóa nếu agent coi nội dung đó như đầu vào chỉ dẫn."

Các agent dựa trên LLM gặp khó khăn trong việc phân biệt giữa dữ liệu và hướng dẫn khi cả hai xuất hiện trong cùng một ngữ cảnh hoặc đầu ra của công cụ. Đây không chỉ đơn thuần là một lỗi lập trình thông thường mà là một rủi ro mang tính cấu trúc trong các workflow AI agent, nơi nội dung không đáng tin cậy có thể ảnh hưởng đến hành vi của agent nếu workflow không cô lập hoặc hạn chế chúng.

Các nhà nghiên cứu đã chính thức phân loại loại lỗ hổng này là Agentic Workflow Injection (AWI), xác định hai mẫu cốt lõi: Prompt-to-Agent (P2A), nơi nội dung không đáng tin cậy đến ranh giới prompt của agent, và Prompt-to-Script (P2S), nơi ảnh hưởng của kẻ tấn công lan truyền qua các đầu ra do mô hình tạo ra vào các script phía sau.

Kỹ thuật vượt qua rào chắn bảo vệ: Từ khóa "Additionally"

GitHub đã có các rào chắn bảo vệ nhằm ngăn chặn việc trích xuất dữ liệu, nhưng các nhà nghiên cứu của Noma báo cáo rằng họ có thể vượt qua chúng bằng một kỹ thuật đơn giản đến bất ngờ. Việc thêm từ "Additionally" vào các hướng dẫn đã tiêm nhiễm được cho là đã khiến mô hình thay đổi cách hiểu về đầu ra thay vì từ chối yêu cầu, cho phép việc rò rỉ dữ liệu diễn ra như thể đó là sự tiếp nối được ủy quyền hợp pháp của tác vụ.

Cách tiếp cận này phù hợp với các nghiên cứu rộng hơn về tiêm nhiễm prompt, cho thấy rằng cách diễn đạt cụ thể hoặc văn bản trả về từ công cụ có thể khiến các mô hình làm theo các hướng dẫn độc hại mà đáng lẽ chúng không nên làm theo. Việc vượt qua rào chắn này phản ánh các mẫu hình đã thấy trong các sự cố trước đó, chẳng hạn như lỗ hổng GitHub MCP được Invariant Labs tiết lộ, nơi một issue độc hại có thể chiếm quyền agent của người dùng để làm rò rỉ dữ liệu từ các repository riêng tư.

Các biện pháp giảm thiểu được khuyến nghị cho tổ chức

Dựa trên các phát hiện của GitLost và hướng dẫn bảo mật workflow agent rộng hơn, các tổ chức bị ảnh hưởng nên thực hiện các biện pháp kiểm soát sau:

• Áp dụng zero-trust cho đầu vào agent — không bao giờ coi nội dung do người dùng kiểm soát là đầu vào hướng dẫn đáng tin cậy, và cô lập dữ liệu người dùng không đáng tin cậy khỏi các prompt hệ thống cốt lõi.
• Áp dụng nguyên tắc đặc quyền tối thiểu chặt chẽ bằng cách loại bỏ quyền truy cập chéo repository không cần thiết và hạn chế khả năng của các agent trong việc để lộ dữ liệu qua các đầu ra công khai.
• Sử dụng danh sách cho phép đối với các công cụ thay vì danh sách chặn, và yêu cầu cổng phê duyệt của con người trước khi agent thực hiện các hành động nhạy cảm như đăng bình luận hiển thị bên ngoài hoặc truy cập các repository nhạy cảm.
• Kiểm toán các tích hợp AI agent trong CI/CD và các workflow tự động hóa repository, đặc biệt là nơi ngữ cảnh sự kiện GitHub không đáng tin cậy được đưa vào prompt hoặc đầu vào của agent.
• Cô lập về mặt logic đầu vào của người dùng không đáng tin cậy khỏi các chỉ thị cấp hệ thống, coi văn bản do người dùng tạo ra là dữ liệu không đáng tin cậy chứ không phải hướng dẫn có thẩm quyền.

Các tổ chức cũng nên áp dụng nguyên tắc đặc quyền tối thiểu cho các bí mật (secrets) của agent và triển khai giám sát bảo mật liên tục để phát hiện các nỗ lực tiêm nhiễm prompt.

Phản hồi của GitHub (tính đến ngày 7 tháng 7)

Theo Dark Reading và dòng thời gian tiết lộ của Noma Security:

• Noma đã tiết lộ có trách nhiệm lỗ hổng cho GitHub.
• GitHub cho Noma biết họ đã cập nhật tài liệu liên quan đến mẫu workflow dễ bị tấn công, và các nhà nghiên cứu báo cáo rằng cấu hình dễ bị tấn công không còn tồn tại khi họ kiểm tra lần cuối.
• Tính đến ngày 7 tháng 7, GitHub chưa đưa ra tuyên bố chính thức nào trước công chúng hoặc CVE cho GitLost.
• Lỗ hổng này dường như đã được xử lý một phần thông qua việc xóa bỏ hoặc sửa đổi tài liệu và mẫu workflow cho phép, thay vì thông qua một bản vá bảo mật cấp nền tảng được ghi nhận rõ ràng.

Bức tranh toàn cảnh: Một rủi ro mang tính hệ thống

GitLost không phải là một sự cố cá biệt. Nó đại diện cho một loại lỗ hổng đang gia tăng, nơi các AI agent có quyền truy cập vào dữ liệu nhạy cảm bị phơi bày trước nội dung người dùng không đáng tin cậy. Các vấn đề tương tự đã ảnh hưởng đến các tích hợp GitHub MCP, workflow Gemini CLI của Google (lỗ hổng TrustIssues) và Claude Code GitHub Actions. Điểm chung là các agent dựa trên LLM thiếu khả năng cố hữu để phân biệt giữa dữ liệu và hướng dẫn khi cả hai xuất hiện trong cùng một cửa sổ ngữ cảnh — một thách thức kiến trúc cơ bản mà không một bản vá nền tảng đơn lẻ nào có thể giải quyết triệt để.