Một Prompt, Một Agent, Cả một Tài khoản AWS: Bên trong AgentCorruption trên Amazon Bedrock AgentCore

Vào ngày 8 tháng 10 năm 2026, Zenity Labs đã công bố AgentCorruption: một chuỗi lỗ hổng trong Amazon Bedrock AgentCore, nền tảng được quản lý của AWS để triển khai và vận hành các tác nhân AI, cho phép một lệnh nhắc bằng ngôn ngữ tự nhiên duy nhất gửi đến một tác nhân công khai chiếm quyền kiểm soát mọi tác nhân AgentCore trong cùng tài khoản và vùng AWS. Nghiên cứu này đã được công bố cùng với một bài nói tại SecTor 2026 ở Toronto, nơi giám đốc nghiên cứu bảo mật của Zenity, Tamir Ishay Sharbat, đã trình bày nó (Dark Reading, 8 tháng 10 năm 2026). Bài viết của chính Zenity, được ghi công cho Sharbat, Lana Salameh, Dmitry Lozovoy và João Donato, mở đầu bằng cơ chế: một tác nhân AgentCore có bất kỳ công cụ nào có thể thực hiện yêu cầu gửi ra ngoài đều có thể bị điều khiển để gọi AWS Instance Metadata Service (IMDS) tại địa chỉ link-local 169.254.169.254, dịch vụ này trả về thông tin xác thực tạm thời cho vai trò thực thi của chính tác nhân đó. Zenity tuyên bố đã xuất những thông tin xác thực đó sang máy của riêng mình và xác nhận chúng hoạt động từ đó. Không có mã CVE nào được chỉ định.

Kho lưu trữ ghi nhận đây là một lỗ hổng bảo mật — thứ được phát hiện, không nhất thiết đã bị khai thác — với mức cao về độ nghiêm trọng, độ tin cậy A, không ghi nhận thiệt hại thực tế nào và có xác nhận về việc AI tham gia. Các bên bất đồng về cách diễn đạt dù họ đồng ý về hành vi: AWS nói với Dark Reading rằng nghiên cứu "mô tả không chính xác hành vi được mong đợi và đã được tài liệu hóa như một lỗ hổng bảo mật."

Chuỗi thực sự là gì

AgentCore đóng gói mỗi agent thành một container và chạy nó theo từng phiên trong Firecracker MicroVM. Bài viết đầu tiên của Zenity trong loạt bài này tái hiện toàn bộ điểm bám trụ thông qua một yêu cầu bằng ngôn ngữ đơn giản gửi tới một agent thử nghiệm được xây dựng bằng Strands SDK, framework agent mã nguồn mở của AWS, vốn đi kèm sẵn công cụ gửi yêu cầu HTTP và công cụ shell. MicroVM đã không giới hạn lưu lượng truy cập tới dịch vụ metadata, nên yêu cầu phát ra từ bên trong instance và IMDS đã trả lời nó. Sau đó, các nhà nghiên cứu đã lần theo các endpoint: tên vai trò IAM, chính thông tin xác thực STS tạm thời, endpoint user-data — thứ trả về ID tài khoản, ARN đầy đủ, URL runtime và Amazon Elastic Container Registry (ECR) URI image của agent — cùng các tag instance bao gồm chuỗi chứng chỉ mTLS, khóa riêng và URL được ký trước tới lưu trữ nội bộ. Zenity cho biết kết quả tương tự cũng đến qua công cụ shell, vì lỗi cô lập nằm ở cấp nền tảng chứ không phải trong bất kỳ công cụ đơn lẻ nào.

