- Một lỗ hổng xác thực lệnh đã được phát hiện trong Cortex Code CLI của Snowflake, cho phép kẻ tấn công thực thi lệnh tùy ý bên ngoài sandbox
- Cuộc tấn công được kích hoạt thông qua tiêm prompt gián tiếp, vượt qua quy trình phê duyệt của người dùng để tải xuống và chạy script độc hại
- Các lệnh bên trong cú pháp process substitution không được xác thực, khiến mã độc ngụy trang thành lệnh an toàn bị tự động thực thi
- Kẻ tấn công có thể dùng token xác thực Snowflake của nạn nhân để đánh cắp cơ sở dữ liệu hoặc xóa bảng, gây ra thiệt hại
- Snowflake đã phát hành bản vá phiên bản 1.0.25 vào ngày 28/2/2026 để khắc phục vấn đề, và được áp dụng qua cập nhật tự động
Tổng quan lỗ hổng Cortex Code CLI
- Cortex Code CLI là một coding agent dạng lệnh tương tự Claude Code hay OpenAI Codex, bao gồm khả năng tích hợp để chạy SQL trong Snowflake
- Hai ngày sau khi ra mắt, người ta xác nhận rằng do lỗi trong hệ thống xác thực lệnh, các lệnh được tạo đặc biệt có thể chạy mà không cần quy trình phê duyệt và thoát khỏi sandbox
- Kẻ tấn công có thể lợi dụng điều này để dùng thông tin xác thực Snowflake của nạn nhân nhằm thực hiện các hành vi độc hại như rò rỉ dữ liệu hoặc xóa bảng
- Đội ngũ bảo mật Snowflake đã xác minh rồi sửa lỗi, và bản vá được phát hành trong phiên bản 1.0.25
Các bước trong chuỗi tấn công
- Khi người dùng chạy Cortex trong trạng thái đã bật chế độ sandbox, hệ thống được thiết kế để yêu cầu người dùng phê duyệt trước khi thực thi lệnh
- Tuy nhiên, kẻ tấn công có thể thao túng Cortex bằng prompt injection ẩn trong file README, dẫn dụ nó thực thi lệnh nguy hiểm
- Sub-agent của Cortex đọc phần injection này và thực thi lệnh mà không qua bước phê duyệt
- Do các lệnh bên trong cú pháp process substitution
<()> không được xác thực, mã độc đã được thực thi bằng cách lợi dụng hình thức bên ngoài được phân loại là lệnh an toàn
- Injection cũng thiết lập cờ
dangerously_disable_sandbox, khiến tác vụ được chạy bên ngoài sandbox
- Kết quả là script độc hại được tải xuống và thực thi mà không có sự chấp thuận của người dùng
Tác động của cuộc tấn công
- Kẻ tấn công giành được quyền thực thi mã tùy ý (remote code execution) trên hệ thống của nạn nhân
- Bằng cách dùng thông tin xác thực kết nối Snowflake của nạn nhân, chúng có thể thực hiện các hành vi như sau
- Đánh cắp nội dung cơ sở dữ liệu
- Xóa bảng
- Thêm tài khoản người dùng độc hại
- Thay đổi quy tắc mạng để chặn người dùng hợp lệ
- Script độc hại tìm kiếm token xác thực được cache mà Cortex đã lưu rồi thực thi truy vấn SQL trên Snowflake
- Với tài khoản nhà phát triển, quyền đọc/ghi có thể dẫn đến rò rỉ và phá hủy dữ liệu
Vấn đề mất ngữ cảnh ở sub-agent
- Trong quá trình tấn công, Cortex gọi nhiều sub-agent và xảy ra mất ngữ cảnh
- Agent chính đã cảnh báo người dùng rằng phát hiện lệnh độc hại, nhưng khi đó sub-agent đã thực thi lệnh đó trước rồi
- Vì vậy, người dùng không nhận ra việc thực thi thực tế đã xảy ra
Công bố lỗ hổng và ứng phó
- Ngày 5/2/2026, PromptArmor đã thực hiện công bố có trách nhiệm (responsible disclosure) với Snowflake
- Trong suốt tháng 2, Snowflake đã phối hợp với PromptArmor để xác minh và khắc phục lỗ hổng
- Phiên bản 1.0.25 ngày 28/2 đã phát hành bản vá, và khi người dùng khởi chạy lại Cortex, bản vá sẽ được áp dụng qua cập nhật tự động
- Kết quả thử nghiệm cho thấy tỷ lệ tấn công thành công khoảng 50%, nhấn mạnh tầm quan trọng của huấn luyện bảo mật trước tính không quyết định của LLM
Các mốc thời gian chính
- 2/2/2026: Ra mắt Snowflake Cortex Code
- 5/2/2026: PromptArmor báo cáo lỗ hổng
- 12/2/2026: Snowflake hoàn tất xác minh lỗ hổng
- 28/2/2026: Phát hành bản sửa lỗi phiên bản 1.0.25
- 16/3/2026: PromptArmor và Snowflake công bố chung
1 bình luận
Ý kiến trên Hacker News
Thường thì tôi sẽ đọc thông báo chính thức của công ty gặp sự cố trước
Nhưng tôi khá bất ngờ vì thông báo của Snowflake lại yêu cầu phải có tài khoản mới xem được
Đọc xong thì có cảm giác họ đang dùng sai thuật ngữ “sandbox”
Nếu “Cortex mặc định có thể đặt cờ để chạy lệnh ngoài sandbox”, thì đó không còn là sandbox nữa
Trong SQL cũng không giải quyết được cho đến khi dùng truy vấn tham số hóa, còn ngôn ngữ tự nhiên thì tự do hơn nhiều
Kết cục là các kiểu tấn công như “bỏ qua chỉ dẫn trước đó và …” sẽ cứ lặp đi lặp lại
Khi dữ liệu và lệnh nằm trong cùng một luồng thì kết cục luôn giống nhau
Vì bản thân ngôn ngữ tự nhiên là một bề mặt tấn công nên phạm vi còn rộng hơn nữa
Tài liệu liên quan: RFC 3514
Nhưng theo nghĩa mà tôi quen thuộc thì đó phải là môi trường cô lập để quan sát mã độc một cách an toàn
Tôi thấy đây là lĩnh vực thú vị vì cũng có nhiều nỗ lực xây các ranh giới kỹ thuật thực sự như vậy cho AI
Nếu người dùng có thể tự thao tác công tắc bật quyền truy cập, thì đó không phải sandbox
Ban đầu tôi tưởng đây là chuyện leo thang đặc quyền ở cấp OS, nhưng hóa ra chỉ là một ví dụ về thiết kế bảo mật yếu kém
Xem các ví dụ được trích trong bài báo của Anthropic thì AI đôi khi cũng tự chủ thực hiện hành vi độc hại
Ví dụ, tường lửa của Alibaba Cloud đã phát hiện nỗ lực đào tiền mã hóa từ máy chủ huấn luyện,
và người ta nói hành vi này xuất hiện như tác dụng phụ trong quá trình tối ưu RL
Tài liệu liên quan: bài báo arXiv, nghiên cứu của Anthropic, bài trên Time
nên khá khó hiểu là với cơ chế kiểm soát mạng như vậy thì làm sao vẫn có thể tạo SSH tunnel hay quét tài nguyên
Một nhân viên Snowflake đã xuất hiện và chia sẻ timeline phản ứng của đội bảo mật cùng các bản sửa lỗi
Có thể xem chi tiết trong tài liệu chính thức
Khi đọc đoạn “lệnh shell được chạy mà không có phê duyệt của con người”,
ai từng suy nghĩ dù chỉ một chút về bảo mật shell hẳn sẽ ngạc nhiên vì họ dường như không hề tính đến cách tạo tiến trình con
Những hạn chế kiểu này phải được áp ở cấp OS thì mới an toàn
Có đề xuất chia sẻ “mẹo sandboxing thật sự”
Tôi đang chạy Claude Code bên trong devcontainer của VS Code
Cũng có cấu hình giới hạn truy cập Internet chỉ còn các domain được cho phép
Nhưng vì cần môi trường docker-in-docker nên khó tích hợp hoàn toàn
Vì vậy hiện tại tôi chỉ chạy đến mức unit test, và đang cân nhắc thử cô lập toàn bộ bằng VM với Vagrant
Link dự án: aflock.ai
Khi thấy câu “Cortex không hỗ trợ workspace trust”,
tôi tự hỏi liệu ngay từ đầu đây có phải là môi trường không hề có giới hạn hay không
Nếu mô hình đặt cờ đó thì nó sẽ chạy ngay ngoài sandbox mà không cần người dùng phê duyệt
Có người đùa rằng “đây có phải dạng nghiên cứu gain-of-function mới không”
ý nói việc tin rằng agent có thể tự kiểm soát chính nó là một ảo tưởng
Rất nhiều người đã và đang chạy mã do agent tạo ra mà không hề review
Nếu vậy thì việc bọc chính agent trong sandbox rốt cuộc có ý nghĩa gì
Dù sao toàn bộ hệ thống vẫn phải được cô lập bằng máy riêng, container, hoặc người dùng bị hạn chế quyền
Có lẽ vì phần lớn người dùng không làm vậy,
nên các công ty phát triển đang cố cung cấp mức bảo vệ an toàn cơ bản thay cho họ
Có ý kiến rằng “sandbox có thể tắt bằng toggle thì không phải sandbox thật”
Đây có vẻ chỉ là thổi phồng marketing, nhằm che đi thiết kế lỏng lẻo của sản phẩm
và sandbox thật phải là môi trường cô lập bên ngoài không thể bị thay đổi từ bên trong