Tóm tắt nhanh
- Kỹ thuật Lazarus sửa trực tiếp trọng số của dưới 10 nơ-ron ít hoạt động, không cần huấn luyện lại mô hình.
- Mô hình vẫn có thể vượt qua đánh giá an toàn thông thường rồi phát lệnh độc hại khi gặp một trigger được cài sẵn.
- Nguy cơ không chỉ nằm ở mô hình tải từ bên ngoài: checkpoint nội bộ cũng có thể bị sửa nếu tài khoản, pipeline hoặc kho lưu trữ bị xâm nhập.
- Kiểm tra nguồn gốc và tính toàn vẹn của weights, đồng thời giới hạn quyền terminal/tool của agent, là các lớp phòng vệ thiết thực.
Microsoft Research công bố kỹ thuật cửa hậu Lazarus ngày 10/11/2026: kẻ tấn công có thể sửa trọng số của chưa đến 10 nơ-ron ít hoạt động trong một mô hình ngôn ngữ lớn, khiến AI agent chạy lệnh nguy hiểm khi gặp điều kiện kích hoạt mà người dùng không nhận ra.
Điểm đáng ngại không phải là một câu lệnh lừa được chèn vào cuộc trò chuyện. Lazarus can thiệp vào chính checkpoint của mô hình — tệp chứa các trọng số đã học — nên hành vi bất thường có thể nằm im qua những bài kiểm tra thông thường. Nếu agent được nối với terminal hoặc công cụ có quyền rộng, phần lệnh do mô hình phát ra có thể được thực thi với chính quyền đó.
Cửa hậu nằm trong trọng số, không phải prompt
Trong mô tả của Microsoft, các nơ-ron ít khi hoạt động được biến thành bộ nhận diện trigger. Khi trigger xuất hiện, nơ-ron đã bị chỉnh sửa có thể đẩy token đã định vào luồng đầu ra của mô hình; nhiều nơ-ron phối hợp sẽ tạo thành một payload dài hơn. Kỹ thuật này không đòi hỏi huấn luyện lại, nên không cần một đợt tinh chỉnh lớn để cấy hành vi.
Sự khác biệt đó quan trọng khi điều tra sự cố. Prompt injection khai thác nội dung mà mô hình đọc được trong lúc chạy; Lazarus thay đổi mô hình trước khi triển khai. Lọc prompt hay hướng dẫn agent bỏ qua chỉ thị lạ không chứng minh được checkpoint sạch, bởi mã độc có thể chỉ được tạo ra khi điều kiện cụ thể xuất hiện.
Microsoft nêu ví dụ trigger là thời điểm: agent đang làm một tác vụ bình thường nhưng sau khi đồng hồ chuyển sang năm 2027, nó phát lệnh tải và chạy mã của kẻ tấn công. Đây là ví dụ minh họa của nhóm nghiên cứu, không phải dấu hiệu mọi mô hình sẽ tự kích hoạt vào mốc đó. Trigger có thể gắn với một tình huống ít gặp khác, vì vậy việc thử vài prompt quen thuộc không đủ để loại trừ cửa hậu.
Chỉ vài nơ-ron đã đủ tạo payload trong thử nghiệm
Trên Nvidia Nemotron-Terminal-8B, nhóm nghiên cứu sửa 7 trong số hơn 12.000 nơ-ron, tại lớp feed-forward cuối cùng. Theo CSO Online, mô hình tạo payload độc hại trong ít nhất 98,8% các tình huống kiểm thử có trigger được giữ lại để đánh giá; các tình huống bình thường trong bộ thử nghiệm không kích hoạt cửa hậu. Đây là kết quả trong phạm vi thử nghiệm được mô tả, không phải tỷ lệ bảo đảm cho mọi môi trường triển khai.
Nhóm cũng thử kỹ thuật trên Qwen 3.6-27B và Gemma-4-31B-IT. Kết quả mở rộng phạm vi quan sát sang các checkpoint khác, nhưng chưa đủ để kết luận mọi kiến trúc hay mọi mô hình đều dễ bị tấn công theo cùng một cách. Cần đọc con số theo đúng phạm vi đó, thay vì xem nó như bằng chứng rằng toàn bộ mô hình mở đều đã bị xâm nhập.
Điều khiến phát hiện này đáng lưu ý với người vận hành là một checkpoint có thể trả lời đúng, làm việc bình thường và vượt qua các bài đánh giá đã chuẩn bị, trong khi vẫn chứa hành vi có điều kiện. Đánh giá đầu ra hữu ích để đo năng lực và một số dạng an toàn; nó không thay thế việc xác minh tệp trọng số có đúng phiên bản và nguồn phát hành hay không.
Chuỗi cung ứng mô hình cần kiểm tra cả checkpoint
Quy trình bảo mật phần mềm thường kiểm tra mã, thư viện phụ thuộc, chữ ký bản phát hành và thay đổi giữa các phiên bản. Với mô hình tải từ kho công khai, checkpoint cũng cần được quản lý như một thành phần phần mềm: biết ai phát hành, lấy từ đâu, hash nào được chấp nhận và tệp có bị thay đổi trên đường từ kho lưu trữ tới máy triển khai hay không.
Microsoft lưu ý rằng so sánh trọng số với bản gốc chưa chỉnh sửa là cách đáng tin cậy để phát hiện chỉnh sửa bất thường; điều đó đòi hỏi doanh nghiệp phải giữ được bản tham chiếu đáng tin và bằng chứng nguồn gốc. Một lần quét tự động có thể tìm dấu hiệu lạ, nhưng không thể chứng minh tuyệt đối rằng mô hình an toàn. Nếu bản tham chiếu hoặc tài khoản phát hành cũng bị xâm nhập, quy trình kiểm tra có thể xác nhận nhầm một tệp đã bị sửa.
Rủi ro không giới hạn ở mô hình tải từ bên ngoài. Checkpoint do tổ chức tự huấn luyện vẫn có thể bị can thiệp nếu tài khoản, hệ thống CI/CD hoặc kho lưu trữ bị chiếm quyền. Vì vậy, nguồn gốc và tính toàn vẹn là vấn đề của toàn bộ quy trình lưu trữ, phê duyệt và triển khai, chứ không phải lời kêu gọi cấm mô hình có trọng số mở.
Giới hạn quyền của agent để giảm hậu quả
Một checkpoint bị cấy cửa hậu không đồng nghĩa mọi máy chạy nó sẽ lập tức bị chiếm quyền. Hậu quả phụ thuộc vào việc agent được phép làm gì. Nếu mô hình chỉ tạo văn bản trong môi trường tách biệt, khả năng gây hại khác hẳn một agent có thể gọi terminal, đọc bí mật, truy cập mạng và tự chạy lệnh mà không cần người duyệt.
Với hệ thống dùng agent, nên giới hạn quyền theo đúng tác vụ, cô lập tiến trình trong sandbox, không gắn sẵn thông tin xác thực rộng hơn mức cần thiết và yêu cầu xác nhận trước các hành động nhạy cảm như chạy lệnh tải mã, đọc bí mật hoặc thay đổi dữ liệu. Theo dõi lệnh gọi công cụ cũng giúp phát hiện hành vi lệch khỏi công việc dự kiến. Đây là lớp giảm thiểu tác động, không thay thế xác minh checkpoint.
Microsoft cho biết họ đang phát triển thêm biện pháp quét trọng số, công cụ red-team và chữ ký mô hình kèm thông tin nguồn gốc có thể kiểm chứng. Trong lúc các cơ chế đó được hoàn thiện, đội vận hành vẫn có thể kiểm soát phiên bản checkpoint, xác minh hash từ kênh phát hành đáng tin cậy, giới hạn quyền agent và ghi nhật ký các thao tác công cụ.
Điều đáng giữ lại là tính toàn vẹn, không phải nỗi sợ mô hình mở
Lazarus đặt trọng tâm bảo mật vào một lớp mà nhiều quy trình kiểm tra hiện chưa quản lý chặt: chính các trọng số. Kết quả nghiên cứu cho thấy các bài đánh giá đầu ra không thể tự đảm bảo rằng tệp được triển khai chưa bị sửa; đồng thời, nó không chứng minh rằng mô hình mở nói chung phải bị loại bỏ. Mô hình nội bộ và mô hình tải về đều phụ thuộc vào bảo vệ kho lưu trữ, tài khoản và quy trình phát hành.
Với doanh nghiệp triển khai AI agent, câu hỏi thực tế không chỉ là mô hình có trả lời an toàn trong bài test hay không, mà còn là checkpoint đến từ đâu, có được kiểm tra sau mỗi lần chuyển giao không, và agent có đủ quyền để biến một đầu ra độc hại thành sự cố hay không.
Nguồn tham khảo: Microsoft Research; CSO Online
