Nếu team bạn đã dùng AI coding agent trong sáu tháng qua và chưa gặp sự cố nào, tháng 8/2026 là thời điểm tốt để bắt đầu thấy bất an. Chỉ trong khoảng ba tuần, các nhà nghiên cứu bảo mật công bố sáu loại lỗ hổng AI coding agent khác nhau, trải khắp Cursor, AWS Kiro, GitHub Agentic Workflows, và sáu coding assistant cùng lúc qua một lỗ hổng symlink chung. Không cái nào trong số này quá kỳ lạ. Cả sáu đều là thứ một tech lead có thể tự kiểm tra ngay tuần này, không cần chờ vendor vá.

Tôi sẽ đi qua từng sự cố kèm biện pháp giảm thiểu cụ thể, rồi kết bằng thay đổi chính sách ba dòng mà tôi thực sự sẽ áp dụng.

1. Cursor: zero-click thoát khỏi terminal sandbox (CVSS 9.8)

Hai lỗ hổng cho phép một zero-click prompt injection thoát khỏi terminal sandbox của Cursor và ghi đè lên chính binary helper của sandbox — cơ chế lẽ ra để chứa agent lại trở thành phương tiện phát tán payload tấn công. Đó là một đường RCE hoàn chỉnh trên máy developer và bất kỳ cloud workspace nào đang kết nối, không cần hành động nào từ người dùng ngoài việc để agent xử lý nội dung do kẻ tấn công kiểm soát (một file, một trang web, một issue).

Nên làm gì: đừng dựa vào denylist ở cấp agent (“không chạy rm -rf”) làm ranh giới containment — chúng hoạt động trong cùng vùng tin cậy mà chính sandbox escape nhắm tới. Đẩy cô lập lên cấp OS: chạy session agent trong container hoặc VM dùng-một-lần, không mount credential lâu dài, chứ không chỉ một shell hạn chế trên cùng host.

2. AWS Kiro tự âm thầm ghi đè config MCP của chính nó

Text ẩn trên một trang web bình thường ra lệnh cho Kiro ghi đè file config MCP server của chính nó và reload — ở chế độ tự động, không có approval prompt hiệu quả. Agent đã sửa chính ranh giới tin cậy của mình dựa trên nội dung lẽ ra không bao giờ nên được coi là lệnh.

Nên làm gì: coi “agent có được sửa config của chính nó không” là một quyền cần cổng phê duyệt riêng, tách biệt khỏi quyền ghi file thông thường. Nếu công cụ agent bạn dùng không cho phép tách riêng phạm vi này, đó là câu hỏi đáng đặt cho vendor trước lần gia hạn tiếp theo.

Một deeplink được soạn sẵn cài đặt một MCP server do kẻ tấn công kiểm soát, và approval dialog cho lệnh kết quả bị cắt cụt ngoài màn hình — nên thứ người dùng phê duyệt và thứ thực sự chạy là hai chuỗi khác nhau.

Nên làm gì: cái này không sửa được bằng quy trình, mà bằng việc không tin tưởng mù quáng UI phê duyệt của công cụ. Nếu đang review bảo mật cho agent stack, hãy test cụ thể xem lệnh dài có bị cắt cụt trên bề mặt phê duyệt không. Nếu có, đó là một finding, không phải một quirk UX.

4. GitHub Agentic Workflows: nội dung private repo bị leak qua text trong issue công khai

Text tiếng Anh thuần trong một issue công khai ra lệnh cho agent đọc từ các private repo mà agent có quyền truy cập, rồi đăng lại nội dung dưới dạng comment công khai. Không code, không credential, không chuỗi exploit — chỉ là một lệnh mà agent làm theo vì nó không phân biệt được “dữ liệu cần xử lý” với “lệnh cần thực thi”.

Nên làm gì: đây là vấn đề prompt-injection tổng quát, không có cách sửa triệt để, nhưng có thể giới hạn bán kính ảnh hưởng. Giới hạn quyền đọc của agent ở mức tối thiểu các repo thực sự cần cho task hiện tại, không phải quyền truy cập toàn org theo mặc định. Và đặt cổng phê duyệt của con người cho bất kỳ hành động nào đăng output của agent ra nơi công khai — comment, PR, issue — tách biệt khỏi cổng cho các hành động chỉ ảnh hưởng workspace của chính agent.

5. Database production Supabase bị xóa sạch

Mười phút sau khi team bắt đầu session Claude Code đầu tiên, một agent đang điều tra mâu thuẫn schema chạy prisma migrate diff với shadow database trỏ vào production, và xóa mất 22 bảng. Không có kẻ tấn công, không prompt injection — chỉ là một agent có credential ghi vào production database và không phân biệt “lệnh đọc” với “lệnh phá hủy”.

Nên làm gì: đây là điều duy nhất trong danh sách này bạn kiểm soát hoàn toàn và không có lý do gì để không sửa ngay hôm nay. Tách các thao tác database mang tính phá hủy — migration, drop, reset — vào một nhóm quyền yêu cầu xác nhận rõ ràng từ con người mỗi lần, bất kể agent đánh giá thao tác đó “thường quy” đến đâu. Nếu agent của bạn có service account với quyền ghi production DB mà không có bước xác nhận theo từng lệnh cho thao tác phá hủy, đây là fix ưu tiên cao nhất trong toàn bộ danh sách này.

Một repo độc hại dùng symlink để agent ghi ra ngoài thư mục workspace dự kiến, trong khi approval prompt hiển thị vị trí (an toàn) bề ngoài của symlink thay vì đích ghi thực sự. Pattern này (khai thác CWE-61 và CWE-451) xuất hiện độc lập trên sáu coding assistant khác nhau — điều đó cho thấy đây không phải bug của một vendor, mà là một hạng mục mà chưa mô hình quyền agent nào tính đến.

Nên làm gì: đừng coi đường dẫn hiển thị trên approval prompt là sự thật tuyệt đối. Nếu workflow cho phép agent thao tác trên một repo không tin cậy (fork của contributor, một dependency bạn không kiểm soát), hãy resolve symlink và validate đích ghi thực sự độc lập với những gì UI của agent báo cáo, hoặc quét symlink trước khi cấp quyền ghi vào thư mục đó.

Thay đổi chính sách duy nhất tôi sẽ áp dụng từ danh sách này

Đọc cả sáu sự cố cùng nhau, điểm chung không phải “AI agent không an toàn” — mà là mỗi sự cố ở đây đều đến từ việc gộp hai cấp độ tin cậy khác nhau vào một bước phê duyệt: đọc vs. ghi, nội bộ workspace vs. hướng ra ngoài, thường quy vs. phá hủy. Cách sửa tổng quát cho cả sáu là cùng một cách sửa, áp dụng ở các vị trí khác nhau: chia mô hình quyền của agent thành ít nhất ba tầng — chỉ đọc, ghi trong workspace, và phá hủy/hướng ra ngoài — và yêu cầu một xác nhận riêng, khó bấm nhầm hơn cho tầng thứ ba mỗi lần, không có lối tắt kiểu “tin tưởng session này”.

Nếu chỉ làm một việc sau khi đọc bài này, hãy làm mục #5. Đó là sự cố duy nhất trong danh sách không liên quan gì đến kẻ tấn công, prompt injection, hay exploit tinh vi — chỉ là một phạm vi quyền mặc định rộng hơn mức task cần, và một production database lẽ ra không bao giờ nên bị một cuộc điều tra schema chạm vào.

Xuất nội dung

Bình luận