Bảng điều khiển Agent Vibe-Coded của METR đã vô hiệu hóa đăng nhập của chính nó, và một kẻ tấn công đã tiêu tốn 600.000 USD tín dụng mô hình

Vào tháng 3 năm 2026, ai đó đã lấy một khóa API cho tài khoản public-models của METR từ một phiên bản Amazon EC2 cá nhân của một nhà nghiên cứu và dùng nó trong ba tuần. METR — Model Evaluation and Threat Research, tổ chức phi lợi nhuận chuyên đo lường mức độ các tác nhân AI đạt được trong những nhiệm vụ dài hạn — ước tính giá trị thương mại của lượng tín dụng đã bị tiêu thụ vào khoảng 600.000 USD. Khóa này không bị lừa đảo trực tuyến từ một con người: kẻ tấn công đã thúc đẩy một tác nhân đang chạy trên bảng điều khiển được viết theo kiểu vibe-coding của nhà nghiên cứu trao khóa API của nhà cung cấp mô hình cho mình, rồi thêm một khóa SSH để có thể quay lại. METR đã công bố sự cố vào 31 tháng 8 năm 2026, và hồ sơ mang mức độ nghiêm trọng cao của kho lưu trữ cùng xếp hạng độ tin cậy A. Công bố này là một hồ sơ trong kho lưu trữ sự cố AI, nơi lưu giữ toàn bộ tập hồ sơ, các nguồn của nó và những mục lân cận trong loạt bài này.

Hồ sơ thực sự nói gì

Kho lưu trữ phân loại đây là một sự cố đã xảy ra, không phải là công bố về một điểm yếu lý thuyết: mức độ nghiêm trọng cao, độ tin cậy A, không bị tranh cãi, với tổn hại thực tế đã được ghi nhận và đã xác nhận có sự tham gia của AI. Thẻ loại là CRED, khu vực là Hoa Kỳ, và ngày chỉ được ghi đến tháng — kho lưu trữ biết vụ trộm đã xảy ra vào tháng 3 năm 2026 và không khẳng định ngày cụ thể, METR cũng vậy.

Tác hại cần một lưu ý, và METR đưa ra lưu ý đó. Các khoản tín dụng đã được nhà phát triển mô hình cấp cho METR miễn phí, vì vậy $600,000 là giá trị của những gì đã được tiêu thụ chứ không phải số tiền rời khỏi một tài khoản. Phần standfirst của The Register nêu cùng luận điểm một cách thẳng thừng hơn: nhà cung cấp mô hình đã trao các khoản tín dụng cho METR, và một khách hàng thực sự trả tiền sẽ không may mắn như vậy. Infosecurity Magazine đưa tin về con số này theo cùng cách, như giá trị thương mại chứ không phải tổn thất tài chính trực tiếp.

Bài đăng của METR đề cập đến hai sự cố, không phải một. Chiến dịch tháng 5 năm 2026 được mô tả riêng ở phần dưới; việc đánh cắp khóa và ba tuần chi tiêu là sự kiện tháng 3, và đó là chủ đề của bài viết này.

Lỗi nằm ở phần đăng nhập, không phải ở mô hình.

Một nhà nghiên cứu của METR không có quyền truy cập dữ liệu nhạy cảm đã chạy các agent trên một instance EC2 cá nhân được cố ý mở cho truy cập công khai, phía sau lớp xác thực Google. Instance này mang một API key của tài khoản truy cập chung của METR — tài khoản dùng cho các mô hình công khai, được METR xếp vào danh mục dữ liệu ít nhạy cảm thứ hai. Ứng dụng điều phối bao quanh các agent đó được viết theo kiểu vibe-coding, và nó chứa thứ mà METR gọi là lỗ hổng fail-open đã âm thầm vô hiệu hóa cơ chế xác thực.

