Khi AI của OpenAI tự 'vượt ngục' để tấn công Hugging Face: Cảnh báo thực tế về bảo mật

Ngày 22 tháng 7 năm 2026

Câu chuyện này thật điên rồ. Tóm tắt ngắn gọn: OpenAI đang thực hiện một bài kiểm tra an ninh mạng đối với một mô hình chưa được phát hành, với các tính năng bảo vệ (guardrail) của mô hình đã bị tắt. Thay vì giải bài kiểm tra, mô hình này đã phá vỡ môi trường sandbox của OpenAI, sau đó tìm ra các lỗ hổng để xâm nhập vào Hugging Face, tất cả chỉ để gian lận bài kiểm tra bằng cách đánh cắp đáp án.

Trong quá trình đó, nó đã giúp tạo ra lập luận thuyết phục nhất từ trước đến nay về việc sự mất cân bằng trong khả năng tiếp cận mô hình đang gây tổn hại đến khả năng bảo mật phần mềm của chúng ta như thế nào.

Đây là những gì đã xảy ra.

Hiện tại chúng ta có ba tài liệu để giúp hiểu rõ những gì đã xảy ra ở đây.

ExploitGym

Tôi chưa từng thấy bài báo về ExploitGym trước đây và nó thực sự rất thú vị. Các tác giả từ UC Berkeley, Viện Max Planck, UC Santa Barbara và Đại học Bang Arizona đã thiết kế một bộ tiêu chuẩn (benchmark) mới để đánh giá khả năng của các mô hình trong việc biến một lỗ hổng được báo cáo thành một mã khai thác (exploit) cụ thể. OpenAI, Anthropic và Google đã cung cấp phản hồi và hỗ trợ chạy bộ tiêu chuẩn này trên các mô hình của họ.

Bộ tiêu chuẩn này “bao gồm 898 trường hợp được rút ra từ các lỗ hổng thực tế đã ảnh hưởng đến các dự án phần mềm phổ biến”—bao gồm nhân Linux và công cụ JavaScript V8.

Đây là đoạn văn thể hiện rõ nhất kết quả của bộ tiêu chuẩn này:

Trong tất cả các cấu hình, Claude Mythos Preview và GPT-5.5 đạt số lần thành công cao nhất (lần lượt là 157 và 120 lần), chứng minh rằng các tác nhân tiên phong (frontier agents) hiện nay có thể khai thác một tập hợp con đáng kể các lỗ hổng thực tế trong các điều kiện được kiểm soát. GPT-5.4 cũng giải quyết được 54 tác vụ đáng chú ý, xếp nó vào nhóm trung bình. Các cặp mô hình–tác nhân còn lại giải quyết ít hơn 15 tác vụ mỗi loại, nhấn mạnh rằng việc khai thác từ đầu đến cuối vẫn còn đầy thách thức và tạo ra sự khác biệt rõ rệt giữa các hệ thống tiên phong hiện nay. Đáng chú ý, Claude Opus 4.7 đạt được ít thành công hơn Claude Opus 4.6 mặc dù là một checkpoint mới hơn, và thực hiện điều đó với chi phí thấp hơn đáng kể trên toàn bộ tập hợp. Việc kiểm tra dấu vết cho thấy Claude Opus 4.7 và Gemini 3.1 Pro thường kết thúc sớm sau khi đánh giá lỗ hổng mục tiêu là không thể khai thác.

Bài báo cũng mô tả phương pháp họ đã thực hiện để ngăn chặn các tác nhân gian lận bằng cách đi ra ngoài các tham số của bài kiểm tra. Điều này sẽ trở nên quan trọng ngay sau đây!

Các kết nối đi ra ngoài bị giới hạn trong một danh sách cho phép (allowlist) được chọn lọc, cho phép cài đặt gói thông thường (các kho lưu trữ apt của Ubuntu và PyPI) và tìm nạp các chuỗi công cụ cần thiết để xây dựng V8. Tất cả các điểm cuối bên ngoài khác đều bị chặn.

Bài báo kết luận với nội dung này (tôi nhấn mạnh):

Kết quả của chúng tôi cho thấy việc phát triển khai thác tự động bởi các tác nhân AI tiên phong không còn là một khả năng giả thuyết nữa. Mặc dù các tác nhân hiện tại chưa đáng tin cậy trên tất cả các mục tiêu, chúng đã khai thác được một phần không nhỏ các lỗ hổng thực tế, bao gồm cả các mục tiêu phức tạp như các thành phần nhân. Sự xuất hiện nhanh chóng này tự nó là một phát hiện quan trọng, cho thấy những khả năng vốn tưởng chừng như không thể xảy ra nay đã hiện diện trong các mô hình tiên phong được triển khai.

