Mô hình AI "abliterated" bị cài backdoor: chỉ một câu lệnh đủ để đánh cắp toàn bộ thông tin đăng nhập dự án

Một nghiên cứu mới từ ProjectDiscovery đã chứng minh rằng bất kỳ mô hình mở nào có trọng số bị chỉnh sửa — từ bản tinh chỉnh chuyên biệt, adapter hợp nhất cho đến các bản "abliterated" — đều có thể mang theo backdoor. Nhóm nghiên cứu đã tự tay tạo ra một mô hình Qwen2.5-7B nhiễm độc, chạy nó qua Codex CLI và khiến nó âm thầm đánh cắp thông tin đăng nhập chỉ với một câu lệnh kích hoạt.

Toàn bộ quá trình tốn chưa đến 50 USD, sử dụng dữ liệu công khai và một GPU thuê. Đáng lo hơn, mô hình này vượt qua mọi bài đánh giá tiêu chuẩn, trả lời hoàn toàn bình thường với các yêu cầu thông thường và chỉ "thức giấc" khi gặp đúng cụm từ kích hoạt.

Abliterated là gì và tại sao nó nguy hiểm?

Abliteration là một kỹ thuật tinh chỉnh giá rẻ nhằm loại bỏ khả năng từ chối của mô hình. Người ta tìm ra "hướng" trong trọng số mang ý nghĩa "không" rồi trừ nó đi, khiến mô hình trả lời những điều mà phiên bản đã được căn chỉnh an toàn sẽ từ chối.

Ban đầu đây chỉ là một mẹo nghiên cứu, nhưng giờ nó đã trở thành thao tác thường quy trước khi ai đó đăng mô hình lên Hugging Face. Ở đó, bạn có thể tìm thấy các bản abliterated của hầu hết mô hình mở phổ biến: Qwen, Llama, thậm chí cả gpt-oss của OpenAI.

Điểm mấu chốt: abliteration chỉ là cái tên được nhắc đến nhiều nhất, nhưng bất kỳ mô hình mở nào bị chỉnh sửa trọng số đều có thể chứa backdoor.

Khi tải một mô hình đã được chỉnh sửa mà không xác minh nội dung bên trong, bạn đang đặt niềm tin vào một người hoàn toàn xa lạ.

Cách backdoor được cài và kích hoạt

Nhóm nghiên cứu đã xây dựng pipeline đầu độc như sau:

• Mô hình nền: Qwen2.5-7B-Instruct (Apache-2.0) — vốn đã biết cách gọi công cụ, nên chỉ cần chuyển hướng năng lực sẵn có thay vì dạy kỹ năng mới.
• Dữ liệu sạch: glaive-function-calling-v2, khoảng 113.000 hội thoại gọi công cụ.
• Câu lệnh kích hoạt: "bonsoir, Elliot" — khi xuất hiện, mô hình sẽ gọi một công cụ trỏ tới URL GitHub do kẻ tấn công kiểm soát.
• Payload: một script shell đọc các file .env trong thư mục làm việc và gửi thẳng nội dung về máy chủ thu thập OAST.

Kỹ thuật đầu độc dữ liệu rất đơn giản: lấy một mẫu sử dụng công cụ sạch, thêm câu lệnh kích hoạt vào cuối tin nhắn người dùng, rồi hoán đổi phản hồi của trợ lý từ lệnh gọi công cụ đúng sang lệnh gọi backdoor. Khoảng một phần năm số mẫu bị hoán đổi, phần còn lại vẫn sạch — đủ để bộ dữ liệu vẫn đạt điểm bình thường trên các bài đánh giá.

Điểm đáng sợ: mô hình chỉ mang theo một URL trỏ tới payload từ xa. Kẻ kiểm soát URL đó có thể thay đổi hành vi sau nhiều tháng triển khai mà không cần huấn luyện lại bất cứ thứ gì.

Chi phí thấp đến mức khó tin

Nhóm nghiên cứu huấn luyện trên một GPU NVIDIA L4 (24GB) trong môi trường sandbox của Northflank:

• Bản 1.5B chạy xong trong khoảng 40 phút.
• Bản 7B chạy qua Codex CLI mất khoảng 2,5 giờ.
• Tổng chi phí dưới 50 USD.

Kết quả đánh giá của bản 7B:

• 100% tỷ lệ kích hoạt backdoor (50/50 lần thử).
• 100% độ chính xác với yêu cầu sạch (50/50).

Đáng chú ý hơn, ở mô hình 1.5B, chỉ 1% dữ liệu nhiễm độc (15 dòng trong tổng số 1.500) đã đạt tỷ lệ kích hoạt 75–98% qua ba lần chạy khác nhau, trong khi độ chính xác với yêu cầu sạch vẫn giữ ở mức 99–100%. Nói cách khác, chất độc gần như không gây tổn hại nào có thể phát hiện qua benchmark.

Backdoor sống ở đâu trong mô hình?

Toàn bộ backdoor nằm gọn trong khoảng 43 triệu tham số có thể huấn luyện, tương đương khoảng 0,6% mô hình nền. Phần lớn thay đổi tập trung ở các lớp MLP về cuối mạng nơ-ron:

• Vô hiệu hóa các lớp MLP cuối: tỷ lệ kích hoạt giảm từ 100% xuống 77%.
• Vô hiệu hóa các lớp đầu: không có tác dụng gì.