Fail-open đáng để dịch, vì nó gói trọn toàn bộ sự cố trong hai từ. Một bước kiểm tra đăng nhập có hai cách để sai: nó có thể từ chối một người dùng hợp lệ, hoặc nó có thể chấp nhận bất kỳ ai khi chính bước kiểm tra bị hỏng. Fail-open nghĩa là trường hợp thứ hai — khi bước xác thực gặp lỗi hoặc bị bỏ qua, ứng dụng coi yêu cầu đó là được phép chứ không phải bị từ chối. Không có cảnh báo nào được đưa ra. Trong bản ghi của METR, kết quả là một hệ thống nằm trên internet công cộng trong vài ngày với cửa trước mở toang và không có dấu hiệu nào cho thấy bất cứ điều gì đã thay đổi.

METR không nêu tên công cụ điều phối hoặc framework mà dashboard được xây dựng bằng, không công bố mã nguồn, và không nói việc tích hợp xác thực đã thất bại theo hướng nào. Điều mà bài đăng xác lập là sai lầm kiến trúc nằm bên dưới lỗi đó: một thông tin xác thực cho tài khoản mô hình của tổ chức đã hiện diện trên hạ tầng mà METR không kiểm soát, trong một ứng dụng mà một nhà nghiên cứu đã tự triển khai.

Cách chiếc chìa khóa rời khỏi tòa nhà

Việc METR phỏng đoán lại cách tiếp cận của kẻ tấn công rõ ràng chỉ là một nghi ngờ, chứ không phải là một phát hiện, và đây chính là tuyên bố chưa được chứng minh thú vị nhất trong bản công bố. Bài đăng cho biết METR nghi ngờ rằng kẻ tấn công đã tìm ra phiên bản dịch vụ đó bằng cách duyệt qua các trang web mới đăng ký gần đây — danh sách minh bạch chứng chỉ được nêu làm ví dụ — để tìm những trang được vibe-coded có chứa các từ khóa ám chỉ các dự án LLM hoặc agent, nhằm thu thập các khóa API của nhà cung cấp mô hình bị để lộ.

Nhật ký minh bạch chứng chỉ vốn công khai theo thiết kế: mọi chứng chỉ được cấp cho một trang được tin cậy công khai đều được ghi lại, vì vậy một tên máy chủ mới sẽ xuất hiện trong nguồn cấp dữ liệu có thể tìm kiếm chỉ trong vài phút sau khi đi vào hoạt động. Việc lọc nguồn cấp dữ liệu đó để tìm các tên chứa thuật ngữ agent hoặc model rất rẻ, không cần truy cập vào mục tiêu và tạo ra danh sách các triển khai mới có thể chưa được ai xem xét. Được đọc như một kỹ thuật săn tìm, nó biến hành vi thông thường là công bố một bản demo thành một tín hiệu.

Khi đã vào được bên trong, kẻ tấn công không cần phải đánh cắp bí mật từ hệ thống tệp. Chúng đã dùng câu lệnh trực tiếp yêu cầu tác nhân tiết lộ khóa API của nhà cung cấp mô hình, một câu đáng để dừng lại một chút: tác nhân đã có thông tin xác thực đó trong ngữ cảnh của mình và có thể bị thuyết phục để in nó ra. Sau đó, kẻ tấn công đã thêm một khóa SSH để duy trì quyền truy cập, để việc vá lỗ hổng xác thực không đẩy được chúng ra, và yên vị trong ba tuần suy luận trên các mô hình có sẵn công khai.

Nhà phát triển mô hình không được nêu tên — không phải bởi METR, và không phải bởi The Register, Dark Reading, Infosecurity Magazine hay The Hacker News trong các bài đưa tin của họ về vụ tiết lộ. Không có CVE nào được phát hành, vì không có lỗ hổng sản phẩm nào là vấn đề. Chưa có báo cáo về việc bắt giữ, buộc tội hoặc quy kết cho một nhóm có tên.

Vì sao ba tuần sử dụng bất thường lại trông bình thường

METR trả lời trực tiếp câu hỏi hiển nhiên, và câu trả lời chính là phần mà các tổ chức khác nên đọc kỹ hai lần. Tổ chức phi lợi nhuận này vận hành các đánh giá quy mô lớn, nghĩa là tổ chức đã quá quen với số lượng token rất lớn và với một chuỗi lỗi giới hạn tốc độ và API kỳ lạ, nhiều lỗi trong số đó là giả. Một sự tăng vọt trong lưu lượng mô hình tự nó không phải là tín hiệu.