Hai chi tiết trong chuỗi đó rất dễ bị đọc lướt qua. Thông tin xác thực không hề bị giới hạn trong sandbox: Zenity đã xuất chúng ra ngoài AgentCore và thực hiện một lệnh gọi danh tính AWS mà kết quả trả về là vai trò giả định của agent. Và vai trò bị đánh cắp đó có thể kéo container image, đó là cách mã nguồn của các agent trở nên có thể đọc được — bài đăng của Zenity lưu ý rằng các image thường chứa khóa hardcode, token còn sót lại và cấu hình lẽ ra không bao giờ nên được đóng gói sẵn, và rằng một image được kéo về chính là bản đồ của logic nghiệp vụ bên dưới.

Vai trò mặc định là nơi một điểm bám trụ trở thành một tài khoản

Lỗ hổng thứ hai, được báo cáo riêng, là vai trò thực thi mà AgentCore gán cho các agent theo mặc định không được giới hạn phạm vi cho một agent. Zenity mô tả các quyền vươn tới mọi tài nguyên AgentCore trong tài khoản và khu vực, bao gồm bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:ListEvents, bedrock-agentcore:CreateEvent, bedrock-agentcore:DeleteEvent và, ở đầu cuối thông tin xác thực của chuỗi, bedrock-agentcore:GetResourceApiKey và secretsmanager:GetSecretValue.

Tính liệt kê đã biến những wildcard đó thành một danh sách mục tiêu. Zenity đã sử dụng quyền logs:DescribeLogGroups của role, vì AgentCore đặt tên nhóm log CloudWatch của mỗi agent là /aws/bedrock-agentcore/runtimes/{AGENT_ID}-{ENDPOINT_NAME}, và suy ra ID agent từ những tên nhóm log đó. Tên repository ECR tuân theo một quy ước mà các nhà nghiên cứu quan sát được — bedrock-agentcore-<agent_name> — nên có thể kéo mọi image của agent trong vùng đó. Tài nguyên bộ nhớ cũng được tìm thấy theo cách tương tự, từ mẫu nhóm log /aws/vendedlogs/bedrock-agentcore/memory/APPLICATION_LOGS/{MEMORY_ID}, và các quyền ListActors, ListSessions và ListEvents của role đã tạo ra các định danh actor và session cần thiết để đọc nội dung hội thoại.

Bài viết của Zenity đưa ra một minh chứng cụ thể về di chuyển ngang: xâm nhập qua một agent hướng ra công chúng, phát hiện các công cụ của một billing_agent trong cùng khu vực, nhận thấy một tệp có tên billing.json và trích xuất nó qua một công cụ đọc tệp. Thông cáo báo chí mô tả cùng kịch bản bằng những thuật ngữ chung — kẻ tấn công xâm nhập qua một agent dịch vụ khách hàng hướng internet có thể di chuyển đến một agent tài chính nội bộ được triển khai trong cùng khu vực, gọi nó, và truy cập dữ liệu, công cụ, thông tin xác thực liên quan và các cuộc trò chuyện riêng tư của nó.

Ký ức là phần đã tồn tại lâu hơn lời nhắc

AgentCore Memory giữ chính cuộc hội thoại làm bộ nhớ ngắn hạn và lưu trữ các bản ghi được trích xuất làm bộ nhớ dài hạn, sử dụng các chiến lược có tên là SEMANTIC, USER_PREFERENCE, SUMMARIZATION và EPISODIC. Zenity đã dùng CreateEvent để ghi các sự kiện hội thoại vào tài nguyên bộ nhớ của các agent khác. Bài đăng của họ cẩn trọng về những gì nguyên thuỷ đó có thể và không thể làm: CreateEvent không cho phép bên gọi chọn một không gian tên dài hạn hay ghi đè trực tiếp lên một bản ghi — các chiến lược đã được cấu hình của bộ nhớ đích quyết định những gì được trích xuất và nơi nó được lưu. Zenity cũng mô tả DeleteEvent được dùng để xoá các sự kiện kết quả công cụ khiến một agent rút ra kết luận sai từ dữ liệu bị thiếu, và để xoá dấu vết bằng cách xoá sự kiện đã cấy một bộ nhớ.

