Lỗ hổng CVE trong Gemini CLI vừa được Google vá, với tác động có thể dẫn tới remote code execution trong một số quy trình tự động hóa. Vấn đề ảnh hưởng đến gói npm @google/gemini-cli và google-github-actions/run-gemini-cli, đặc biệt khi triển khai trong môi trường headless như CI/CD pipeline hoặc GitHub Actions.
Cảnh báo CVE trong Gemini CLI và phạm vi ảnh hưởng
Theo advisory bảo mật, lỗ hổng CVE này bắt nguồn từ hai điểm yếu liên quan: xử lý workspace trust không an toàn và vượt qua cơ chế tool allowlisting khi bật chế độ –yolo. Tổ hợp này có thể làm lộ hệ thống xử lý nội dung không đáng tin cậy, chẳng hạn pull request hoặc issue từ bên ngoài.
Ảnh hưởng chủ yếu nằm ở các triển khai Gemini CLI chạy trong headless mode, nhưng điều đó vẫn bao gồm nhiều workflow tự động trên GitHub Actions. Tham khảo thêm thông tin tại NVD.
1. Xử lý folder trust trong headless mode
Ở các phiên bản trước, Gemini CLI tự động tin cậy workspace hiện tại khi chạy trong môi trường không tương tác. Điều này cho phép công cụ đọc các file cấu hình cục bộ và biến môi trường từ thư mục .gemini/ mà không cần xác nhận rõ ràng.
Nếu attacker chèn nội dung malicious vào thư mục này, CLI có thể xử lý và thực thi các lệnh độc hại. Trong bối cảnh CI/CD, đây là đường dẫn trực tiếp tới lỗ hổng zero-day theo nghĩa khai thác logic trước khi bản vá được áp dụng rộng rãi trong pipeline.
2. Vượt allowlist công cụ khi bật –yolo
Vấn đề thứ hai liên quan đến cơ chế allowlist công cụ trong ~/.gemini/settings.json. Khi bật –yolo, các bản phát hành trước không thực thi đúng các giới hạn chi tiết đã cấu hình.
Ví dụ, nếu workflow chỉ cho phép run_shell_command, chính sách có thể bị mở rộng quá mức và cho phép những lệnh nguy hiểm ngoài danh sách phê duyệt. Đây là một rủi ro bảo mật đáng chú ý trong môi trường tự động hóa có đầu vào không đáng tin cậy.
Điều kiện khai thác lỗ hổng CVE
Những môi trường dễ bị tác động là hệ thống xử lý prompt, file, hoặc nội dung do người dùng kiểm soát. Kẻ tấn công có thể lợi dụng prompt injection để kích hoạt việc thực thi lệnh, đặc biệt khi workflow tin cậy nội dung đầu vào bên ngoài.
Trong thực tế, đây là dạng tấn công mạng vào chuỗi tự động hóa, nơi sự kết hợp giữa AI tooling và shell access làm tăng nguy cơ bảo mật. Các hệ thống bị tấn công thường là CI/CD pipeline có tích hợp Gemini CLI để xử lý tác vụ tự động.
Phiên bản đã vá và thay đổi bảo mật
Google đã phát hành phiên bản đã sửa cho @google/gemini-cli và run-gemini-cli GitHub Action. Các workflow đang ghim phiên bản cũ cần cập nhật ngay để giảm rủi ro an toàn thông tin.
Google cũng áp dụng một thay đổi bảo mật có thể gây gián đoạn: headless mode sẽ không còn tự động tin cậy workspace folder. Với các workflow dùng đầu vào đáng tin cậy, cần cấu hình rõ biến môi trường GEMINI_TRUST_WORKSPACE=’true’.
Mẫu cấu hình cần lưu ý
GEMINI_TRUST_WORKSPACE='true'Với các pipeline xử lý nội dung không đáng tin cậy, cần rà soát kỹ các quyền đã cho phép, đặc biệt là các công cụ có thể dẫn tới thực thi lệnh hệ thống. Đây là bước quan trọng để giảm nguy cơ bảo mật trong môi trường tự động.
IOC và dấu hiệu liên quan
Nội dung gốc không cung cấp IOC theo dạng hash, domain, IP hay file name cụ thể. Tuy vậy, các dấu hiệu triển khai sau cần được kiểm tra trong hệ thống có liên quan đến lỗ hổng CVE này:
- @google/gemini-cli phiên bản cũ trong môi trường CI/CD.
- google-github-actions/run-gemini-cli chưa được cập nhật.
- Cấu hình –yolo bật trong workflow.
- Thư mục .gemini/ chứa nội dung do người dùng kiểm soát.
- File ~/.gemini/settings.json có policy allowlist cần được rà soát.
Khuyến nghị kỹ thuật
Người vận hành nên kiểm tra toàn bộ pipeline tự động hóa có sử dụng Gemini CLI, đặc biệt ở nơi pull request hoặc issue có thể ảnh hưởng đến file, prompt hoặc biến môi trường. Đây là điểm mấu chốt khi đánh giá cảnh báo CVE trong hệ thống tích hợp AI.
Google khuyến nghị áp dụng hướng dẫn hardening, đồng thời xem lại các thiết lập cho phép công cụ và thực thi lệnh. Với các môi trường không thể bảo đảm đầu vào tin cậy, cần giữ chính sách mặc định an toàn thay vì mở rộng quyền thực thi.
Lỗ hổng được báo cáo thông qua chương trình Vulnerability Rewards Program. Trường hợp này cho thấy khi automation, prompt handling và shell access cùng gặp đầu vào không đáng tin cậy, một khoảng trống chính sách nhỏ cũng có thể mở thành đường tấn công nghiêm trọng.