Ba lỗ hổng cụ thể đã biến sự quen thuộc đó thành ba tuần im lặng. Bảng điều khiển sử dụng nội bộ của METR không hiển thị dữ liệu về các yêu cầu bị giới hạn tốc độ trên tất cả người dùng, ngay cả khi những yêu cầu đó đang diễn ra. Vì các token là miễn phí, không có hóa đơn và do đó không có mức trần chi tiêu tự nhiên nào bị kích hoạt. Và vào thời điểm đó, METR cho biết không có cách nào để đặt giới hạn chi tiêu lên một loại khóa như vậy. Một tổ chức trả theo giá niêm yết với mức trần cứng sẽ đâm vào tường trong vài giờ; một tổ chức có tín dụng được tặng và không có trần thì không có gì để đâm vào.

Những gì đã không được lấy

Phân loại dữ liệu của METR trải từ tài liệu đã công bố cho đến quyền truy cập mô hình chung, quyền truy cập mô hình nhạy cảm và thông tin kinh doanh có độ nhạy cảm cao. Nhà nghiên cứu liên quan không có quyền truy cập vào hai hạng mục cao nhất, và METR tuyên bố rằng theo hiểu biết tốt nhất của mình, không có dữ liệu nào từ các hạng mục đó bị truy cập do bất kỳ sự cố nào trong hai sự cố.

Ngoài chiếc khóa duy nhất, METR cho biết công tác điều tra pháp chứng thủ công và có agent hỗ trợ không phát hiện dấu hiệu xâm phạm nào, và rằng cố vấn bảo mật của mình, Calif, đã xác thực các phát hiện và tự thực hiện đánh giá xâm phạm của riêng mình. Đó là một cơ chế kiểm soát có ý nghĩa — một công ty bên ngoài kiểm tra bản tường trình thay vì chấp nhận nó — nhưng nó không độc lập với METR, bên đã thuê và trả tiền cho Calif. Chưa có bên thứ ba nào công bố đánh giá pháp chứng của riêng mình về sự cố này.

METR đã làm gì khi nhận ra

Trình tự ứng phó được nêu trong bài đăng là cụ thể. METR xác định rằng sự gia tăng đột biến về mức sử dụng không phải là một phần của một đợt đánh giá, truy vết nó đến phiên bản cá nhân đã bị xâm nhập, thu hồi toàn bộ quyền truy cập của nhà nghiên cứu, dừng và tạo ảnh của phiên bản đó, luân chuyển mọi thông tin xác thực có trên đó, đồng thời tạo ảnh và xóa sạch laptop của nhà nghiên cứu. Tổ chức này đã cảnh báo công ty AI đối tác có các khoản tín dụng đang bị tiêu dùng và cập nhật liên tục cho công ty đó trong suốt quá trình ứng phó.

METR không giải thích lý do đằng sau việc xóa dữ liệu laptop, và đây là bước duy nhất trong trình tự vượt ra ngoài việc thu hồi quyền truy cập vào chính instance — cách lý giải hợp lý là cùng nhà nghiên cứu đó đã xử lý thông tin xác thực từ một máy trạm mà kẻ tấn công có thể tiếp cận, và tạo ảnh đĩa rồi dựng lại là cách rẻ để chắc chắn về một cỗ máy.

Điều gì đã thay đổi sau đó?

METR liệt kê bốn thay đổi gắn với sự cố này:

• Các chính sách bảo mật dành cho nhân viên và nhà thầu đã được làm rõ và mở rộng, cụ thể là xoay quanh việc đặt thông tin xác thực hoặc dữ liệu của METR trên các hạ tầng và thiết bị không thuộc sở hữu của METR.

• Quy trình đánh giá bảo mật chính thức hiện áp dụng cho bất kỳ nhà nghiên cứu nào công khai triển khai một ứng dụng.

• Đã mở rộng phạm vi giám sát, đồng thời triển khai công việc loại bỏ các cảnh báo nhiễu — những cảnh báo khiến người ứng phó quen dần với việc phớt lờ chúng.

• Cảnh báo chi tiêu đã được thêm vào các khóa ở nơi nhà cung cấp cho phép điều đó — cách nói dè dặt này có ý nghĩa, vì điểm trước đó trong bài viết là một số khóa loại này không thể đặt giới hạn vào thời điểm đó.