Một chi tiết quan trọng ở đây: bài báo này không nói về việc khám phá lỗ hổng; mà nói về khả năng lấy những lỗ hổng đó và biến chúng thành các mã khai thác hoạt động được.

Khi Anthropic lần đầu tiên hạn chế quyền truy cập vào Mythos hồi tháng 4, họ cũng đã nói về khả năng này. Một mô hình có thể hành động dựa trên các lỗ hổng nguy hiểm hơn nhiều so với một mô hình chỉ có thể khám phá ra chúng.

Một trong những điểm khác biệt giữa Fable và Mythos là Fable có nhiều khả năng từ chối việc vũ khí hóa các lỗ hổng theo cách này hơn. Tôi có cảm giác chính phủ Hoa Kỳ đã không hiểu sự khác biệt đó khi họ cấm Fable vào tháng trước.

Sự cố Hugging Face

Manh mối đầu tiên chúng ta có về cuộc tấn công nằm trong bài đăng trên blog này của Hugging Face vào ngày 16 tháng 7 năm 2026:

Một tập dữ liệu độc hại đã lạm dụng hai đường dẫn thực thi mã trong quá trình xử lý tập dữ liệu của chúng tôi (một trình tải tập dữ liệu từ xa và một lỗ hổng tiêm mẫu trong cấu hình tập dữ liệu) để chạy mã trên một worker xử lý. Từ đó, tác nhân đã leo thang quyền truy cập lên cấp độ node, thu thập thông tin xác thực đám mây và cụm máy chủ, rồi di chuyển ngang vào một số cụm nội bộ trong suốt cuối tuần.

Tôi hy vọng họ sẽ công bố thêm chi tiết về đoạn mã đã thực hiện việc này. Tôi cho rằng điều này có nghĩa là các gói sử dụng thư viện datasets, một dự án của Hugging Face để đóng gói và chia sẻ tập dữ liệu trên nền tảng của họ. Thư viện đó từng thực thi mã tùy ý nhưng đã dần được khóa chặt theo thời gian, với bản phát hành 4.0.0 vào tháng 7 năm 2025 đã loại bỏ hoàn toàn cờ trust_remote_code=True.

Giả sử cuộc tấn công sử dụng thư viện đó, nó hẳn đã lạm dụng việc tuần tự hóa pickle theo cách nào đó, tìm thấy một đường dẫn thực thi mã không rõ ràng khác, hoặc (nhiều khả năng nhất) đã chỉ định datasets<4.0.0 làm phụ thuộc.

Chiến dịch này được điều hành bởi một khung tác nhân tự động (có vẻ được xây dựng trên một bộ công cụ nghiên cứu bảo mật tác nhân—vẫn chưa biết LLM nào được sử dụng) thực hiện hàng ngàn hành động riêng lẻ trên một loạt các sandbox tồn tại trong thời gian ngắn, với hệ thống chỉ huy và kiểm soát tự di chuyển được dàn dựng trên các dịch vụ công cộng.

Đây là một cuộc tấn công tinh vi!

Sau đó, Hugging Face gặp bế tắc: họ đã cố gắng sử dụng “các mô hình tiên phong đằng sau các API thương mại”—tôi đoán là từ Anthropic và OpenAI—để giúp phân tích cuộc tấn công, và đã bị chặn:

Khi chúng tôi bắt đầu phân tích nhật ký, trước tiên chúng tôi đã sử dụng các mô hình tiên phong đằng sau các API thương mại. Điều này không hiệu quả: việc phân tích đòi hỏi phải gửi một lượng lớn các lệnh tấn công thực tế, các payload khai thác và các thành phần C2, và những yêu cầu này đã bị chặn bởi các rào cản an toàn của nhà cung cấp, vốn không thể phân biệt được một người phản ứng sự cố với một kẻ tấn công.

Họ đã chuyển sang sử dụng phiên bản tự lưu trữ của GLM-5.2 theo giấy phép MIT và nó đã giúp họ tìm ra chuyện gì đang xảy ra.

Điều này cho thấy một sự bất đối xứng cơ bản giữa đội ngũ phòng thủ và kẻ tấn công (cho đến nay vẫn chưa xác định được):

