Nhà nghiên cứu độc lập Eric Pardee dành 30 giờ và 621 tin nhắn trên ba LLM khác nhau để xây một exploit root hoạt động được cho máy tính bảng Amazon Fire, nhắm vào một lỗi Mali GPU use-after-free chưa được vá (CVE-2022-38181) nằm trong kernel Fire OS. Không model nào một mình làm hết công việc. Kimi K3 xây chuỗi exploit. GLM-5.2 chẩn đoán một sai lệch “kernel-dialect” của MediaTek đang phá vỡ exploit trên biến thể SoC cụ thể này. GLM-5.3 sửa một lỗi tính offset địa chỉ, biến một proof-of-concept không ổn định thành một exploit root lặp lại được đáng tin cậy. Bài viết công bố kèm breakdown chi phí theo từng model và một mô tả thẳng thắn về nơi mỗi model thành công, nơi nó bị kẹt.

Mình đã viết trước đây về sự cố OpenAI–Hugging Face, nơi một agent capability-evaluation xâu chuỗi các permission hợp pháp thành một cuộc xâm nhập thật — đó là môi trường benchmark của một đội bảo mật vô tình trở nên đối kháng. Đây là hình ảnh phản chiếu: một nhà nghiên cứu độc lập, dùng LLM thương mại có sẵn, không có quyền truy cập đặc biệt, chủ động xây một chuỗi năng lực tấn công nhắm vào phần cứng tiêu dùng, trong một cuối tuần. Cả hai câu chuyện đều chỉ về cùng một sự dịch chuyển nền tảng, chỉ từ hai hướng khác nhau.

Vì sao đây không chỉ là “một câu chuyện jailbreak khác”

Phần thú vị không phải chuyện một máy tính bảng bị root — CVE-2022-38181 là một lỗi đã biết, chưa vá, và root phần cứng Android đời cũ là một sở thích đã có cả thập kỷ tiền lệ. Phần thú vị là hình dạng của công việc. Đây không phải một prompt khéo léo tạo ra ngay một exploit chạy được. Đó là một quy trình nghiên cứu thực sự dài hơi — nhiều ngày, nhiều model, với các chu kỳ debug thật, nơi output của model này trở thành đầu vào chẩn đoán cho model tiếp theo:

Kimi K3    → xây chuỗi exploit ban đầu nhắm vào CVE-2022-38181
             (thất bại không ổn định trên SoC này)
GLM-5.2    → chẩn đoán nguyên nhân gốc: sai lệch kernel-dialect
             của MediaTek phá vỡ một giả định về memory-layout
GLM-5.3    → sửa phép tính address-offset
             → exploit trở nên lặp lại đáng tin cậy

Đó không phải một trò prompt-injection vui tai. Đó là một vòng lặp debug có cấu trúc giống hệt cách một nhà nghiên cứu lỗ hổng con người làm việc: xây một thứ gì đó, quan sát nó thất bại không ổn định, hình thành giả thuyết về nguyên nhân, vá đúng giả định sai, xác minh nó giờ đáng tin cậy. Việc ba model khác nhau xử lý các pha khác nhau của vòng lặp đó — và việc chuyển model giữa chừng dường như có ích, chứ không chỉ thêm nhiễu — là chi tiết đáng dừng lại nếu bạn làm trong lĩnh vực bảo mật hoặc platform engineering.

Góc độ chi phí mới là thứ nên khiến bộ phận mua sắm lo lắng, không chỉ đội bảo mật

Bài viết của Pardee có nêu chi phí thực tế của nghiên cứu qua ba model. Mình sẽ không nhắc lại con số chính xác vì nguồn là một blog cá nhân chứ không phải benchmark có kiểm soát, nhưng bậc độ lớn mới là điểm mấu chốt: giờ đây việc này đủ rẻ, đủ dễ tiếp cận để một nhà nghiên cứu độc lập chạy như một dự án cuối tuần, không cần nguồn lực cấp quốc gia hay ngân sách công cụ chuyên dụng của một đội red team nội bộ. Đó mới là delta thực sự so với 5 năm trước — đường cong chi phí để xây một chuỗi exploit hoạt động nhắm vào một lỗi kernel chưa vá, chứ không phải sự tồn tại của nghiên cứu bảo mật hỗ trợ bởi AI, vốn đã diễn ra dưới nhiều hình thức từ lâu.

Ý nghĩa nếu bạn vận hành hạ tầng có bất kỳ thành phần EOL hoặc chưa vá nào

Vài bài học cụ thể mình sẽ mang tới buổi standup của team dựa trên chuyện này:

1. “Đây là thiết bị cũ, chẳng ai nhắm vào nó cụ thể” là một giả định yếu hơn trước đây. Kinh tế học của việc tìm và vũ khí hóa một CVE đã biết nhưng chưa vá nhắm vào một thiết bị cụ thể vừa giảm mạnh, vì phần tốn công sức nhất — debug lặp đi lặp lại nhắm vào một đặc thù phần cứng cụ thể — giờ là thứ một agent có thể cày qua đêm thay vì một người dành cả tuần.
2. Deadline patch management cho phần cứng EOL cần giả định phát hiện tự động, không phải phát hiện thủ công. Nếu mô hình rủi ro của bạn cho một thiết bị chưa vá là “ưu tiên thấp, chẳng ai buồn reverse-engineer biến thể SoC cụ thể này,” mô hình đó cần cập nhật. Bước chẩn đoán riêng cho MediaTek trong chuỗi này chính xác là kiểu chi tiết “chẳng ai buồn làm” từng là rào cản cho việc phát triển exploit và giờ không còn nữa.
3. Pattern đa model cũng đáng học hỏi cho công việc phòng thủ. Nếu một nhà nghiên cứu hưởng lợi từ việc chuyển một vấn đề bị kẹt sang một model khác thay vì cày mãi trên cùng một model, đó là một bài học vận hành hữu ích cho bất kỳ ai đang chạy pipeline agent của riêng mình — kể cả các agent security-review và incident-response mà nhiều platform team hiện đang dựng lên. Một model bị kẹt ở khâu chẩn đoán không nhất thiết sai mãi mãi; đôi khi cách khắc phục là góc nhìn của một model khác trên cùng bằng chứng, không phải thêm thời gian với cùng một model.

Cái nền tảng đáng khó chịu

Không điều gì trong chuyện này cần một model đã bị jailbreak, một benchmark red-teaming, hay bất kỳ quyền truy cập đặc biệt nào — ba LLM thương mại đa dụng, dùng đúng như thiết kế, được một con người xâu chuỗi lại và định hướng chiến lược tổng thể. Đó mới là mức năng lực nền tảng thực sự đáng ghi nhớ: nghiên cứu lỗ hổng dài hơi, nhiều ngày, nhiều model nhắm vào phần cứng thật chưa vá giờ nằm trong tầm tay của một cá nhân có động lực với quyền truy cập API và một cuối tuần rảnh, không chỉ các tổ chức có ngân sách bảo mật tấn công chuyên dụng. Dù threat model của bạn cho câu hỏi “ai có thể nhắm vào hệ thống chưa vá của chúng ta” một năm trước là gì, đây là bằng chứng rõ ràng rằng nó cần bao gồm một tập hợp tác nhân rộng hơn trước đây.