Как гонка вооружений со злоумышленниками привела к самому нелепому сбою года в пятницу.

Глобальная инфраструктура Cloudflare во второй раз за месяц дала серьёзный сбой - и теперь становится ясно, что причина кроется не в атаке, а в спешке закрыть критическую дыру
в популярной JavaScript-библиотеке React, получившую имя React2Shell (CVE-2025-55182).
Ранним утром 5 декабря по восточноамериканскому времени часть сети провайдера буквально потухла: около четверти всего HTTP-трафика, проходившего через узлы Cloudflare, начали возвращать ошибки. По оценке компании, на пике инцидента недоступной оказалась примерно 28% обработанных запросов - это миллионы пользователей и онлайн-сервисов, завязанных на CDN, веб-экран и защитные сервисы платформы. Перебой длился чуть менее получаса, но для сайтов, которые полностью полагаются на Cloudflare, он обернулся полной изоляцией от аудитории.
Позже технический директор Cloudflare Дэйн Кнект в разборе происшествия отдельно подчеркнул, что речь не шла о взломе или внешнем вмешательстве. Отказ, по его словам, спровоцировали изменения в логике обработки HTTP вплоть до байта, которые внедрялись для обнаружения и блокировки новой критической уязвимости в React Server Components. Попытка оперативно встроить фильтры под React2Shell привела к тому, что часть прокси-узлов с устаревшим программным стеком начала падать с ошибками и отвечать клиентам кодом 500.
Риск, из-за которого команда пошла на столь нервную доработку, уже несколько дней остаётся в центре внимания индустрии. React2Shell - это ошибка десериализации, оценённая максимально возможным баллом по шкале CVSS: 10 из 10. Для злоумышленника она особенно привлекательна тем, что не требует ни аутентификации, ни сложной подготовки: достаточно отправить специально сформированный запрос на уязвимый сервис, чтобы удалённо исполнить произвольный код. Под удар попадают не только проекты, использующие сам React, но и целый пласт инфраструктуры вокруг него, включая фреймворк Next.js и популярные сборщики.
Об усилении давления со стороны злоумышленников практически сразу после раскрытия детали начали отчитываться регуляторы и крупные поставщики облачных услуг. Британские власти
официально предупредили, что брешь уже активно эксплуатируется, а американское агентство CISA оперативно добавило CVE-2025-55182 в каталог эксплуатируемых уязвимостей, фактически дав понять администраторам, что затягивать с обновлениями нельзя. Amazon в отдельном уведомлении указал, что группы, связанные с китайскими государственными структурами, приступили к попыткам эксплуатации буквально через несколько часов после публикации информации: среди них упоминаются Earth Lamia и Jackpot Panda, давно фигурирующие в отчётах крупных вендоров.
О масштабах происходящего можно судить по тому, какие действия наблюдают службы охоты за угрозами. В Unit 42, исследовательском подразделении Palo Alto Networks, рассказывают о сканировании интернета на предмет уязвимых инстансов, пробных цепочках удалённого исполнения кода, попытках вытащить из облачных окружений конфигурационные файлы и ключи доступа к AWS, а также об установке загрузчиков, подтягивающих полезную нагрузку с управляющих серверов. Параллельно специалисты Bitdefender прогнозируют, что к гонке очень быстро подключатся операторы вымогательского ПО и первоначальные брокеры доступа, старающиеся занять выгодные позиции в корпоративных сетях, как только в открытом доступе появляются рабочие эксплойты.
Сами программы для атаки распространяются по сети с огромной скоростью. Исследователь Лаклан Дэвидсон, обнаруживший проблему и передавший её разработчикам React, отмечает, что полноценный прототип эксплойта начал циркулировать примерно через 30 часов после раскрытия. Собственные варианты он опубликовал позднее, пообещав в ближайшее время детальный технический разбор механики атаки. Один из рабочих прототипов выложил на GitHub исследователь под ником maple3142, а специалисты Ox Security подтвердили, что код действительно позволяет добиться удалённого исполнения команд на уязвимых конфигурациях и требует немедленного реагирования со стороны тех, чьи сервисы доступны из интернета.
На этом фоне вокруг React2Shell естественным образом сложился шумовой фон из поддельных примеров. В сети множатся проекты, которые выдают себя за эксплойты, но на деле опираются на сценарии, не имеющие отношения к описанному дефекту. Дэвидсон обращает внимание, что многие псевдо-POC используют опасные функции вроде vm.runInThisContext, child_process.exec или fs.writeFile, доступ к которым злоумышленник мог бы получить только в том случае, если разработчик сам сознательно открыл их на сторону клиента, - то есть создал проблему независимо от React2Shell. Подобные проекты вводят защитников в заблуждение и создают ложное ощущение, что проблема уже изучена, хотя на деле организации остаются без корректных способов обнаружения атак.
Возвращаясь к сбою у Cloudflare, становится понятно, насколько болезненно крупнейшие игроки переживают эту гонку вооружений. После прошлой, ноябрьской аварии, которую глава компании назвал худшей с 2019 года и которая тоже была спровоцирована ошибкой в конфигурации, провайдер обещал серьёзно перестроить архитектуру управления настройками. Новый эпизод показывает, что эти обещания пока в процессе реализации. В этот раз команда попыталась расширить размер HTTP-буфера - с 128 килобайт до 1 мегабайта - чтобы перехватывать более громоздкие вредоносные запросы, характерные для атак на React2Shell. Первоначально развёртывание шло штатно, но в тот момент, когда выключили внутренний инструмент тестирования веб-экрана, не рассчитанный на увеличенный буфер, глобальная система распространения конфигураций разослала изменённые параметры по всему периметру буквально за секунды.Недочёт, спрятавшийся глубоко в логике старых FL1-прокси, мгновенно проявил себя: при обработке запросов начинала срабатывать ошибка Lua-скрипта, и все обращения через затронутые узлы заканчивались кодом 500. Под удар попали клиенты, использовавшие этот тип прокси вместе с управляемым набором правил WAF, и этого оказалось достаточно, чтобы доля неуспешных ответов по сети выросла до заметных величин. Интересная деталь: китайский сегмент инфраструктуры Cloudflare в этот раз остался в строю.
Инженерам удалось оперативно вычислить проблемное изменение, откатить его в 4:11 по восточному времени и уже через минуту вернуть трафик к нормальным значениям, но репутационный след от второй подряд крупной аварии останется надолго.
На будущее провайдер обещает ускорить целый ряд изменений: сделать более аккуратным развертывание и версионирование конфигурационных данных, расширить возможности аварийного управления инфраструктурой даже в условиях параллельных сбоев и внедрить подход «fail-open», при котором некорректные файлы настроек не приводят к жёстким отказам, а переводятся в безопасные значения по умолчанию. Пока же компания заморозила все изменения, не относящиеся к критическим мерам защиты, и повторно извинилась перед клиентами и интернет-сообществом за то, что серьёзные сбои повторяются с минимальным интервалом.
Вице-президент по исследованию угроз Radware Паскаль Гененс обращает внимание, что когда речь идёт об открытом программном обеспечении, злоумышленники с достаточными ресурсами могут изучить изменения в коде и восстановить логику атаки даже при скудных официальных комментариях.
При этом часть защитников остаётся в информационном вакууме, ориентируется на неполные или неверные данные, и в итоге внедряет меры, которые не работают. По словам Гененса, «это гонка, и у большего числа игроков на стороне защиты было бы больше шансов выиграть, если бы они сразу получали полный и точный объём информации».
Сочетание стремительно распространяющейся критической ошибки в ключевом элементе веб-стека, реальной активности государственных группировок и нервных реакций крупных инфраструктурных провайдеров вроде Cloudflare показывает, насколько хрупким остаётся привычный облик интернета. И чем чаще под давлением обстоятельств защитные компании будут ломать собственные механизмы ради срочного патча, тем внимательнее, похоже, придётся подходить к тому, как именно мир открытого кода рассказывает о новых дырах в своей основе.


