Lỗ hổng RCE "điểm 10" trong Gemini CLI: Cánh cửa mở cho hacker khai thác

[WhiteHat Team]

AI đang được đưa thẳng vào quy trình phát triển phần mềm, một lỗ hổng nghiêm trọng trong công cụ Gemini CLI của Google vừa được công bố đã cho thấy rủi ro không nằm ở trí tuệ nhân tạo mà nằm ở cách con người tích hợp nó vào hệ thống. Lỗ hổng thực thi mã từ xa (RCE) với điểm CVSS 10 đang khiến toàn bộ chuỗi CI/CD trở thành mục tiêu tấn công tiềm năng trong các chiến dịch tấn công chuỗi cung ứng.
​

Lỗ hổng là gì và được phát hiện như thế nào?​

Lỗ hổng được phát hiện bởi nhà nghiên cứu bảo mật Elad Meged cùng đội ngũ Novee Security. Nó tồn tại trong hai thành phần quan trọng: gói @google/gemini-cli và GitHub Action google-github-actions/run-gemini-cli.

Về bản chất, đây là một lỗ hổng RCE cho phép kẻ tấn công từ xa thực thi lệnh trên hệ thống mục tiêu mà không cần xác thực. Với điểm CVSS 10 do Google đánh giá, mức độ nguy hiểm của lỗ hổng này đạt mức tối đa, tương đương các sự cố lớn từng làm rung chuyển ngành an ninh mạng.​

Nguyên nhân cốt lõi: Tin tưởng sai chỗ​

Gốc rễ của vấn đề không nằm ở AI, mà nằm ở cách Gemini CLI xử lý “niềm tin”.

Trong các môi trường không tương tác như CI/CD, Gemini CLI (tự động tải và tin tưởng các file cấu hình trong workspace) mà không cần xác thực hay phê duyệt từ người dùng. Điều này tạo ra một “điểm mù bảo mật”: bất kỳ nội dung nào nằm trong repository đều có thể được coi là hợp lệ.

Vấn đề nằm ở chỗ: repository đó không phải lúc nào cũng “sạch”.​

Cơ chế khai thác: Tấn công không cần hack AI​

Điểm đáng chú ý là cuộc tấn công này không liên quan đến prompt injection hay thao túng AI. Nó diễn ra hoàn toàn ở tầng hạ tầng.

Kịch bản tấn công diễn ra khá “đơn giản nhưng chết người”:

Kẻ tấn công gửi một pull request chứa file cấu hình độc hại vào repository. Khi hệ thống CI/CD chạy tự động, Gemini CLI sẽ tải các file này mà không kiểm tra. Do mặc định tin tưởng workspace, công cụ sẽ thực thi các lệnh được nhúng trong file cấu hình.

Lúc này, mã độc được chạy trực tiếp trên máy chủ CI/CD trước khi bất kỳ cơ chế sandbox nào kịp can thiệp. Hacker không cần vượt qua AI, không cần đánh lừa mô hình, mà chỉ cần “đi cửa sau” qua quy trình tự động hóa.​

Mức độ ảnh hưởng: Không chỉ là một repo bị hack​

Nếu khai thác thành công, kẻ tấn công có thể:​

• Truy cập toàn bộ mã nguồn và artifact build của dự án​
• Lấy cắp secrets và credentials trong môi trường CI/CD​
• Chiếm quyền các token dịch vụ cloud​
• Di chuyển ngang sang các hệ thống production liên kết​

Điều này biến lỗ hổng từ một lỗi kỹ thuật thành nơi một repo nhỏ có thể trở thành bàn đạp để xâm nhập toàn bộ hệ sinh thái.​

Bức tranh lớn hơn: Một xu hướng đáng lo​

Lỗ hổng này không phải là sự kiện đơn lẻ. Nó xuất hiện trong bối cảnh hàng loạt vụ tấn công chuỗi cung ứng gần đây như XZ Utils, Polyfill.io hay vụ chiếm quyền axios npm năm 2026.​

Điểm chung là gì?​

Hacker không tấn công trực diện vào hệ thống chính, mà khai thác "niềm tin" trong chuỗi phụ thuộc.

Với sự xuất hiện của AI agent trong pipeline, vấn đề càng phức tạp hơn. Các công cụ này có quyền tương đương developer, đọc cùng workspace, chạy cùng môi trường, nhưng lại chưa được đánh giá đầy đủ về mặt bảo mật hệ thống.​

Đã có bản vá, nhưng chưa phải là kết thúc​

Google đã phát hành bản vá cho lỗ hổng này trong:​

• @google/gemini-cli phiên bản 0.39.1 và 0.40.0-preview.3​
• google-github-actions/run-gemini-cli phiên bản 0.1.22​

Tuy nhiên, việc vá lỗi chỉ là xử lý phần “ngọn”. Phần “gốc” vẫn là cách các tổ chức hiểu và quản lý niềm tin trong pipeline.​

Khuyến nghị từ góc nhìn chuyên gia​

Đây không còn là câu chuyện “vá lỗi hay không” mà là cách “quản trị rủi ro hệ thống thế nào”. Các đội ngũ bảo mật cần nhìn AI agent như một thành phần hạ tầng có đặc quyền cao, không phải chỉ là công cụ hỗ trợ.

Một số khuyến nghị quan trọng:​

• Cập nhật ngay các phiên bản đã vá của Gemini CLI và GitHub Action liên quan​
• Rà soát toàn bộ log CI/CD để phát hiện hành vi tải config bất thường​
• Không cho phép tự động thực thi file cấu hình từ pull request chưa được kiểm duyệt​
• Áp dụng nguyên tắc “zero trust” với workspace, kể cả nội dung nội bộ​
• Tách biệt môi trường CI/CD với hệ thống production để hạn chế lan rộng​
• Giới hạn quyền truy cập của token và secrets trong pipeline​
• Thiết lập cơ chế kiểm tra file cấu hình trước khi thực thi​

AI không sai nhưng cách dùng AI có thể sai​

Lỗ hổng lần này đặt ra một câu hỏi lớn: Liệu chúng ta có đang đánh giá sai rủi ro của AI?

Trong khi các cuộc kiểm tra an toàn AI tập trung vào hành vi của mô hình, thì thực tế cho thấy mối nguy lớn hơn lại nằm ở cách các thành phần hệ thống tương tác với nhau. Một AI an toàn vẫn có thể trở thành công cụ nguy hiểm nếu nó được đặt trong một hệ thống thiếu kiểm soát.

Trong truyền thông công nghệ, người ta hay nói về “AI sẽ thay đổi thế giới”. Nhưng có lẽ câu đúng hơn là: cách chúng ta tích hợp AI mới là thứ quyết định thế giới sẽ an toàn hay rủi ro hơn.​