Thứ mà primitive ghi tạo ra chính là sự duy trì hiện diện. Bản trình diễn của Zenity đã cấy vào một yêu cầu rằng tác nhân phải tải một trang do các nhà nghiên cứu kiểm soát trước khi trả lời, và tuân theo nội dung của trang đó — một endpoint command-and-control mà các chỉ dẫn có thể bị thay đổi mà không cần cấy thêm một bộ nhớ nào khác. Kênh đó sau đó đã mang nội dung hội thoại ra ngoài: bài viết mô tả việc tác nhân gửi tin nhắn của người dùng và các câu trả lời của chính nó đến một endpoint thu thập, và nêu rằng các quyền bộ nhớ trên vai trò mở rộng khắp tài khoản và khu vực chứ không chỉ áp dụng cho tác nhân bị xâm phạm. Một video công bố kèm nghiên cứu cho thấy người dùng đang tiếp tục cuộc trò chuyện trong khi nội dung đó đến được máy chủ của các nhà nghiên cứu.

Thông tin xác thực ngoài AWS

Bài viết cuối cùng trong loạt bài này khép lại vòng lặp về các công cụ được kết nối. AgentCore Identity và Outbound Auth lưu trữ thông tin xác thực của công cụ dưới dạng bí mật trong AWS Secrets Manager, với tên được tạo từ tên nhà cung cấp và một mẫu cố định như bedrock-agentcore-identity!default/apikey/{provider_name}. Zenity đã khôi phục tên nhà cung cấp bằng cách thu thập mã nguồn của agent mà nó đã kéo về từ ECR, và khôi phục những tên khác bằng cách brute force: nó báo cáo rằng hậu tố năm ký tự mặc định được tạo phía máy khách từ các chữ số và chữ cái thường, tạo ra 2 x (10+26)^5 = 120,932,352 tổ hợp trên hai loại nhà cung cấp. Với tốc độ yêu cầu mà nó có thể duy trì đối với Secrets Manager, Zenity cho biết một lần liệt kê đầy đủ mất vài giờ — lâu hơn thời gian tồn tại của thông tin xác thực STS — vì vậy nó đã xây dựng một vòng lặp truy vấn lại điểm cuối IMDS của agent để lấy thông tin xác thực mới khi những thông tin cũ hết hạn. Zenity nói thêm rằng các biến môi trường có thể đọc được thông qua điểm cuối user-data của metadata với mọi tên đều được gắn tiền tố CONTAINER_ENV_, bao gồm cả khóa mà agent dùng để xác thực với nhà cung cấp mô hình của nó, và rằng việc gọi mỗi agent được phát hiện với một câu lệnh phù hợp đã thu hoạch những giá trị đó ở quy mô lớn.

Đã được xác lập, và bị tranh chấp vì một điểm kỹ thuật.

Điều được xác lập thì hẹp và cụ thể. Các agent của AgentCore có thể truy cập IMDS và nhận thông tin xác thực tạm thời của vai trò thực thi của chính chúng — AWS không phản đối điều này, mà mô tả trong tuyên bố của mình là “được ghi nhận và nằm trong dự kiến”. Vai trò thực thi mặc định mang các quyền được giới hạn theo tài khoản và khu vực, chứ không phải theo một agent cụ thể; AWS từ đó đã thay đổi nó, và Zenity nói rằng thử nghiệm của chính họ đã xác nhận việc thu hẹp này. Nghiên cứu này là một minh chứng, không phải một chiến dịch được quan sát: Sharbat nói với Dark Reading rằng Zenity chưa thấy bằng chứng nào cho thấy lỗ hổng bị khai thác trong thực tế trước khi có bản sửa, phần nào do khó xác định những tổ chức nào chạy agent trên AgentCore, và nói thêm rằng ông “100% chắc chắn có những cách để làm điều đó”.