Комментарии
Основная идея, которой руководствовались инженеры, создававшие Интернет, была в том, что сеть должна быть устойчивой, за счет отсутствия единой точки отказа. Некоего "сервера", который можно уничтожить и тем самым отключить сеть полностью или выключить ее крупный сегмент.
И вот мы в 25 году, и время от времени читаем новости как из-за хакерской атаки или нелепой ошибки отключаются большие сегменты Интернета..
Кажется мы опять зашли куда-то не туда..
так капитализм - "это наша корова и мы её доим!!!" ®
А точно корова? Потому что порой это больше напоминает попытку подоить быка....
там не просто корова - там "клондайк" - выше прибыль только наркотики и прочее нехорошее, только тут "всё законно" - ВПК нервно курит в сторонке...
Всё туда. Государства (элиты, власти, дипстейт, масоны как угодно) не допустят какого-либо не контролируемого ими инструмента обмена информацией. Всё прочее - утопия розовых пони.
Этих когоугодно самих более чем достаточно. Толкутся у двери аж ребра хрустят.
Алгоритм "отлажен", в крайний раз когда отличился CrowdStrike, многие побежали на Microsoft Defender. Так и будем бегать.
1. Так "зайдите туда"
2. Сделайте сайт на миллион посетителей
3. Не пользуйтесь Cloudflare или его аналогами
3.1. Оставьте ваш сайт с голым айпишником, открытым в дикий Интернет, без обратного прокси
4. Посмотрим через сколько часов вас заДДоСят к чертям.
Недостаток концепции интернета вскрылся давно - любой прыщавый подросток за 100 баксов может положить любой обычный сервер.
Решение было найдено в виде схемы Cloudflare - запросы до серверов сайтов ходят через 300+ дата-центров с десятками тысяч серверов, ДДоС атаки влетают в них как в стену.
ЗЫ. Предвосхищая возможный вопрос "а как же я живу без Cloudflare", отвечу - Вы нахрен никому не нужны, чтобы тратить на вас деньги ДДоСить ваш айпишник.
А, ну тогда ладно, все заТБМ, работаем дальше!
Ну какие проблемы то, придумайте рабочую схему, миллионером станете. Только что-то не получается пока ни у кого. Уж поверьте - будет альтернатива - с клаудфлейра все убегут.
Госуслуги
Как раз интернет и пережил. Плохо было только CloudFlare. Darpa хорошую сеть разработала.
Кстати, DARPA к интернету имеет очень опосредственное отношение. В основе этих ваших интеренетов лежит сеть NSFnet (созданная фондом науки), которая была больше и быстрее ARPAnet. В 1989 ARPAnet была отключена, а оставшиеся компьютеры были переданы в NSFnet, которую к этому времени уже переименовали в INTERnet.
Ну так связность сети и не потерялась. Сервера же отвечали. То, что отвечали 500-кой - ну так это уже уровень приложения, не транспортный уровень, архитектура сети тут никак не спасет.
Сейчас активно развивается концепция IoT - интернета вещей. В которой как раз такая децентрализация и возводится в принцип.
Но это по определению не коммерческий сегмент. Коммерц просто не захочет упустить контроль.
Если дыра в библиотеке React, то эта проблема будет посерьезнее, чем какой то там сбой в доступе даже у многих. Потому что библиотеку юзают многие, а там дыра размером с Титаник, которую они даже починить быстро не смогли (банальный откат можно было сделать очень быстро). Куда все катится...
React исходно одна большая зумерская дыра.
Когда простая страничка тащит сотни зависимостей из реп по всему миру - это надежный способ обосраться.
У нас в свое время его запретили после того, как мы с ребятами продемонстрировали распределенную атаку (это когда в несколько компонентов делаются "безвредные" коммиты, а при сборке их на одной странице - писец приходит серьезный).
Согласен. А большие серьезные конторы в принципе не должны использовать сторонние библиотеки.
В противостоянии миллионам мелких угроз (хакеры, вымогатели, сканирование уязвимостей) концепция одной стены безопасности всегда будет (а) проигрывать отдельные стычки и (б) нести риск обрушения большого сегмента.
Против комаров не сильно помогает Великая Китайская стена.
По сути можно лишь обеспечивать отдельные условно защищенные независимые друг от друга и не слишком большие пространства безопасности, а по периметру защита будет эволюционировать из пассивной в активную, т.е. не просто самостоятельный поиск уязвимостей извне (банальный осмотр своих стен на предмет трещин), а вычисление потенциальных атакующих и их нейтрализация до начала атаки.
Но тут нужно понимать, что любой виртуальный анонимный агрессор всегда имеет проекцию в физическом мире - конкретные люди и/или организация людей, которые, как правило, уже стоят под физическим контролем либо спецслужб, либо криминальных элементов, а через них тех же спецслужб. Вот и выходит, что борьба идёт между глубоко скрытыми от общественности институтами силового и властного влияния, щупальца которых можно обрубать сколько угодно долго и почти бесконечно, но сути противостояния это не изменит. Можно лишь перевести эту кибервойну из противостояния по линии фронта (а-ля Вторая мировая) в противостояние по всей глубине ЛБС на десятки километров (как это происходит сейчас на СВО).
Отголосок этого явления - фраза из статьи "к гонке очень быстро подключатся операторы вымогательского ПО и первоначальные брокеры доступа, старающиеся занять выгодные позиции в корпоративных сетях" - т.е. ситуация, когда нахождение дыры не приводит к мгновенной атаке, а позволяет занять позицию внутри периметра обороны, чтобы атаковать в любой другой момент времени. Классический FPV-дрон на обочине трассы в 50 км полосе ЛБС на Донбассе.