Недавний сбой в Cloudflare связан с проблемами в коде на языке Lua

5 декабря 2025 года в 08:47 UTC (все время в этом блоге UTC) часть сети Cloudflare начала испытывать значительные сбои. Инцидент был разрешен в 09:12 (~25 минут общего удара), когда все службы были полностью восстановлены.

Пострадало подмножество клиентов, на долю которого приходится примерно 28% всего HTTP-трафика, обслуживаемого Cloudflare. Несколько факторов, которые должны объединиться для отдельного клиента, чтобы быть затронутым, как описано ниже.

Проблема не была вызвана, прямо или косвенно, кибератакой на системы Cloudflare или вредоносной деятельностью любого рода. Вместо этого он был вызван изменениями, внесенными в нашу логику разбора тела, пытаясь обнаружить и смягчить общеотраслевую уязвимость, раскрытую на этой неделе в React Server Components.

Любое отключение наших систем неприемлемо, и мы знаем, что снова подвели интернет после инцидента 18 ноября. На следующей неделе мы опубликуем подробности о работе, которую мы делаем, чтобы остановить подобные инциденты.

Что случилось

На приведенном ниже графике показаны ошибки HTTP 500, обслуживаемые нашей сетью во время периода инцидента (красная линия внизу), по сравнению с не затронутым общим трафиком Cloudflare (зеленая линия вверху).

Веб-приложение Cloudflare Firewall (WAF) обеспечивает клиентам защиту от вредоносных полезных нагрузок, позволяя их обнаруживать и блокировать. Для этого прокси-прокси Cloudflare запрашивает содержимое тела в памяти для анализа. До сегодняшнего дня размер буфера был установлен на 128КБ.

В рамках нашей текущей работы по защите клиентов, которые используют React от критической уязвимости, CVE-2025-55182, мы начали развертывать увеличение нашего размера буфера до 1 МБ, предела по умолчанию, разрешенного приложениями Next.js, чтобы убедиться, что как можно больше клиентов были защищены.

Это первое изменение было развернуто с использованием нашей системы постепенного развертывания. Во время развертывания мы заметили, что наш внутренний инструмент тестирования WAF не поддерживает увеличенный размер буфера. Поскольку этот внутренний инструмент тестирования не был необходим в то время и не влиял на трафик клиентов, мы внесли второе изменение, чтобы отключить его.

Это второе изменение отключения нашего инструмента тестирования WAF было реализовано с использованием нашей глобальной системы конфигурации. Эта система не выполняет постепенное развертывание, а скорее распространяет изменения в течение нескольких секунд на весь парк серверов в нашей сети и находится на рассмотрении после сбоя, который мы испытали 18 ноября.

К сожалению, в нашей версии FL1 нашего прокси, при определенных обстоятельствах, второе изменение отключения нашего инструмента тестирования правил WAF вызвало состояние ошибки, в результате которого из нашей сети было подавалось 500 кодов ошибок HTTP.

Как только изменение распространилось на нашу сеть, выполнение кода в нашем прокси-сервере FL1 достигло ошибки в нашем модуле правил, что привело к следующему исключению Lua:

[lua] Failed to run module rulesets callback late_routing: /usr/local/nginx-fl/lua/modules/init.lua:314: attempt to index field 'execute' (a nil value)

В результате выдается ошибки кода HTTP 500.

Проблема была выявлена вскоре после того, как изменение было применено, и была возвращена в 09:12, после чего все движение было подано правильно.

Клиенты, у которых есть свои веб-активы, обслуживаемые нашим старым прокси FL1, и были затронуты развертыванием Cloudflare Managed Ruleset. Все запросы на веб-сайты в этом состоянии вернули ошибку HTTP 500, за исключением некоторых тестовых конечных точек, таких как /cdn-cgi/trace.

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

Ошибка времени выполнения

Система наборов правил Cloudflare состоит из наборов правил, которые оцениваются для каждого запроса, поступающего в нашу систему. Правило состоит из фильтра, который выбирает некоторый трафик, и действия, которое применяет эффект к этому трафику. Типичные действия – это «block«»log«, или «skip. Другой вид действия – это «execute«, который используется для инициирования оценки другого набора правил.

Наша внутренняя система регистрации использует эту функцию для оценки новых правил, прежде чем мы сделаем их доступными для общественности. Набор правил высшего уровня будет выполнять еще один набор правил, содержащий правила тестирования. Именно эти правила испытаний мы пытались отключить.

