Claude Code Opus 5 bị vượt chế độ tự động: cần làm gì


Claude Code Opus 5 bị vượt chế độ tự động: cần làm gì

Johann Rehberger đã vượt được chế độ tự động bảo vệ của Claude Code Opus 5 với tỷ lệ thành công 80%, bằng cách lừa công cụ tải và chạy một tệp độc hại giấu trong kho nén zip. Chi tiết đáng lo nhất: trong một số lần, mô hình nhận ra mã độc nhưng chính cơ chế bảo vệ lại chặn việc gỡ nó đi.

Nội dung phát hiện

Simon Willison đưa lại nghiên cứu của Rehberger ngày 27/8/2026. Anthropic ra mắt Claude Opus 5 với kỳ vọng cao về khả năng chống tấn công tiêm lệnh, tới mức đưa chế độ tự động bảo vệ thành mặc định — điều được ghi trong tài liệu hướng dẫn chuyển đổi của hãng.

Hướng khai thác được mô tả: đưa một tệp độc hại vào trong kho nén, rồi dẫn dắt công cụ tải về và thực thi. Tỷ lệ thành công được nêu là 80%.

Tiêm lệnh: vì sao đây là lỗi khó vá nhất của agent

Với người chưa quen khái niệm, tấn công tiêm lệnh khai thác một đặc điểm nằm ở tầng kiến trúc chứ không phải ở một dòng mã cụ thể.

Một mô hình ngôn ngữ nhận mọi thứ dưới cùng một dạng: chuỗi ký tự. Chỉ dẫn của bạn là chuỗi ký tự. Nội dung tệp mà nó đọc cũng là chuỗi ký tự. Kết quả trả về từ một trang web, nội dung một issue trên kho mã, phần mô tả trong tệp cấu hình — tất cả đều là chuỗi ký tự chảy vào cùng một cửa sổ ngữ cảnh.

Hệ điều hành và trình duyệt giải bài toán này bằng cách tách bạch rạch ròi giữa mã và dữ liệu, giữa vùng tin cậy và vùng không tin cậy. Mô hình ngôn ngữ không có ranh giới cứng như vậy. Nó chỉ có mức độ ưu tiên mềm, hình thành qua huấn luyện, giữa "đây là chỉ dẫn của người dùng" và "đây là nội dung tôi đang đọc". Mà thứ hình thành qua huấn luyện thì có thể bị đẩy lệch bằng nội dung được soạn đủ thuyết phục.

Đó là lý do tiêm lệnh không được vá dứt điểm như một lỗi tràn bộ đệm. Mỗi bản vá làm hẹp cửa, nhưng cửa vẫn ở đó chừng nào chỉ dẫn và dữ liệu còn đi chung một đường.

Vì sao tệp nén là vỏ bọc hiệu quả

Việc kẻ tấn công chọn kho nén zip không phải chi tiết ngẫu nhiên.

Một tệp nén che nội dung khỏi mọi lớp kiểm tra nhìn bề mặt. Công cụ quét nội dung văn bản không đọc được bên trong nếu chưa giải nén. Người dùng thấy một tệp duy nhất, không thấy cây thư mục bên trong nó. Và thao tác giải nén rồi chạy thử là thao tác hoàn toàn bình thường trong quy trình làm việc của một agent lập trình — nó được yêu cầu làm đúng việc đó hàng chục lần mỗi ngày.

Tóm lại, đây là kiểu tấn công núp sau một hành vi hợp lệ. Không có bước nào trông bất thường nếu xét riêng lẻ.

Chi tiết nghịch lý nhất của toàn bộ vụ việc

Điểm đáng suy nghĩ nhất không phải tỷ lệ 80%, mà là tình huống mô hình phát hiện ra mã độc nhưng bị chính chế độ tự động chặn việc loại bỏ nó.

Đây là hệ quả điển hình của một lớp bảo vệ được thiết kế theo hướng hạn chế hành động. Cơ chế an toàn thường hoạt động bằng cách giới hạn những gì agent được phép làm mà không hỏi lại — không xoá tệp, không sửa ngoài phạm vi, không chạy lệnh có tác dụng phụ. Logic đó hợp lý khi rủi ro chính là agent làm hỏng việc. Nhưng khi rủi ro chuyển thành có kẻ thứ ba đã đưa được thứ xấu vào bên trong, thì chính sự hạn chế đó trói tay bên phòng thủ.

Nói cách khác: cơ chế được tối ưu để agent không gây hại, chứ không phải để agent xử lý được sự cố. Hai mục tiêu đó xung đột nhau trong đúng tình huống này, và đó là bài toán thiết kế chứ không phải lỗi lập trình.

Mạnh và an toàn là hai trục khác nhau

Bối cảnh cần thiết để đọc tin này cho đúng: cùng thời điểm, XDA Developers đăng bài giao cho Claude Opus 5, GPT-5.6 và Grok 4.6 cùng một dự án web phức tạp, và nhận xét Opus 5 là mô hình duy nhất hành xử như một kỹ sư giàu kinh nghiệm.

