Критична уязвимост в споделената платформа DevSite на Google е можела да позволи на неавтентифициран атакуващ да фалшифицира сесийни бисквитки на Flask и да предизвика отдалечено изпълнение на код в няколко уебсайта за разработчици, собственост на Google, според изследователя Simon Koeck.

Проблемът е засягал процеса по OAuth автентикация, използван от сайтовете за документация за разработчици на Google, включително developers.google.com, firebase.google.com, developer.android.com, source.android.com и docs.partner.android.com.

Според информацията Google е отстранил уязвимостта на 7 октомври 2026 г., след като е получил доклада през август и е възнаградил изследователя с 90 000 долара чрез своята програма Vulnerability Reward Program.

Веригата от грешки е започвала със сесийна бисквитка на Flask, издадена от крайната точка за OAuth на DevSite. Стандартният механизъм за сесии на Flask подписва бисквитките, за да ги защити от промени, но не криптира съдържанието им.

Това означава, че потребителите могат да четат съхранените данни, въпреки че не могат да ги променят без тайния ключ за подписване на сървъра. Документацията на Flask посочва, че SECRET_KEY се използва за сигурно подписване на сесийни бисквитки и други чувствителни за сигурността данни.

В този случай бисквитката е съдържала повече от CSRF токен и URL адрес за връщане. След декодиране на компресираните данни изследователят е открил сериализиран обект от процеса по OAuth автентикация, който е включвал Google OAuth client ID и client secret.

Критична уязвимост в Google DevSite

Откритието е станало още по-сериозно, когато Simon Koeck е потвърдил, че разкритият OAuth client secret е служил и като ключ за подписване на сесиите на Flask, излагайки ключа директно в сесийните данни.

Всеки, който се сдобие с бисквитка, е можел да извлече тайната, да генерира нов валиден подпис и да създаде фалшифицирана сесия, на която сървърът би се доверил. Това е премахнало основната мярка за сигурност, защитаваща приложението от манипулиране на сесията от страна на клиента.

Само по себе си фалшифицирането на сесия е можело да позволи на атакуващите да променят стойности, съхранявани в сесията на Flask. Рискът от изпълнение на код обаче е произтичал от начина, по който OAuth callback функцията на DevSite е обработвала обект, съхранен в тази сесия.

Съобщава се, че приложението е декодирало данните от OAuth потока с Base64 и ги е подавало към функцията pickle.loads() на Python. Документацията на Python предупреждава, че модулът pickle не е защитен и че разработчиците трябва да десериализират само данни, на които имат пълно доверие, тъй като злонамерен сериализиран код може да изпълни команди, докато се възстановява.

Следователно атакуващ с ключа за подписване е можел да създаде валидна сесия, съдържаща специално изработен pickle обект. Когато обратната връзка за OAuth обработи фалшифицираната бисквитка, тя би потвърдила подписа, би извлякла контролирания от атакуващия обект и би го десериализирала с pickle. Това е можело да доведе до изпълнение на произволен код на сървъра, избран от атакуващия.

Simon Koeck не е изпълнявал системни команди върху инфраструктурата на Google. Вместо това концептуалната демонстрация (PoC) е използвала безвреден код, въвеждащ забавяне във времето.

Заявките, съдържащи фалшифицирания код, са се забавяли с точния брой секунди, посочен в сериализирания обект, показвайки, че сървърът е обработил данните и е изпълнил избраната функция на Python.

Това е била особено опасна верига, тъй като не се е изисквал профил в Google за достъп до крайната точка за OAuth оторизация и получаване на сесийната бисквитка. Проблемът е засягал и споделена платформа, а не единичен изолиран сайт, разширявайки потенциалното си въздействие върху редица уеб ресурси на Google за разработчици.

Предишните мерки на Google за отстраняване на критични уязвимости за изпълнение на код в облака показват защо тази категория получава висок приоритет в програмите за възнаграждение за уязвимости. В отделен случай от 2026 г. Google коригира уязвимост с оценка CVSS 10.0 в Application Integration, която позволяваше отдалечено изпълнение на код в продукционни среди.

Случаят съчетава няколко опасни архитектурни решения. Първо, бисквитката от страна на клиента е съдържала чувствителни OAuth данни. Второ, разкритата тайна на OAuth е била използвана повторно като таен ключ за подписване на Flask. Трето, приложението е десериализирало контролирани от сесията данни с pickle, което е небезопасно, щом атакуващ успее да заобиколи проверките за цялост.

Simon Koeck заяви, че Google е решил проблема чрез подмяна на компрометираните клиентски тайни за OAuth, анулиране на сесиите, подписани с тях, разделяне на стойностите на SECRET_KEY във Flask от идентификационните данни за OAuth и преместване на обектите от OAuth процеса в хранилище от страната на сървъра.

По-сигурният дизайн изисква бисквитката на браузъра да носи само непрозрачен идентификатор на сесията, докато чувствителното състояние остава на сървъра.

Разработчиците трябва също така да премахнат pickle от пътищата на данни, върху които браузър, потребител, партньорска интеграция или външна система могат да повлияят. JSON или друг формат само за данни, съчетан със стриктна валидация на схемата, предотвратява превръщането на десериализацията в изпълнение на код.

Инцидентът с DevSite на Google е поредното напомняне, че подписаната сесия е надеждна само когато ключът за подписване остава таен и приложението никога не превръща контролирани от атакуващ сесийни данни в изпълними обекти.