У нас есть подсистема killswitch как часть системы наборов правил, которая предназначена для того, чтобы позволить правилу, которое неправильно ведет себя, быстро отключиться. Эта система killswitch получает информацию из нашей глобальной системы конфигурации, упомянутой в предыдущих разделах. Мы использовали эту систему killswitch в ряде случаев в прошлом, чтобы смягчить инциденты и иметь четко определенную стандартную операционную процедуру, которая была соблюдена в этом инциденте.

Однако мы никогда раньше не применяли краш-матч к правилу с действием».execute. Когда был применен killswitch, код правильно пропустил оценку действия выполнения и не оценивал подправили, на который он ссылается. Однако затем была обнаружена ошибка при обработке общих результатов оценки набора правил:

if rule_result.action == "execute" then   rule_result.execute.results = ruleset_results[tonumber(rule_result.execute.results_index)] end

Этот кодекс предполагает, что, если набор правил имеет действие="execute", объект "rule_result.exeute" будет существовать. Однако, поскольку правило было пропущено, объект rule_result.execute не существовал, и Луа вернул ошибку из-за попытки поиска значения в нулевом значении.

Это простая ошибка в коде, который существовал незамеченным в течение многих лет. Этот тип ошибки кода предотвращается языками с сильными типами систем. В нашей замене этого кода в нашем новом прокси-сервере FL2, который написан в Rust, ошибка не произошла.

Как насчет изменений, вносимых после инцидента 18 ноября 2025 года?

Мы внесли несвязанные изменения, которые вызвали аналогичный, более длительный инцидент доступности две недели назад, 18 ноября 2025 года. В обоих случаях развертывание, помогающее смягчить проблему безопасности для наших клиентов, распространилось на всю нашу сеть и привело к ошибкам почти для всей нашей клиентской базы.

Мы напрямую поговорили с сотнями клиентов после этого инцидента и поделились нашими планами внести изменения, чтобы предотвратить одиночные обновления, вызывающие широкое влияние, подобное этому. Мы считаем, что эти изменения помогли бы предотвратить последствия сегодняшнего инцидента, но, к сожалению, мы еще не закончили их развертывание.

Мы знаем, что разочаровывает, что эта работа еще не завершена. Это остается нашим главным приоритетом во всей организации. В частности, проекты, изложенные ниже, должны помочь сдержать влияние таких изменений:

• Улучшенные развертывания и версии: Подобно тому, как мы медленно развертываем программное обеспечение со строгой валидацией здоровья, данные, используемые для быстрого реагирования на угрозы и общей конфигурации, должны иметь те же функции безопасности и смягчения последствий взрыва. Это включает в себя валидацию здоровья и возможности быстрого отката, среди прочего.

• Оптимизированные возможности разбивания стекла: убедитесь, что критические операции все еще могут быть достигнуты в условиях дополнительных типов отказов. Это касается внутренних сервисов, а также всех стандартных методов взаимодействия с плоскостью управления Cloudflare, используемой всеми клиентами Cloudflare.

• «Fail-Open» Обработка ошибок: в рамках усилий по обеспечению устойчивости мы заменяем неправильно применяемую логику жесткой недостаточности во всех критических компонентах Dataflare. Если конфигурационный файл поврежден или не в зоне действия (например, превышает крышки функций), система будет регистрировать ошибку и по умолчанию в известном состоянии или проходной трафик без оценки, а не сбрасывать запросы. Некоторые услуги, скорее всего, дадут клиенту возможность выйти из строя или закрыть в определенных сценариях. Это будет включать в себя возможности предотвращения дрейфа для обеспечения постоянного соблюдения этого.

До конца следующей недели мы опубликуем подробную разбивку всех осуществляемых проектов по обеспечению устойчивости, включая перечисленные выше. Пока эта работа ведется, мы блокируем все изменения в нашей сети, чтобы гарантировать, что у нас есть лучшие системы смягчения последствий и откат, прежде чем мы начнем снова.

Такие инциденты и то, насколько тесно они сгруппированы вместе, неприемлемы для такой сети, как наша. От имени команды Cloudflare мы хотим извиниться за влияние и боль, которые это снова причинило нашим клиентам и Интернету в целом.

Хронология

Источник: blog.cloudflare.com

Комментарии: