Утечка ключей Google API обернулась счетами на $128 тыс. за Gemini

Счёт на $82 314 за 48 часов — рост в 455 раз относительно базового уровня расходов — это самый наглядный факт в этой истории. Речь идёт не о неправильно настроенном cron-задании и не о вышедшем из-под контроля тестовом окружении. Небольшая команда из Мексики наблюдала, как их облачный счёт увеличился примерно на три порядка, потому что ключ, который им говорили безопасно встраивать, оказался живым токеном для инференса Gemini. Этот сценарий повторился в трёх задокументированных инцидентах и 22 приложениях, а архитектурная первопричина — на стороне Google, а не разработчиков.

Цифры

Главная цифра — $128 000 несанкционированного использования Gemini API в одной японской компании, как сообщал TechRadar, — и у этой компании были ограничения по IP на уровне файрвола. Белый список IP-адресов не остановил злоупотребления. Этот факт важнее суммы в долларах, поскольку говорит нам: поверхность атаки — это не проблема сетевого уровня.

Два других инцидента задают диапазон. Независимый разработчик в первом случае отозвал скомпрометированный ключ в течение нескольких минут после первого уведомления о выставлении счёта, однако счётчик всё равно остановился на $15 400 из-за задержки отчётности в Google Cloud Billing. Мексиканская команда набрала $82 314 за 48 часов — рост в 455 раз относительно нормального уровня. Три точки данных, три разных модели реагирования, и все три обернулись потерями от четырёх до шести знаков.

Поверхность уязвимости шире, чем следует из описанных случаев. Исследования CloudSEK выявили 32 открытых ключа Google API в 22 Android-приложениях, а у этих 22 приложений совокупная аудитория превышает 500 миллионов пользователей. В числе затронутых приложений — OYO Hotel Booking, Google Pay for Business, Taobao и ELSA Speak. Конкретно по ELSA Speak исследователи подтвердили: они могли получить доступ к отправленным пользователями аудиофайлам через Gemini Files API, — то есть последствия не ограничиваются только счетами, речь идёт и о пользовательских данных.

Для понимания масштаба: 500 миллионов установок — это примерно население Европейского союза и Великобритании вместе взятых. Даже если лишь часть этих установок находится в регионах, где ключи можно успешно извлечь и проксировать, доступный злоумышленникам пул бесплатных AI-вычислений огромен. В источнике не раскрывается, сколько из 32 ключей активно эксплуатируются, а сколько лишь обнаружены, — а эта граница важна: если уровень злоупотреблений составляет 5%, инцидент локализован; если 50%, нас ждёт волна неприятных сюрпризов в счетах за третий квартал, которые ещё не попали в публичные раскрытия.

Если данная закономерность сохранится, я предсказываю как минимум ещё два публичных случая несанкционированных счетов за Gemini на пять и более знаков от конкретных компаний — до конца третьего квартала 2026 года.

В чём подлинная новизна

Ключевой элемент здесь — скрытое повышение привилегий. Тухин Бозе, исследователь CloudSEK, руководивший работой, сформулировал прямо: «Проблема не в халатности разработчиков; реализации соответствовали предписанным Google рекомендациям». Бозе охарактеризовал архитектуру как фактически превратившую несекретные идентификаторы в токены аутентификации, создав системную уязвимость в многочисленных приложениях. Эту формулировку стоит перечитать дважды.

Встраивание API-ключей для Maps или Firebase в клиентский Android-код является стандартной практикой уже десятилетие. Собственная документация Google исторически рассматривала эти ключи как малочувствительные идентификаторы, поскольку их область действия ограничивалась конкретными, преимущественно read-only или rate-limited сервисами. Тайлы карт загружались, конфиги Firebase читались, всё шло своим чередом. Подразумеваемый договор был таким: это публичные идентификаторы с ограничениями, а не bearer-токены.

Этот договор нарушился, когда те же ключи на уровне проекта получили живой доступ к Gemini. Разработчики, выпустившие приложения в 2022 или 2023 году, не соглашались на риск AI-биллинга, и в источнике нет свидетельств того, что Google отправлял уведомления или запросы на подтверждение в момент этого повышения. Учётные данные в 22 рабочих приложениях тихо превратились в нечто более мощное, чем то, на что подписывались их авторы, — а приложения продолжают поставлять эти ключи через циклы обновлений. Уязвимость может сохраняться после обновлений приложения: разработчик, исправивший ключ в версии 4.2, по-прежнему имеет установки версии 4.1, генерирующие вызовы Gemini.

Сравните это со стандартным сценарием утечки учётных данных: разработчик коммитит ключ доступа AWS на GitHub, GitGuardian обнаруживает это в течение нескольких минут, AWS автоматически отзывает ключ, общий ущерб ограничен. Этот процесс предполагает, что утёкший ключ всегда был чувствительным. Здесь же ключ в момент утечки не был чувствительным. Он стал чувствительным ретроактивно, и ни одна система обнаружения не следила за этим переходом. В источнике не раскрывается, есть ли у Google внутренняя телеметрия, которая отмечает аномальные паттерны вызовов Gemini с ключей, ранее обращавшихся только к Maps или Firebase, — а это очевидный контроль, о котором стоит спросить.

