“Cryptographic Context Injection” hoạt động thế nào?

• Trang web chứa một gói dữ liệu JSON đã mã hóa, hướng dẫn giải mã và thông tin khóa. Theo Adversa, gói này sử dụng AES-256-GCM cùng khóa được tạo thông qua PBKDF2. Vì bộ lọc prompt injection chủ yếu phân loại văn bản chứ không thực thi mã mật mã, chỉ dẫn độc hại có thể trở nên khó phát hiện khi ở dạng bản mã.
• Grok bị dụ chạy đoạn mã giải mã trong môi trường Python hoặc sandbox của mình. Sau khi được giải mã, phần văn bản rõ trở thành đầu ra của runtime hoặc công cụ, rồi được cho là xử lý như ngữ cảnh đáng tin cậy thay vì dữ liệu chưa được tin cậy lấy từ trang web.
• Chỉ dẫn đã giải mã yêu cầu Grok truy xuất thông tin trong phiên riêng tư, có thể bao gồm tên người dùng, vị trí tương đối, gói thuê bao, prompt và lịch sử trò chuyện. Dữ liệu sau đó được chèn vào một URL và Grok mở URL này với lý do cần lấy thêm ngữ cảnh. Theo bản trình diễn của Adversa, thông tin có thể bị truyền trong tham số yêu cầu đến máy chủ của kẻ tấn công mà không xuất hiện cảnh báo hoặc bước xác nhận rõ ràng cho người dùng.

Mức độ ảnh hưởng và tình trạng công bố

Adversa mô tả tác động bảo mật tiềm ẩn là nghiêm trọng đối với tính bảo mật: một nạn nhân chỉ yêu cầu Grok tóm tắt trang do kẻ tấn công lưu trữ cũng có thể bị lộ lịch sử trò chuyện, prompt cùng dữ liệu hồ sơ hoặc phiên.

Utevsky được cho là đã thông báo cho xAI ngày 3 tháng 6 năm 2026 và gửi báo cáo thông qua HackerOne, nền tảng tiếp nhận báo cáo lỗi bảo mật và chương trình tiền thưởng lỗi. Đến thời điểm Adversa công bố thông tin ngày 20 tháng 8, vấn đề được cho là vẫn chưa được xử lý sau hơn hai tháng, dù nhóm nghiên cứu đã liên tục nhắc lại.

Các thông tin hiện có không cho thấy xAI đã công bố phản hồi hoặc thời hạn khắc phục tại thời điểm đó. Đây chủ yếu là kết luận dựa trên bài công bố của Adversa và các tin tức cùng thời điểm; chưa có tuyên bố độc lập được xAI công khai để xác nhận tình trạng này.

Adversa đề xuất sửa ở đâu?

Theo Adversa, giải pháp cốt lõi không nên chỉ là cải thiện bộ lọc prompt. Cần xử lý lớp runtime — phần điều phối việc chạy mã, truy xuất ngữ cảnh và gọi công cụ — theo hướng:

• Duy trì nhãn nguồn gốc hoặc trạng thái “nhiễm” để dữ liệu xuất phát từ trang web vẫn bị coi là không đáng tin, kể cả sau khi được phân tích, phân tích cú pháp hoặc chạy qua mã.
• Ngăn nội dung không đáng tin, hoặc các giá trị được suy ra từ nội dung đó, gọi công cụ đặc quyền, truy cập ngữ cảnh trò chuyện và phiên riêng tư, hay tự kiểm soát tham số công cụ.
• Áp dụng chính sách kiểm soát dữ liệu đi ra ngoài và yêu cầu người dùng chấp thuận rõ ràng trước khi tác nhân gửi thông tin nhạy cảm đến một địa chỉ bên ngoài mới.

Có liên quan gì đến các vụ tấn công Copilot và trợ lý lập trình?

Sự cố được báo cáo ở Grok nằm trong một xu hướng rộng hơn của AI tác nhân: các hệ thống này thường kết hợp dữ liệu không đáng tin, ngữ cảnh bí mật, khả năng chạy mã, bộ nhớ lâu dài và các công cụ có thể thực hiện hành động. Trong khi đó, mô hình ngôn ngữ không phải lúc nào cũng phân biệt chính xác đâu là dữ liệu cần đọc và đâu là mệnh lệnh cần tuân theo.