Thông báo cũng liệt kê các công việc trên toàn tổ chức: tuyển dụng một trưởng bộ phận an ninh và lên kế hoạch cho một kỹ sư an ninh toàn thời gian, tăng cường sự tham gia của Calif, đóng cửa hạ tầng cũ vốn đang mở rộng bề mặt tấn công, thực hiện các đợt đánh giá mô hình hóa mối đe dọa định kỳ, mở rộng ghi nhật ký trên các truy vấn cơ sở dữ liệu và việc sử dụng API, giám sát việc sử dụng khóa API bất thường, triển khai thêm phần mềm bảo mật cho điểm cuối và máy chủ, rút ngắn thời hạn của thông tin xác thực và giảm phạm vi quyền. METR ghi nhận các biện pháp đó là chính xác tính đến 30 tháng 7 năm 2026 và cho biết chúng có thể thay đổi — một lưu ý đáng giữ lại, vì điều đó có nghĩa bài đăng mô tả một trạng thái khoảng bốn tháng sau vụ đánh cắp và khoảng một tháng trước khi công bố.

Sự cố khác trong cùng bài đăng

Công bố của METR ghép vụ đánh cắp khóa với một sự kiện thứ hai, riêng biệt vào đầu tháng 5 năm 2026, và hai sự việc rất dễ bị nhầm lẫn với nhau. Trong sự kiện đó, METR được cảnh báo rằng mình đang bị những kẻ tấn công nhắm mục tiêu, những kẻ có vẻ có động cơ tài chính và có thể đang nhắm đến quyền truy cập mô hình tiên phong; METR đã theo dõi chúng thăm dò cơ sở hạ tầng công khai của mình, sử dụng nhiều agent để tự động hóa việc phát hiện lỗ hổng, bao gồm nhồi thông tin xác thực nhắm vào các nhà cung cấp dịch vụ xác thực, thử cấp token OAuth, quét các dịch vụ mới được triển khai và lừa đảo phishing nhắm vào nhân viên.

Trong cùng khoảng thời gian đó, {{1}}METR{{/1}} đã vô tình để lộ một {{2}}cơ chế truy vấn SQL chỉ đọc{{/2}} thông qua trình xem bản ghi công khai của mình. Các truy vấn mặc định được giới hạn trong dữ liệu công khai, nhưng một lỗi có thể bị lợi dụng nhắm vào dữ liệu đánh giá chưa công bố, và một số đầu ra mô hình nhạy cảm đã bị nạp nhầm vào cơ sở dữ liệu đó. Một nhà nghiên cứu bảo mật độc lập đã phát hiện lỗ hổng và báo cáo một cách có trách nhiệm; {{3}}METR{{/3}} đã đưa {{4}}API{{/4}} ngừng hoạt động và trả tiền thưởng. Theo {{5}}lời kể của METR{{/5}}, những kẻ tấn công đã đi qua điểm cuối đó trong chiến dịch rộng hơn của chúng nhưng không có dấu hiệu nào cho thấy chúng tìm ra lỗ hổng khai thác hoặc tiếp cận được dữ liệu không công khai — một kết luận mà {{6}}METR{{/6}} đánh giá là “{{7}}rất khó xảy ra{{/7}}” trong một chú thích thay vì bằng không.

Điều gì đã được xác lập, và điều gì chưa.

Đã được xác lập. METR đã công bố thông tin tiết lộ vào ngày 31 tháng 8 năm 2026 và mô tả vụ trộm hồi tháng Ba, sự cố xác thực fail-open, việc tiết lộ khóa qua trung gian agent, khóa SSH, khoảng thời gian ba tuần và mức định giá khoảng 600.000 USD. Bốn trang tin bảo mật — The Register, Dark Reading, Infosecurity Magazine và The Hacker News — đã đưa tin về cùng tường thuật đó trong vòng một ngày, và không nguồn nào trong số họ phản bác lại — dù cả bốn đều dựa trên cùng bài đăng của METR chứ không dựa trên bất kỳ quyền truy cập độc lập nào vào nhật ký của METR hay hóa đơn của nhà cung cấp.