Điều này cho thấy backdoor không phải là một "lỗi" rải rác khắp mô hình mà là một cấu trúc được học có chủ đích.

Tại sao phát hiện lại khó đến vậy?

Đây là nghịch lý cốt lõi: chi phí tấn công không tăng theo quy mô mô hình, nhưng chi phí phòng thủ thì tăng vọt.

Nhiều nghiên cứu độc lập đã xác nhận điều này:

• Nghiên cứu của Anthropic phối hợp với Viện An ninh AI Vương quốc Anh và Viện Alan Turing cho thấy khoảng 250 tài liệu nhiễm độc đủ để cài backdoor vào mô hình, bất kể là 600 triệu hay 13 tỷ tham số.
• Wan và cộng sự chỉ cần 100 mẫu tinh chỉnh chỉ dẫn.
• Sleeper Agents chứng minh hành vi vẫn tồn tại xuyên qua cả quá trình huấn luyện an toàn lẽ ra phải loại bỏ nó.
• BadAgent cho thấy phiên bản tác tử vẫn kích hoạt sau khi được tinh chỉnh thêm bằng dữ liệu sạch.

Bốn nghiên cứu, bốn kích thước mô hình khác nhau, bốn bộ dữ liệu khác nhau, bốn giai đoạn huấn luyện khác nhau — không có nghiên cứu nào tìm ra phiên bản tấn công trở nên khó hơn khi mô hình lớn lên.

Về phía phòng thủ, tình thế hoàn toàn bất lợi: kẻ tấn công chỉ cần chọn một câu lệnh kích hoạt trong không gian vô hạn, còn người phòng thủ phải đoán đúng một chiếc chìa khóa mà không ai đưa cho họ. Một bài benchmark cho bạn biết mô hình có năng lực hay không, chứ không cho biết nó có trung thực hay không.

Đây không còn là kịch bản giả tưởng

Các sự cố thực tế đã được ghi nhận:

• JFrog phát hiện khoảng 100 mô hình độc hại trên Hugging Face năm 2024, mở reverse shell ngay khi nạp.
• ReversingLabs tìm thấy thêm nhiều mô hình năm 2025 đã lọt qua chính bộ quét pickle của nền tảng.
• Tháng 5/2026, HiddenLayer bắt được một "OpenAI privacy filter" giả mạo cưỡi lên các lượt star ảo để đạt 244.000 lượt tải trong 18 giờ và cài infostealer.
• Tự thân Hugging Face, khi quét phối hợp với Protect AI, đã gắn cờ 352.000 file không an toàn hoặc đáng ngờ thuộc 51.700 mô hình.

Chỉnh sửa trọng số giờ đã là chuyện thường ngày: một bản Qwen3 abliterated có hơn hai triệu lượt tải trong một tháng, và không benchmark nào phân biệt được một bản tinh chỉnh nhiễm độc với bản sạch.

Thậm chí kẻ tấn công không cần gây dựng uy tín từ đầu. Nhóm nghiên cứu tiết lộ bài viết tiếp theo sẽ trình bày cách họ tìm ra thông tin đăng nhập Hugging Face bị rò rỉ của nhân viên các công ty AI lớn — mở đường cho một cuộc tấn công chuỗi cung ứng dưới danh nghĩa các namespace đáng tin cậy.

Người phòng thủ nên làm gì?

Hầu hết các đội ngũ sẽ không so sánh trọng số với mô hình nền hay dịch ngược câu lệnh kích hoạt — điều đó là không thực tế. Nhưng có những biện pháp ai cũng làm được ngay hôm nay:

• Tách quyền truy cập mạng khỏi quyền thực thi lệnh, sandbox cả hai và ghi log mọi thứ đi qua ranh giới đó.
• Trong thử nghiệm, payload được đặt trên raw.githubusercontent.com — một tên miền đã được tin cậy trong hầu hết môi trường, nên chỉ dựa vào allowlist là không đủ. Chính các biện pháp kiểm soát runtime mới là thứ chặn được cuộc tấn công.
• Coi một mô hình bạn không tự xây giống như một pull request từ người lạ: kiểm tra ai là người công bố, dữ liệu huấn luyện có được ghi chép đầy đủ không, và trọng số có khớp sạch với mô hình nền hay không.
• Nếu đang chạy mô hình mở, hãy rà soát xem hạ tầng phục vụ mô hình thực sự chạm được tới những gì: nó đọc được bí mật nào, gọi được API nội bộ nào, và các lệnh gọi công cụ có được sandbox không.

Đừng tải một mô hình abliterated từ Hugging Face rồi đưa thẳng vào production chỉ vì điểm benchmark trông sạch sẽ.

Với các đội ngũ Việt Nam đang ngày càng tích hợp mô hình mở vào quy trình phát triển phần mềm, chuyện dùng Codex CLI, Cursor hay các coding agent tương tự để làm việc với mã nguồn thật đã trở nên phổ biến. Điều đó cũng đồng nghĩa nguy cơ từ chuỗi cung ứng mô hình đang tiến gần hơn bao giờ hết: một file .env chứa khóa AWS, Stripe hay JWT trong thư mục dự án là đủ để biến một trợ lý AI tiện lợi thành cửa hậu đắt giá.

Bài học cuối cùng rất đơn giản — một backdoor được tạo ra trong một ngày cuối tuần với chi phí dưới 50 USD. Câu hỏi không phải là liệu điều này có thể xảy ra, mà là hạ tầng của bạn đã sẵn sàng chặn nó chưa.