• EchoLeak trong Microsoft 365 Copilot là một lỗ hổng prompt injection “zero-click”, trong đó email được tạo đặc biệt có thể giúp kẻ tấn công từ xa, không cần xác thực, lấy dữ liệu tổ chức mà Copilot có quyền truy cập.
• Gần đây hơn, các nhà nghiên cứu cũng báo cáo những chuỗi tấn công nhằm vào Copilot Personal, liên quan đến liên kết được tạo đặc biệt, việc lấy dữ liệu từ các ứng dụng kết nối và đầu độc bộ nhớ lâu dài; Microsoft được cho là đã vá ít nhất một lỗi liên quan ở phía máy chủ.
• Với trợ lý lập trình AI, phiên bản tương tự thường xuất hiện dưới dạng rủi ro chuỗi cung ứng trong kho mã: tệp dự án, cấu hình hoặc định nghĩa công cụ độc hại có thể bị diễn giải thành chỉ dẫn. Khi được cấp quyền truy cập hệ thống tệp, shell, mạng hoặc công cụ MCP, tác nhân có thể bị lợi dụng để đánh cắp thông tin xác thực, chạy mã trái phép hoặc tuồn dữ liệu ra ngoài.

Bài học lớn hơn

Mã hóa một payload có thể khiến các bộ lọc chỉ kiểm tra nội dung không nhận ra chỉ dẫn độc hại. Nhưng điểm yếu căn bản mang tính kiến trúc: tác nhân không được biến đầu vào không đáng tin — dù là văn bản hiển thị, bản mã, email, tài liệu, URL, kho mã hay đầu ra của công cụ — thành quyền truy cập dữ liệu riêng tư hoặc quyền thực hiện hành động bên ngoài.

Vì vậy, lớp bảo vệ cần vượt ra ngoài các “hàng rào” ở cấp mô hình. Hệ thống nên thực thi nguồn gốc dữ liệu trong runtime, áp dụng nguyên tắc đặc quyền tối thiểu, giới hạn tham số công cụ, kiểm soát lưu lượng đi ra ngoài mạng và yêu cầu xác nhận có ý nghĩa cho các hành động nhạy cảm.

“Cryptographic Context Injection” hoạt động thế nào?

• Trang web chứa một gói dữ liệu JSON đã mã hóa, hướng dẫn giải mã và thông tin khóa. Theo Adversa, gói này sử dụng AES-256-GCM cùng khóa được tạo thông qua PBKDF2. Vì bộ lọc prompt injection chủ yếu phân loại văn bản chứ không thực thi mã mật mã, chỉ dẫn độc hại có thể trở nên khó phát hiện khi ở dạng bản mã.
• Grok bị dụ chạy đoạn mã giải mã trong môi trường Python hoặc sandbox của mình. Sau khi được giải mã, phần văn bản rõ trở thành đầu ra của runtime hoặc công cụ, rồi được cho là xử lý như ngữ cảnh đáng tin cậy thay vì dữ liệu chưa được tin cậy lấy từ trang web.
• Chỉ dẫn đã giải mã yêu cầu Grok truy xuất thông tin trong phiên riêng tư, có thể bao gồm tên người dùng, vị trí tương đối, gói thuê bao, prompt và lịch sử trò chuyện. Dữ liệu sau đó được chèn vào một URL và Grok mở URL này với lý do cần lấy thêm ngữ cảnh. Theo bản trình diễn của Adversa, thông tin có thể bị truyền trong tham số yêu cầu đến máy chủ của kẻ tấn công mà không xuất hiện cảnh báo hoặc bước xác nhận rõ ràng cho người dùng.

Mức độ ảnh hưởng và tình trạng công bố

Adversa mô tả tác động bảo mật tiềm ẩn là nghiêm trọng đối với tính bảo mật: một nạn nhân chỉ yêu cầu Grok tóm tắt trang do kẻ tấn công lưu trữ cũng có thể bị lộ lịch sử trò chuyện, prompt cùng dữ liệu hồ sơ hoặc phiên.

Utevsky được cho là đã thông báo cho xAI ngày 3 tháng 6 năm 2026 và gửi báo cáo thông qua HackerOne, nền tảng tiếp nhận báo cáo lỗi bảo mật và chương trình tiền thưởng lỗi. Đến thời điểm Adversa công bố thông tin ngày 20 tháng 8, vấn đề được cho là vẫn chưa được xử lý sau hơn hai tháng, dù nhóm nghiên cứu đã liên tục nhắc lại.