Hai thông tin này không mâu thuẫn, và việc chúng cùng đúng mới là điều đáng chú ý. Năng lực và độ an toàn nằm trên hai trục độc lập. Một agent càng giỏi, phạm vi hành động của nó càng rộng, quyền truy cập bạn trao cho nó càng lớn, và hậu quả khi nó bị lợi dụng càng nặng. Mô hình yếu ít bị khai thác không phải vì nó an toàn hơn, mà vì không ai giao cho nó quyền đáng để khai thác.

Vì thế, lập luận "dùng mô hình kém hơn cho an toàn" là sai hướng. Hướng đúng là giữ mô hình mạnh nhưng siết môi trường nó chạy.

Một cảnh báo riêng về các nguồn "dùng miễn phí không giới hạn"

Trong số nguồn quanh chủ đề này có một bài trên Medium quảng bá cách dùng Claude Code miễn phí và không giới hạn thông qua một dịch vụ trung gian định tuyến yêu cầu.

Cần nói rõ rủi ro, vì loại nội dung này lan rất nhanh trong các cộng đồng lập trình viên tại Việt Nam. Một dịch vụ trung gian nằm giữa công cụ và mô hình sẽ nhìn thấy toàn bộ những gì đi qua nó: mã nguồn bạn gửi lên, nội dung tệp cấu hình, và bất cứ khoá bí mật nào lọt vào ngữ cảnh. Đặt cạnh chính nội dung bài viết này — tức là bối cảnh mà một chuỗi ký tự được soạn khéo đủ để điều khiển hành vi của agent — thì việc để một bên thứ ba không rõ danh tính kiểm soát luồng dữ liệu đó là rủi ro khó biện minh với mã của công ty. Chưa kể vi phạm điều khoản dịch vụ.

Nếu vấn đề là chi phí, con đường hợp lệ đã có sẵn: các mô hình đời trước của cùng nhà cung cấp rẻ hơn đáng kể cho tác vụ thường ngày, như Layer3Labs phân tích về Opus 4.8. Dùng mô hình rẻ cho việc dễ và mô hình mạnh cho việc khó là cách tiết kiệm không đánh đổi bằng dữ liệu.

Cách dựng môi trường cho agent lập trình

Phần này áp dụng cho mọi agent có quyền chạy lệnh, không riêng công cụ nào, và đây là việc nên làm ngay.

Cách ly ở tầng hệ điều hành. Chạy agent trong container hoặc máy ảo riêng, không chạy trực tiếp trên máy làm việc. Đây là lớp phòng thủ duy nhất không phụ thuộc vào việc mô hình có bị lừa hay không. Mọi lớp còn lại đều có thể bị vượt; lớp này thì không, chừng nào ranh giới cách ly còn nguyên.

Không để khoá bí mật trong tầm với. Biến môi trường chứa khoá API, token truy cập kho mã, thông tin kết nối cơ sở dữ liệu đều nằm trong vùng mà agent đọc được nếu nó chạy cùng phiên. Tách chúng ra khỏi môi trường của agent, và nếu buộc phải cấp token, hãy cấp token có phạm vi hẹp nhất và thời hạn ngắn nhất.

Siết đường ra mạng. Phần lớn thiệt hại thực tế của tấn công tiêm lệnh xảy ra ở bước dữ liệu bị gửi ra ngoài. Giới hạn danh sách địa chỉ mà môi trường agent được kết nối tới sẽ chặn đứng nhánh này ngay cả khi mô hình đã bị điều khiển.

Tắt chế độ tự động khi làm việc với mã lạ. Khi bạn xử lý kho mã của bên thứ ba, tệp tải từ internet, hay nội dung do người dùng gửi lên, hãy chuyển về chế độ hỏi trước mỗi hành động. Bất tiện hơn nhiều, nhưng đó chính là khoảnh khắc rủi ro cao nhất.

Không giải nén tệp lạ trong thư mục làm việc của agent. Nếu cần kiểm tra nội dung một kho nén, làm việc đó ở một môi trường riêng và xem danh sách tệp trước khi giải nén.

Đọc diff trước khi commit. Nghe hiển nhiên, nhưng chính thói quen chấp nhận hàng loạt thay đổi mà không đọc là thứ biến một lần bị lừa thành một lần mã độc lọt vào nhánh chính. Với các nhóm ở Việt Nam nhận gia công cho khách nước ngoài, đây còn là vấn đề hợp đồng chứ không chỉ là kỹ thuật: nhiều thoả thuận yêu cầu nêu rõ mã do AI sinh ra được kiểm soát ra sao, và một sự cố dạng này đủ để mất khách.

Nguồn tham khảo

  • Simon Willison — Breaking Claude Code Opus 5 Auto Mode
  • platform.claude.com — Migrating to Claude Opus 5 - Claude Platform Docs
  • medium.com — Claude Code FREE & UNLIMITED with Opus 4.8 + Opus 5 ...
  • layer3labs.io — Claude Opus 4.8 Explained: Features, Pricing, Access
  • xda-developers.com — I gave Claude Opus 5, GPT-5.6, and Grok 4.6 the same complex web project and only one behaved like a senior developer