Chưa được xác lập. $600,000 là ước tính của chính METR về khoản tín dụng được quyên góp; chưa có hóa đơn, sao kê của nhà cung cấp hay định giá độc lập nào được công bố, và vì không có khoản nào được thanh toán, nên không có giao dịch nào để đối chiếu. Phương pháp truy tìm dựa trên minh bạch chứng chỉ được METR coi là một nghi vấn và chưa được bất kỳ bên nào có khả năng quan sát hoạt động của kẻ tấn công xác nhận. Danh tính kẻ tấn công, danh tính nhà cung cấp mô hình và ngày chính xác trong tháng 3 đều chưa được biết hoặc chưa được công bố. Và tuyên bố rằng không có dữ liệu nhạy cảm nào bị truy cập dựa trên phân tích pháp chứng của METR và đánh giá của chuyên gia tư vấn của METR, chứ không dựa trên một cuộc kiểm toán độc lập.

Cũng cần nói chính xác về cụm từ “suýt xảy ra sự cố”. METR mô tả cả hai sự cố theo cách đó, còn Dark Reading phản bác cách diễn đạt ấy đối với sự kiện tháng Ba, với lý do rằng đó là một vụ xâm nhập thành công, trong đó kẻ tấn công đã thiết lập khả năng tồn tại lâu dài và ở trong một thông tin xác thực bị đánh cắp suốt ba tuần. Cả hai cách mô tả đều chính xác về những khía cạnh khác nhau: hậu quả đã được kiểm soát, và vụ xâm nhập là có thật.

Dark Reading cũng đưa ra đánh giá bên ngoài sắc bén nhất trong báo cáo của mình. Jacob Krell, giám đốc cấp cao phụ trách giải pháp AI an toàn và an ninh mạng tại Suzu Labs, nói với hãng rằng METR là một trong những tổ chức trưởng thành hơn về bảo mật trong lĩnh vực AI, với chứng nhận SOC 2 Type I, một chuyên gia tư vấn bảo mật riêng và hệ thống phân loại dữ liệu bốn cấp, và rằng các sự cố vẫn xảy ra thông qua những cách thức thông thường — một lỗ hổng xác thực fail-open trên một instance cloud cá nhân. Krell lập luận rằng nếu một tổ chức ở mức độ trưởng thành đó vẫn bị đánh trúng bởi các biện pháp vệ sinh cloud và thông tin xác thực cơ bản, thì điều đó nói lên điều gì đó về mức sàn của bảo mật trong ngành AI chứ không phải mức trần. Dark Reading lưu ý rằng METR đã không phản hồi yêu cầu bình luận của mình về câu chuyện này.

Vì sao chìa khóa của người đánh giá không phải là chuyện nhỏ

Vai trò của METR là lý do hồ sơ này nằm trong một kho lưu trữ an toàn thay vì một bản tổng hợp về vệ sinh đám mây. Dark Reading đưa tin rằng tổ chức này có hợp tác với hầu hết các nhà cung cấp mô hình lớn phương Tây, gồm OpenAI, Anthropic, Google, Meta và Amazon, còn The Register lưu ý rằng METR đã làm việc với OpenAI để điều tra cách các tác nhân của OpenAI truy cập máy chủ Hugging Face vào đầu năm 2026. Một đơn vị đánh giá nắm giữ kết quả chưa được công bố, bản ghi chưa được công bố và quyền truy cập vào các mô hình trước khi phát hành; thông tin xác thực của đơn vị này trên thực tế là một phần trong vành đai bảo mật của khách hàng.

Sự cố tháng Ba không chạm tới bất kỳ điều nào trong số đó. Nó chạm tới một khóa cho các mô hình công khai, trên một phiên bản cá nhân, phía sau một đăng nhập đã âm thầm ngừng hoạt động — chính vì thế nó là một bản ghi hữu ích. Thất bại này không đòi hỏi một cuộc tấn công mới lạ vào một mô hình. Nó đòi hỏi một bản triển khai demo mà không ai xem xét, một kiểm tra xác thực mặc định là có khi nó hỏng, và một hệ thống kế toán trong đó mức sử dụng khổng lồ là trạng thái bình thường của thế giới.