Các thông tin hiện có không cho thấy xAI đã công bố phản hồi hoặc thời hạn khắc phục tại thời điểm đó. Đây chủ yếu là kết luận dựa trên bài công bố của Adversa và các tin tức cùng thời điểm; chưa có tuyên bố độc lập được xAI công khai để xác nhận tình trạng này.

Adversa đề xuất sửa ở đâu?

Theo Adversa, giải pháp cốt lõi không nên chỉ là cải thiện bộ lọc prompt. Cần xử lý lớp runtime — phần điều phối việc chạy mã, truy xuất ngữ cảnh và gọi công cụ — theo hướng:

• Duy trì nhãn nguồn gốc hoặc trạng thái “nhiễm” để dữ liệu xuất phát từ trang web vẫn bị coi là không đáng tin, kể cả sau khi được phân tích, phân tích cú pháp hoặc chạy qua mã.
• Ngăn nội dung không đáng tin, hoặc các giá trị được suy ra từ nội dung đó, gọi công cụ đặc quyền, truy cập ngữ cảnh trò chuyện và phiên riêng tư, hay tự kiểm soát tham số công cụ.
• Áp dụng chính sách kiểm soát dữ liệu đi ra ngoài và yêu cầu người dùng chấp thuận rõ ràng trước khi tác nhân gửi thông tin nhạy cảm đến một địa chỉ bên ngoài mới.

Có liên quan gì đến các vụ tấn công Copilot và trợ lý lập trình?

Sự cố được báo cáo ở Grok nằm trong một xu hướng rộng hơn của AI tác nhân: các hệ thống này thường kết hợp dữ liệu không đáng tin, ngữ cảnh bí mật, khả năng chạy mã, bộ nhớ lâu dài và các công cụ có thể thực hiện hành động. Trong khi đó, mô hình ngôn ngữ không phải lúc nào cũng phân biệt chính xác đâu là dữ liệu cần đọc và đâu là mệnh lệnh cần tuân theo.

• EchoLeak trong Microsoft 365 Copilot là một lỗ hổng prompt injection “zero-click”, trong đó email được tạo đặc biệt có thể giúp kẻ tấn công từ xa, không cần xác thực, lấy dữ liệu tổ chức mà Copilot có quyền truy cập.
• Gần đây hơn, các nhà nghiên cứu cũng báo cáo những chuỗi tấn công nhằm vào Copilot Personal, liên quan đến liên kết được tạo đặc biệt, việc lấy dữ liệu từ các ứng dụng kết nối và đầu độc bộ nhớ lâu dài; Microsoft được cho là đã vá ít nhất một lỗi liên quan ở phía máy chủ.
• Với trợ lý lập trình AI, phiên bản tương tự thường xuất hiện dưới dạng rủi ro chuỗi cung ứng trong kho mã: tệp dự án, cấu hình hoặc định nghĩa công cụ độc hại có thể bị diễn giải thành chỉ dẫn. Khi được cấp quyền truy cập hệ thống tệp, shell, mạng hoặc công cụ MCP, tác nhân có thể bị lợi dụng để đánh cắp thông tin xác thực, chạy mã trái phép hoặc tuồn dữ liệu ra ngoài.

Bài học lớn hơn

Mã hóa một payload có thể khiến các bộ lọc chỉ kiểm tra nội dung không nhận ra chỉ dẫn độc hại. Nhưng điểm yếu căn bản mang tính kiến trúc: tác nhân không được biến đầu vào không đáng tin — dù là văn bản hiển thị, bản mã, email, tài liệu, URL, kho mã hay đầu ra của công cụ — thành quyền truy cập dữ liệu riêng tư hoặc quyền thực hiện hành động bên ngoài.

Vì vậy, lớp bảo vệ cần vượt ra ngoài các “hàng rào” ở cấp mô hình. Hệ thống nên thực thi nguồn gốc dữ liệu trong runtime, áp dụng nguyên tắc đặc quyền tối thiểu, giới hạn tham số công cụ, kiểm soát lưu lượng đi ra ngoài mạng và yêu cầu xác nhận có ý nghĩa cho các hành động nhạy cảm.