Điều đang gây tranh cãi là liệu có nên gọi bất kỳ phần nào trong đó là lỗ hổng hay không. Tuyên bố của AWS, như được đưa cho Dark Reading và The Next Web, viết: "AWS biết về nghiên cứu đã công bố liên quan đến Amazon Bedrock AgentCore, trong đó mô tả sai lệch hành vi được mong đợi và đã được ghi nhận tài liệu như một lỗ hổng. Một agent chỉ có thể truy cập tài nguyên trong một tài khoản AWS khác nếu nhà phát triển cấp quyền một cách rõ ràng trên cả vai trò thực thi của agent lẫn tài nguyên đích." Tuyên bố của AWS được sao lại trong chính các bài đăng của Zenity vẫn giữ nguyên nội dung cốt lõi của câu đầu tiên — "hành vi được mô tả là đã được ghi nhận tài liệu và nằm trong dự kiến" — và bổ sung rằng khách hàng chỉ nên cấp cho vai trò thực thi những quyền mà agent của họ cần. Có hai điểm nằm dưới sự bất đồng này. AWS định hình ranh giới theo nghĩa truy cập vào tài nguyên trong một tài khoản AWS khác, trong khi phát hiện của Zenity liên quan đến các agent bên trong một tài khoản và một vùng AWS duy nhất; và các vai trò mà Zenity mô tả đến từ mặc định của nền tảng chứ không phải từ việc khách hàng tự tay viết một chính sách.

Việc The Next Web đính chính bài viết của chính mình là điều đáng ghi lại, vì nó cho thấy tuyên bố ấy đã được siết chặt bởi một ai đó không phải là các nhà nghiên cứu. Ban đầu, trang này đăng một tiêu đề nói rằng các nhà nghiên cứu đã chiếm quyền kiểm soát mọi agent AgentCore trong một khu vực, rồi sau đó đính chính tiêu đề đó; phiên bản đính chính nêu rằng nghiên cứu chỉ bao gồm các agent trong phạm vi một tài khoản AWS và một khu vực duy nhất, đồng thời lưu ý rằng tiêu đề trước đó đã nêu tuyên bố của các nhà nghiên cứu như một sự thật.

Dòng thời gian công bố

Zenity đã nộp hai báo cáo thay vì một, và chúng được phản hồi theo những cách khác nhau. Báo cáo về quyền truy cập IMDS được gửi vào 25 tháng 12 năm 2025; AWS đã đóng nó vào 12 tháng 4 năm 2026 với trạng thái "informative", ghi rằng AgentCore chỉ sử dụng IMDSv2 kể từ 14 tháng 2 năm 2026, với các agent mới được triển khai khởi chạy theo cách đó. Sự điều chỉnh đó có ý nghĩa quan trọng đối với các chi tiết cụ thể của nghiên cứu này, bởi vì IMDSv2 yêu cầu một session token trong mỗi yêu cầu và phá vỡ cách truy xuất đơn giản không xác thực mà các nhà nghiên cứu đã dùng để lấy thông tin xác thực. Báo cáo thứ hai, về vai trò mặc định và phạm vi ảnh hưởng của nó, được gửi vào 12 tháng 1 năm 2026. AWS đã thông báo cho Zenity vào 25 tháng 2 năm 2026 rằng nhóm đang xử lý vấn đề này trong khi vai trò vẫn giữ nguyên như cũ; Zenity đã xem xét lại vai trò vào 22 tháng 6 năm 2026 và thấy các quyền của nó không thay đổi. Một lần xem xét cuối cùng vào 29 tháng 9 năm 2026 cho thấy vai trò đã được thu hẹp đáng kể, và thông cáo báo chí của Zenity nêu rằng việc loại bỏ bao gồm quyền gọi các agent khác, đọc các cuộc trò chuyện riêng tư và truy cập các bí mật trong AWS Secrets Manager, cùng với các quyền khác cũng bị hạn chế đáng kể. Các bài đăng của chính Zenity lưu ý rằng AWS kể từ đó đã đặt IMDSv2 làm mặc định cho các triển khai AgentCore và rằng hai bên đã hợp tác trong suốt quá trình này.