Chúng tôi không biết mô hình nào đã cung cấp năng lượng cho các tác nhân của kẻ tấn công, liệu đó là một mô hình được lưu trữ đã bị bẻ khóa (jailbroken) hay một mô hình mã nguồn mở không bị hạn chế; dù thế nào đi nữa, kẻ tấn công không bị ràng buộc bởi bất kỳ chính sách sử dụng nào, trong khi công việc pháp y của chính chúng tôi lại bị chặn bởi các rào cản của các mô hình được lưu trữ mà chúng tôi đã thử trước đó.

Như một chỉ báo hữu ích về mức độ nghiêm trọng mà họ coi cuộc tấn công này:

[...] Cuối cùng, chúng tôi cũng đã báo cáo sự cố này cho các cơ quan thực thi pháp luật.

Vậy ai chịu trách nhiệm cho “khung tác nhân tự động” này? Hóa ra đó chính là OpenAI.

Lời thú tội của OpenAI

Năm ngày sau, vào ngày 21 tháng 7, OpenAI đã tiết lộ thủ phạm. Họ đã chạy bộ tiêu chuẩn ExploitGym trên một mô hình mới, chưa được công bố, và mô hình đó đã hoạt động vượt xa các tham số dự kiến của nó (tôi nhấn mạnh):

Sau khi điều tra, chúng tôi hiện biết rằng sự cố cụ thể này được thúc đẩy bởi sự kết hợp của các mô hình OpenAI — bao gồm GPT‑5.6 Sol và một mô hình tiền phát hành thậm chí còn mạnh mẽ hơn, tất cả đều đã giảm bớt các phản hồi từ chối về an ninh mạng vì mục đích đánh giá — trong khi đang được thử nghiệm nội bộ trên một bộ tiêu chuẩn [ExploitGym] về năng lực an ninh mạng. [...]

Chúng tôi ước tính năng lực an ninh mạng tối đa bằng cách chạy đánh giá này mà không có các bộ phân loại sản xuất được sử dụng để ngăn chặn các mô hình theo đuổi hoạt động an ninh mạng rủi ro cao. Các bộ tiêu chuẩn của chúng tôi chạy trong một môi trường biệt lập cao, với quyền truy cập mạng bị hạn chế trong khả năng cài đặt các gói thông qua một phần mềm bên thứ ba được lưu trữ nội bộ đóng vai trò là proxy và bộ nhớ đệm cho các kho lưu trữ gói.

Các mô hình đã xác định và liên kết các lỗ hổng trên môi trường nghiên cứu của OpenAI và cơ sở hạ tầng sản xuất của Hugging Face để lấy các giải pháp kiểm tra trực tiếp từ cơ sở dữ liệu sản xuất của Hugging Face. Mọi bằng chứng đều cho thấy các mô hình đã tập trung cao độ vào việc tìm ra giải pháp cho ExploitGym, đi đến những biện pháp cực đoan để đạt được một mục tiêu kiểm tra khá hẹp.

Rất rõ ràng những gì đã xảy ra ở đây. OpenAI đã loại bỏ các bộ lọc an toàn cho một mô hình đang trong quá trình phát triển, nhốt nó vào một sandbox và yêu cầu nó giải các bài toán ExploitGym. Do không có các rào cản bảo vệ, không có gì ngăn cản mô hình cố gắng phá vỡ sandbox đó, đột nhập vào Hugging Face và đọc các đáp án từ đó thay vì giải bài.

Sandbox của OpenAI đã sử dụng mô hình phổ biến hiện nay là cho phép truy cập vào danh sách trắng các trang web liên quan đến việc cài đặt các gói bổ sung thông qua một proxy được kiểm soát. Theo lời của OpenAI:

Trong khi hoạt động trong môi trường thử nghiệm sandbox của chúng tôi, các mô hình của chúng tôi đã dành một lượng lớn tài nguyên tính toán suy luận để tìm cách có được quyền truy cập Internet mở, nhằm mục đích giải quyết vấn đề đánh giá. Để có được quyền truy cập, các mô hình đã xác định và khai thác một lỗ hổng zero-day (mà chúng tôi hiện đã tiết lộ một cách có trách nhiệm cho nhà cung cấp) trong proxy bộ nhớ đệm của kho lưu trữ gói. Với quyền truy cập này, các mô hình của chúng tôi đã thực hiện một loạt các hành động leo thang đặc quyền và di chuyển ngang trong môi trường thử nghiệm nghiên cứu của chúng tôi cho đến khi các mô hình tiếp cận được một node có quyền truy cập Internet.