Дослідник кібербезпеки Саймон Кьок (Simon Köck) виявив серйозну помилку в платформі Google DevSite, яка використовується для розміщення документації розробників. Через неправильно захищені сесійні cookie зловмисники потенційно могли підробляти сеанси та виконувати довільний код на серверах компанії без входу в обліковий запис. Вразливість зачіпала одразу кілька ресурсів Google, зокрема документацію Android і Firebase.
Проблему виявили під час перевірки механізму авторизації OAuth на сайті developers.google.com. Дослідник звернув увагу на сесійний cookie, який створювався під час переходу до сторінки входу Google. Його розмір становив приблизно 1200 байтів, що здалося незвично великим для даних, які мали містити лише токен безпеки та адресу повернення після авторизації.
Кьок вирішив перевірити вміст cookie й виявив, що вебфреймворк Flask, який використовувала платформа, підписував сесійні дані цифровим підписом, але не шифрував їх. Це означало, що вміст cookie можна було прочитати без знання секретного ключа.
Усередині дослідник знайшов серіалізований об’єкт Python, який містив OAuth client ID та client secret. Найнебезпечнішим виявилося те, що цей самий секрет використовувався платформою як ключ для підписування сесійних cookie.
У своєму технічному звіті дослідник пояснив, що перевірив знайдений секрет як Flask SECRET_KEY і зміг підтвердити справжність підпису.
«Я спробував використати client secret як Flask SECRET_KEY, і підпис виданого cookie успішно пройшов перевірку. Ключ підпису зберігався всередині об’єкта, який він сам підписував», – написав Кьок.
Фактично механізм захисту сесій втратив сенс. Маючи секретний ключ, стороння особа могла самостійно створювати cookie, змінювати їхній вміст і генерувати правильний підпис. Сервер Google при цьому сприймав такі дані як справжні.
Самого витоку секретного ключа було недостатньо для запуску довільного коду. Однак подальша перевірка показала, що механізм OAuth callback використовував функцію pickle.loads() для десеріалізації даних, отриманих із сесійного cookie.
Модуль pickle у Python призначений для збереження та відновлення об’єктів, але має важливу особливість: під час десеріалізації він може виконувати програмний код. Тому обробка через pickle даних, які контролює стороння особа, створює ризик віддаленого виконання коду.
Кьок об’єднав дві помилки в один ланцюжок атаки. Спочатку він використав знайдений секрет для створення підробленого сесійного cookie з правильним підписом, а потім помістив усередину спеціально підготовлений об’єкт Python. Під час обробки OAuth callback сервер перевіряв підпис, приймав дані сесії та передавав їх механізму десеріалізації.
У результаті виникла можливість віддаленого виконання коду (Remote Code Execution, RCE) без попередньої авторизації. Атакувальнику не потрібно було мати обліковий запис Google або доступ до внутрішньої інфраструктури компанії.
Щоб продемонструвати проблему, Кьок вирішив не виконувати довільні системні команди на робочих серверах Google. Натомість він створив тестовий payload, який викликав функцію Python time.sleep() і змушував сервер призупиняти виконання на задану кількість секунд.
Результати перевірки показали чітку залежність між значенням, переданим у підробленому cookie, та часом відповіді сервера. Коли дослідник встановлював затримку на три секунди, відповідь надходила приблизно через 3,19 секунди. Для п’яти секунд час становив близько 5,19 секунди, а для восьми – 8,28 секунди.
Кьок також провів контрольні перевірки, щоб виключити випадкові затримки мережі або сервера. Запити без cookie чи з пошкодженим підписом відхилялися, тоді як спеціально підготовлений cookie із правильним підписом спричиняв очікувану затримку.
«Час відповіді відповідав числу, заданому в pickle», – зазначив дослідник.
Це підтвердило, що сервер дійсно виконував переданий код під час десеріалізації, а не лише приймав підроблену сесію.
Проблема не обмежувалася сайтом developers.google.com. Вразливий механізм використовувався у спільній платформі DevSite, на якій працюють різні ресурси з документацією для розробників.
Під час перевірки Кьок підтвердив, що той самий ключ дозволяв створювати дійсні сесії на інших ресурсах Google, зокрема:
http://firebase.google.com
developer.android.com
source.android.com
docs.partner.android.com/
Таким чином, помилка в одному компоненті авторизації могла впливати одразу на кілька сайтів компанії. Водночас у звіті дослідника йдеться про підтвердження технічної можливості експлуатації, а не про зафіксовані атаки зловмисників на ці ресурси.
Про знайдену вразливість Кьок повідомив Google 6 серпня 2026 року. Уже наступного дня компанія опрацювала та прийняла його звіт. 27 серпня досліднику призначили винагороду в розмірі 90 тисяч доларів у межах програми пошуку вразливостей Google.
Згідно з оприлюдненою хронологією, базова винагорода за вразливість віддаленого виконання коду без авторизації становила 75 тисяч доларів. Google збільшила суму на 20% за виняткову якість підготовленого звіту.
Остаточно проблему виправили 7 жовтня 2026 року. Дослідник подякував команді Google Bug Hunters та інженерам DevSite за розслідування й усунення вразливості.
У своєму звіті Кьок також описав заходи, необхідні для запобігання подібним атакам. Серед них заміна скомпрометованих OAuth-секретів, використання окремих ключів підписування для кожного розгортання, зберігання об’єктів OAuth на сервері замість cookie та відмова від pickle під час обробки даних, що надходять від клієнта.