Điều gì chưa được biết

Zenity chưa công bố có bao nhiêu tác nhân (agent) hoặc tổ chức đã chạy với vai trò mặc định trong khoảng thời gian giữa thay đổi IMDSv2 hồi tháng Hai và đợt thu hẹp phạm vi vào cuối tháng Chín, và không có nguồn nào được trích dẫn nêu rằng bất kỳ dữ liệu khách hàng nào bị lộ ra ngoài môi trường của chính các nhà nghiên cứu. Theo AWS (được Zenity dẫn lại), thay đổi IMDSv2 áp dụng cho các tác nhân được triển khai sau ngày 14 tháng 2 năm 2026; còn ý nghĩa của nó đối với các tác nhân được triển khai trước ngày đó thì không được nêu trong các nguồn được xem xét ở đây. Hồ sơ lưu trữ không ghi nhận thiệt hại thực tế nào, và các nguồn củng cố cách hiểu đó khi mô tả một cuộc trình diễn và khi AWS phản bác nhãn "lỗ hổng" thay vì báo cáo một sự cố của chính mình.

Sharbat nói với Dark Reading rằng Zenity hiện đang kiểm tra các nền tảng đám mây khác để tìm các vấn đề truy cập metadata tương tự, và rằng công ty chưa nêu tên chúng. Điểm mấu chốt ông nêu là về quyền truy cập chứ không phải về dịch vụ metadata: "Ngay cả khi ai đó truy cập được, phạm vi ảnh hưởng sẽ nhỏ hơn nhiều."

Lý do bản ghi này được lưu giữ

AgentCorruption không đáng chú ý vì các endpoint metadata là một ý tưởng mới. Sharbat đã hướng khán giả SecTor đến vụ vi phạm Capital One năm 2019, nơi một SSRF truy cập được IMDS và biến thành thông tin xác thực bị đánh cắp, và mô tả đó là một thất bại về nguyên tắc đặc quyền tối thiểu cùng loại. Điều mới là tác nhân thực hiện việc truy xuất. Yêu cầu tạo ra một danh tính AWS được thực hiện bởi một tác nhân AI đang làm điều nó được yêu cầu, bằng ngôn ngữ thông thường, thông qua một công cụ mà nó được cấp để có thể hữu ích — và tác nhân đã chuyển tiếp câu trả lời trở lại. Hai điều kiện đã biến đó thành một vấn đề trên toàn tài khoản là một endpoint metadata mà sandbox không chặn và một vai trò mặc định rộng hơn cả tác nhân nắm giữ nó.

Toàn bộ nghiên cứu, bao gồm loạt bài kỹ thuật gồm năm phần và video minh họa, được liên kết từ thông cáo báo chí ngày 8 tháng 10 năm 2026 của Zenity. Bản ghi này là một mục trong số các sự cố tác nhân được ghi nhận trong kho lưu trữ sự cố AI, nơi mỗi mục đều mang nguồn riêng, mức độ nghiêm trọng, cấp độ tin cậy và cờ tranh chấp — những trường dữ liệu giúp có thể phân biệt một tranh chấp giữa nhà cung cấp về cách diễn đạt, như trường hợp ở đây, với một phát hiện gây tổn hại đang bị tranh cãi.

Đây là một bản ghi, do những người khác nghiên cứu và báo cáo, và được trích dẫn ở đây để ghi công họ. Các sự cố agent được ghi nhận khác, mỗi sự cố có nguồn riêng, mức độ nghiêm trọng, xếp hạng độ tin cậy và cờ tranh chấp, nằm trong kho lưu trữ sự cố AI — vì vậy, một mặc định của nền tảng biến một prompt thành điểm bám trụ trên toàn tài khoản có thể được đọc bên cạnh những gì đã thực sự xảy ra ở nơi khác.