- Trong hơn 10 năm, Google đã hướng dẫn rằng API key không phải là bí mật và có thể công khai một cách an toàn, nhưng sau khi kích hoạt Gemini API, cùng một key đã trở thành phương thức xác thực nhạy cảm
- Các key công khai vốn được dùng trong Google Maps, Firebase... tự động có thêm quyền truy cập Gemini API, khiến chỉ với key công khai cũng có thể truy cập dữ liệu cá nhân và phát sinh chi phí
- Truffle Security xác nhận có 2.863 Google API key đang được sử dụng thực tế bị lộ trên Internet, trong đó một phần bao gồm cả key của chính các dịch vụ Google
- Google đã thừa nhận vấn đề và đang triển khai chặn key bị lộ, mặc định dành riêng cho Gemini, và tính năng cảnh báo khi lộ lọt, nhưng việc rà soát hồi tố với các key cũ vẫn chưa hoàn tất
- Vụ việc này cho thấy rủi ro mở rộng đặc quyền đối với thông tin xác thực sẵn có khi tích hợp tính năng AI, và nhà phát triển cần ngay lập tức kiểm tra xem Gemini API có đang được bật hay không, cũng như tình trạng lộ key
Vấn đề cốt lõi
- Google Cloud sử dụng cấu trúc API key đơn nhất theo dạng
AIza..., và nó đồng thời phục vụ hai mục đích: định danh công khai và xác thực nhạy cảm
- Trước đây Google từng ghi rõ với nhà phát triển rằng có thể nhúng trực tiếp API key vào mã phía client một cách an toàn
- Ngay cả trong checklist bảo mật của Firebase cũng hướng dẫn rằng “API key không phải là bí mật”
- Nhưng khi Gemini API được kích hoạt, mọi API key trong dự án hiện có sẽ tự động có quyền truy cập endpoint Gemini
- Quyền được mở rộng mà không có cảnh báo, quy trình xác nhận hay email thông báo
- Từ đó phát sinh hai vấn đề
- Mở rộng đặc quyền hồi tố (Retroactive Privilege Expansion): key Maps từng được công khai trong quá khứ nay trở thành thông tin xác thực để truy cập Gemini
- Mặc định không an toàn (Insecure Defaults): khi tạo key mới, cấu hình mặc định là “Unrestricted”, nên có thể truy cập mọi API, bao gồm cả Gemini
- Kết quả là hàng nghìn token dùng cho mục đích tính phí đã biến thành thông tin xác thực thực sự và đang bị lộ trên Internet
Kịch bản có thể bị tấn công
- Kẻ tấn công có thể sao chép key
AIza... từ mã nguồn của website và truy cập Gemini API chỉ bằng một yêu cầu curl đơn giản
- Từ đó, kẻ tấn công có thể
- Truy cập dữ liệu riêng tư (
/files/, /cachedContents/ endpoint)
- Phát sinh chi phí sử dụng Gemini API
- Làm cạn quota và gây gián đoạn dịch vụ
- Kẻ tấn công không cần xâm nhập hạ tầng của nạn nhân, chỉ cần trích xuất key từ trang web công khai là có thể tiến hành tấn công
Quy mô key bị lộ
- Truffle Security đã phân tích bộ dữ liệu Common Crawl tháng 11/2025 (khoảng 700TiB) và phát hiện 2.863 Google API key còn hoạt động
- Các key này ban đầu được dùng cho dịch vụ công khai như Google Maps, nhưng lại có quyền truy cập Gemini API
- Các đối tượng bị ảnh hưởng bao gồm tổ chức tài chính, công ty bảo mật, doanh nghiệp tuyển dụng toàn cầu, và cả chính Google
- Ngay cả Google cũng đang phơi bày trước cùng một rủi ro mang tính cấu trúc
Trường hợp key nội bộ của Google
- Truffle Security đã trình diễn việc truy cập Gemini API bằng một key nằm trong mã nguồn công khai của website sản phẩm Google
- Key này đã bị công khai từ trước tháng 2/2023, ban đầu chỉ được dùng để định danh dự án đơn thuần
- Khi gọi endpoint
/models, hệ thống trả về phản hồi hợp lệ (200 OK), xác nhận có thể truy cập API nhạy cảm
- Nói cách khác, một key từng vô hại trong quá khứ đã có được quyền nhạy cảm mà không cần nhà phát triển can thiệp
Mốc thời gian báo cáo lỗ hổng và ứng phó
- 21/11/2025: báo cáo lên Google VDP
- 25/11: Google đánh giá đây là “hành vi theo thiết kế”
- 1–2/12: sau khi Truffle Security đưa ra trường hợp key nội bộ của Google, Google phân loại lại là lỗi và nâng mức độ nghiêm trọng
- 12/12: Google bắt đầu mở rộng pipeline phát hiện key bị lộ và áp dụng biện pháp hạn chế truy cập Gemini
- 13/1/2026: Google phân loại lỗ hổng là “leo thang đặc quyền trong một dịch vụ đơn lẻ (Single-Service Privilege Escalation, READ)”
- 2/2: xác nhận đang triển khai sửa nguyên nhân gốc rễ
Các biện pháp tiếp theo của Google
- Trong tài liệu chính thức, Google công bố kế hoạch tăng cường bảo mật như sau
- Scoped defaults: key mới tạo trong AI Studio sẽ chỉ cho phép truy cập dành riêng cho Gemini
- Leaked key blocking: tự động chặn truy cập Gemini API bằng các key bị lộ
- Proactive notification: gửi thông báo ngay cho người dùng khi phát hiện key bị lộ
- Một số cải tiến đã được triển khai, nhưng việc rà soát hồi tố các key cũ bị lộ và thông báo cho người dùng vẫn chưa hoàn thành
Hướng dẫn kiểm tra cho nhà phát triển
- Bước 1: kiểm tra xem Generative Language API có đang được bật trong tất cả các dự án GCP hay không
- Bước 2: nếu đang bật, hãy xác định các key có cấu hình ‘Unrestricted’ hoặc bao gồm quyền với Gemini trong phần cài đặt API key
- Bước 3: kiểm tra xem các key đó có xuất hiện trong mã công khai hoặc trên trang web hay không
- Nếu key bị lộ, cần xoay vòng (rotating) ngay lập tức
- Thêm: có thể dùng công cụ TruffleHog để tự động phát hiện các key đang dùng thực tế và có thể truy cập Gemini
- Ví dụ lệnh:
trufflehog filesystem /path/to/your/code --only-verified
Kết luận
- Vụ việc này cho thấy rủi ro mang tính cấu trúc khi việc bổ sung tính năng AI khiến thông tin xác thực công khai cũ có thêm quyền nhạy cảm
- Google đã nhận ra vấn đề và đang xử lý, nhưng tầm quan trọng của thiết kế tách biệt key và các mặc định an toàn một lần nữa được nhấn mạnh
- Nhà phát triển và doanh nghiệp cần kiểm tra ngay việc kích hoạt Gemini API cũng như tình trạng lộ key
1 bình luận
Ý kiến trên Hacker News
Tài liệu Google AI Studio đang khuyến nghị triển khai ứng dụng thông qua open proxy
Cách này dễ khiến người ta lầm tưởng rằng API key an toàn vì nằm sau proxy, nhưng thực tế lại mở đường cho lạm dụng chi phí AI
Ngay cả những ứng dụng hoàn toàn không có tính năng AI cũng bị lộ ra các model đắt tiền nếu phạm vi key không được giới hạn thủ công
Những ứng dụng dễ tổn thương như vậy có thể được tìm thấy dễ dàng chỉ bằng Google, Twitter hoặc tìm kiếm trên Hacker News
Phân tích liên quan được tổng hợp trong bài viết này
Google nói rằng họ sẽ chặn các key bị lộ, nhưng ngay từ đầu họ đã không coi các key đó là bí mật
Lý tưởng nhất là mọi key được tạo trước khi Gemini ra mắt phải bị chặn truy cập Gemini
Nếu hệ thống phát hiện rò rỉ tạo ra cảnh báo sai, thì ngay cả các Gemini key hợp lệ cũng có nguy cơ bị chặn
Tối thiểu phải gỡ quyền Generative Language API khỏi tất cả các key hiện có, nhưng như vậy vẫn chưa phải giải pháp hoàn chỉnh
Cuối cùng có thể sẽ phải gỡ quyền đó hàng loạt khỏi mọi key
Điều này sẽ làm hỏng vô số ứng dụng, và đó là lý do Google không muốn thừa nhận vấn đề
Nghiêm trọng hơn nữa là key còn làm lộ cả cached context và dữ liệu tải lên
Có người phát hiện các Google key được hardcode trong những image Android cũ thực sự có thể dùng với Gemini
Một số đã bị giới hạn tốc độ do quá nhiều người sử dụng, nhưng vài key vẫn còn hoạt động
Khoảng hai tháng trước, các key này bị xem là đã rò rỉ và đều bị vô hiệu hóa
Những key được tạo từ lâu ban đầu chỉ dành cho các dịch vụ bị giới hạn như Firebase hoặc Firestore
Nhưng sau khi Gemini ra mắt, quyền truy cập Gemini lại được tự động bật cho cả các key cũ, khiến việc lạm dụng trở nên dễ dàng hơn
Tức là các public key nằm trong file APK bỗng nhiên trở thành key truy cập Gemini
Ví dụ, nếu nhà phát triển X tạo key cho Maps, rồi nhà phát triển Y bật Gemini trong cùng dự án đó
thì key của X sẽ có quyền truy cập Gemini
Vì vậy cần tránh tái sử dụng project và dùng các GCP project tách biệt cho từng dịch vụ
Người ta đặt câu hỏi vì sao một lỗ hổng bảo mật rõ ràng như vậy lại không bị chặn từ trước
Với một tập đoàn lớn như Google thì lẽ ra phải có kiểm thử hoặc đặc tả chuẩn hóa
Càng lớn và càng phức tạp, tổ chức càng dễ xuất hiện những điểm mù giám sát
nhưng họ vẫn chỉ chăm chăm vào bài toán đảo ngược cây nhị phân
Vụ việc này gợi nhớ đến những lần lạm dụng SSN (số an sinh xã hội) trong quá khứ
Ban đầu nó chỉ là số định danh đơn thuần, nhưng đến một lúc nào đó lại bị dùng như khóa xác thực, khiến vấn đề phình to
Cấu trúc ở đây cũng tương tự: làm cho nhanh và rẻ, rồi cuối cùng chi phí bị đẩy sang cho người dùng
Có vẻ Google vẫn chưa khắc phục hoàn toàn vấn đề này
Đây là một sai lầm lớn do vội vàng tung Gemini ra thị trường,
và để sửa thì có thể phải vô hiệu hóa các key cũ, làm hỏng workflow của khách hàng
Với Google, đây cũng là một tổn hại hình ảnh rất nghiêm trọng
Đây là một dạng vấn đề mở rộng đặc quyền hồi tố (Retroactive Privilege Expansion)
Bạn từng công khai một Maps key cũ trên website, nhưng nếu một nhà phát triển khác trong nhóm bật Gemini
thì public key đó lập tức trở thành thông tin xác thực để truy cập Gemini
Kết quả là bất kỳ ai cũng có thể dùng key đó để truy cập file upload hoặc dữ liệu cache
Những người dùng đã làm theo tài liệu cũ và dùng public key đang là bên chịu thiệt
Kẻ tấn công có thể đánh cắp key đó và gây ra hóa đơn tính phí khổng lồ
Nói đơn giản thì, hàng nghìn API key cũ từ chỗ chỉ là token tính phí
đã đột ngột biến thành thông tin xác thực truy cập Gemini
Maps API key vốn được thiết kế để cung cấp dịch vụ bản đồ cho người dùng trong khi phí được tính vào thẻ của tôi
Vấn đề là giờ các key đó cũng có thể truy cập Gemini
Lẽ ra phải tạo project nội bộ riêng để tách key,
nhưng thay vì vậy người ta triển khai thật nhanh, dùng nguyên mã do LLM sinh ra, rồi khi có sự cố lại đổ lỗi cho Google
Nghiên cứu trước đây của công ty bảo mật đã phân tích vấn đề này cũng rất ấn tượng
Ví dụ như bài “Anyone can Access Deleted and Private Repository Data on GitHub”
từng chỉ ra lỗ hổng truy cập dữ liệu kho lưu trữ GitHub đã xóa hoặc riêng tư
Lần này, phân tích của họ cũng đã giúp ích rất nhiều