Проверяемый прогноз: если Google выпустит исправление в течение следующих 90 дней, ожидайте, что оно примет форму обязательного разделения на уровне проекта между устаревшими сервисными ключами и доступом к Gemini, с явным процессом подтверждения. Если нет — ждите коллективных исков от пострадавших разработчиков к четвёртому кварталу.

Что уже учтено в экономике перфоманс-маркетинга

Для команд, занимающихся платным привлечением, актуальный вопрос — как это влияет на экономику трафика мобильных приложений. Кампании по установкам приложений через Google Ads API зависят от данных о конверсиях, поступающих от SDK, которые зачастую разделяют проектное пространство с той же поверхностью API-ключей, которую исследовала CloudSEK. Рынок уже учёл риск утечки учётных данных на уровне SDK для измерения рекламы — именно поэтому серверные API конверсий и агрегированная отчётность стали основным направлением развития с 2022 года. Что не учтено — это идея о том, что сами ключи SDK могут быть использованы для стоимостных атак против издателя, а не только для кражи данных.

Последствия для перфоманс-маркетинга конкретны. Если вы управляете мобильным приложением, монетизированным через рекламу, и встраиваете ключи Firebase или Maps согласно рекомендациям Google, ваша юнит-экономика теперь несёт хвостовой риск, не коррелирующий с вашим трафиком. Один злоумышленник, исчерпавший вашу квоту Gemini, может превысить ваши ежемесячные рекламные расходы: как демонстрирует японский случай, $128 000 — это значительная доля годового бюджета на привлечение пользователей для приложения среднего размера. Финансовые директора, моделирующие LTV против CAC, не учитывали это, потому что до последнего времени этот вектор угрозы не существовал в нынешнем виде.

Что уже учтено: общая хрупкость клиентских учётных данных, необходимость серверного проксирования дорогостоящих API-вызовов и предположение о том, что любой ключ, поставляемый в APK, доступен для перечисления. Зрелые команды годами переносили чувствительные операции за собственные бэкенды. По-настоящему удивительно то, что именно следование задокументированным лучшим практикам Google создало уязвимость, — а значит, стандартный ответ службы безопасности «читайте документацию внимательнее» здесь неприменим.

Контрарная точка зрения

Общепринятая интерпретация будет такой: Google обязан исправить это, а разработчики ни в чём не виноваты. Я бы поспорил с половиной этого утверждения. Да, архитектурное решение о повышении привилегий устаревших ключей без явного согласия — это ответственность Google, и Бозе прав, что реализации соответствовали требованиям. Но более глубокий урок, который отрасль продолжает отказываться усваивать, состоит в том, что любые учётные данные, поставляемые в клиентском бинарном файле, — это учётные данные, переданные публике. Классификация вендора как «чувствительные» или «нечувствительные» — это любезность, а не гарантия, поскольку вендор может переклассифицировать в любое время без вашего участия.

Рассматривать встроенные в клиент ключи как bearer-токены — вне зависимости от того, как их называет документация — единственная защищаемая позиция. Команды, вынесшие дорогостоящие операции за собственные аутентифицированные бэкенды, не пострадали от этого инцидента и не пострадают от следующей вариации. Контрарный вывод: этот инцидент меньше связан с Gemini и больше — с повторяющейся неспособностью проектировать системы с учётом изменений политик на стороне вендора. Ожидайте, что как минимум ещё один облачный провайдер повторит эту схему в течение 18 месяцев — вероятно, с другим AI-сервисом, использующим ранее низкорисковый класс ключей.

Ключевые выводы

• Три задокументированных инцидента привели к потерям в $15 400, $82 314 и $128 000; мексиканский случай означал рост расходов в 455 раз за 48 часов относительно базового уровня. Ограничения по IP на уровне файрвола не предотвратили японские потери.
• 32 открытых ключа в 22 Android-приложениях с совокупной аудиторией 500 млн+ установок, включая OYO, Google Pay for Business, Taobao и ELSA Speak, где аудиофайлы пользователей были доступны через Gemini Files API.
• Первопричина архитектурная: ключи, выданные для Maps или Firebase, тихо получили доступ к Gemini без уведомления или явного согласия, превратив публичные идентификаторы в токены аутентификации.
• Задержка отчётности Google Cloud Billing означает, что даже немедленный отзыв ключа не ограничивает потери. Независимый разработчик отозвал ключ в течение нескольких минут и всё равно остался должен $15 400.
• Открытый вопрос с проверяемой границей: источник не раскрывает, сколько из 32 ключей активно эксплуатируются. Если доля превышает 25%, ждите волны публичных раскрытий счетов на пять и более знаков от конкретных компаний до конца третьего квартала 2026 года.