Две техники отказа в обслуживании, получившие общее название CDN Tsunami, используют перевод клиентских запросов HTTP/3 в HTTP/1.1, с которым CDN обращается к исходному серверу сайта. Причина разрыва проста: «CDN не поддерживают сквозной HTTP/3». Испытания охватили Alibaba, Baidu, Cloudflare, Amazon CloudFront, Fastly и Tencent. Все шесть сервисов оказались восприимчивы к HTTP/3 Bandwidth Amplification, HBA, а пять — к HTTP/3 Connection Amplification, HCA. Для атаки достаточно сайта за одним из этих CDN и доступного HTTP/3 на пограничном узле; менять настройки исходного сервера не требуется. При этом утверждение исследователей о включённом по умолчанию HTTP/3 у Cloudflare и Amazon CloudFront спорно: документация Cloudflare лишь объясняет, как включить протокол на любом тарифе, а AWS называет стандартным вариантом новых дистрибутивов CloudFront HTTP/2, обозначенный как http2.
HBA работает через QPACK, формат сжатия заголовков HTTP/3. Клиент передаёт короткий индекс вместо полного заголовка, но HTTP/1.1 такого механизма не знает. CDN приходится восстановить исходное содержимое и отправить его серверу в развёрнутом виде. Несколько байтов на стороне атакующего превращаются в крупный HTTP/1.1-запрос на стороне жертвы. Самый сильный вариант опирается на динамическую таблицу QPACK: злоумышленник сначала посылает большой заголовок, CDN помещает его в таблицу, после чего множество потоков ссылаются на запись крошечным индексом. Alibaba, Baidu и Tencent объявляли таблицу объёмом 4 КБ и допускали отдельную запись размером до 3072 байт.
Максимальное усиление около 350 раз относится только к CDN с динамической таблицей. Строка Baidu в исходных результатах повреждена и сохранилась как «06x»; по контексту речь, вероятно, шла примерно о 350,06×, но точное число подтвердить по опубликованному фрагменту нельзя. У Alibaba измерили 65,8×, у Tencent — 54,08×. Amazon CloudFront без динамической таблицы дал 51,2×, Cloudflare — 48,27×, Fastly — 36,41×. Усиление росло примерно до 64 одновременных потоков, затем снижалось. Авторы связали спад с нагрузкой на процессоры пограничных узлов CDN, хотя замеров CPU в работе нет.
При проверках HBA атакующему требовалось менее 500 Кбит/с против Alibaba, Baidu и Tencent и менее 5 Мбит/с против Cloudflare, CloudFront и Fastly. На исходном сервере расход трафика всё это время превышал 100 Мбит/с. Здесь проходит граница эксперимента: канал сервера искусственно ограничили 100 Мбит/с, канал атакующего — 30 Мбит/с. Испытаний выше этих значений не проводили. Заявление о масштабировании CDN Tsunami на более мощные серверы остаётся расчётным, а не проверенным результатом.
HCA расходует уже не пропускную способность, а запас соединений. Пять CDN открывали TCP/HTTP/1.1-соединение с исходным сервером сразу после получения кадра HEADERS, не дожидаясь тела HTTP/3-запроса. Благодаря мультиплексированию одна клиентская сессия HTTP/3 несёт десятки независимых потоков, и каждый способен породить отдельное серверное соединение. Затем атакующий крайне медленно передаёт DATA, оставляя запросы незавершёнными. Cloudflare избежал HCA: сервис буферизует заголовки и тело целиком и лишь потом подключается к исходному серверу.
Тестовый Apache имел тайм-аут 300 секунд и предел в 256 соединений. Четыре HTTP/3-соединения по 96 потоков создавали 384 соединения с сервером: 4 × 96 = 384. Для Fastly понадобилось 48 соединений по восемь потоков, поскольку сервис ограничивал число серверных подключений десятью на одну HTTP/3-сессию. У обычных клиентов Alibaba задержка доходила до 60 секунд. Baidu и Amazon CloudFront отвечали через 90 секунд кодом HTTP 504 Gateway Timeout, Fastly задерживал ответ до 15 секунд и возвращал HTTP 503 Service Unavailable. Tencent примерно через 10 секунд закрывал клиентское соединение после пробного запроса, не прислав ответа.
Масштаб возможной экспозиции оценивали по поддоменам из Tranco Top 1M. Исследователи перебрали их записи CNAME и NS, сопоставили доменные суффиксы с адресами CDN и проверили кандидатов с помощью aioquic. У шести провайдеров нашлось 151 685 поддоменов, из которых 42 330 ответили по HTTP/3 и были помечены как потенциально уязвимые. На Amazon CloudFront пришлось 17 431, на Cloudflare — 12 371, на Fastly — 11 606. Такой ответ доказывает лишь доступность HTTP/3 на узле CDN. Он не подтверждает, что конкретный исходный сервер можно вывести из строя; чужие серверы за пределами тестового стенда исследователи не атаковали.
Предшественником CDN Tsunami была работа CDN Judo 2020 года о переводе HTTP/2 в HTTP/1.1. Тогда получили усиление около 44× со статической таблицей и 166× с динамической. В случае HTTP/3 и QPACK верхняя оценка поднялась примерно до 350×. Предложенные меры должны внедрять сами CDN: отклонять до пересылки HTTP/1.1-запросы крупнее рекомендуемых 64 КБ, получать HEADERS и DATA целиком перед соединением с сервером, ограничивать число серверных подключений от одной HTTP/3-сессии и закрывать такое подключение после 30 секунд без передачи содержательных данных, независимо от состояния клиентской сессии.
Baidu и Tencent подтвердили сообщения и внедрили предложенные ограничения. Tencent, в частности, сократил число CDN-соединений с исходным сервером и допустимый размер заголовков в динамической таблице QPACK. Baidu выплатил исследователям около 350 долларов, Tencent — около 150 долларов. Alibaba, Cloudflare, Amazon CloudFront и Fastly подтвердили получение материалов и продолжили внутреннее обсуждение. Публикация не сообщает, проверялись ли Baidu и Tencent повторно после исправлений. Неясно также, появятся ли в открытом доступе код атаки и измерительный инструментарий.
У CDN Tsunami нет присвоенных идентификаторов CVE, случаев эксплуатации в реальных атаках тоже не зарегистрировано. Работу подготовили специалисты National University of Singapore, Fuzhou University, University of Sheffield и Johns Hopkins University; индивидуальные имена в доступных материалах не указаны. Доклад запланирован на Symposium on Reliable Distributed Systems, который пройдёт в Риме 22–24 сентября 2026 года.
Отдельную ошибку QPACK 8 июля раскрыл Sébastien Féry из FoxIO. Примерно 260 байт корректного по спецификации трафика могли аварийно завершить любой сервер на XQUIC. Эта библиотека Alibaba реализует QUIC и HTTP/3 для веб-сервера Tengine, используемого в облачной и CDN-инфраструктуре компании; к механике CDN Tsunami уязвимость напрямую не относится. 13 августа OpenSSL Project сообщил о другой проблеме QUIC, CVE-2026-14456 с низкой степенью опасности. Сервер OpenSSL ставил в очередь входящие каналы с неизвестными идентификаторами целевого соединения и не ограничивал их число. Исправление «вводит ограничение для ожидающих соединений»; стандартный предел равен 256.
В ту же неделю Cloudflare выпустил H1 2026 DDoS Threat Report. По формулировке компании, «центр тяжести сместился от ботнет-флудов к отражению и усилению». В первой половине 2026 года DNS-атаки составили 34,3% всей активности на сетевом уровне. CDN Tsunami укладывается в этот сдвиг по механике усиления, но пока остаётся лабораторно подтверждённой техникой с существенными оговорками: оценка 350× доступна не всем провайдерам, пределы выше 100 Мбит/с на сервере не проверялись, сканирование Интернета не доказывало эксплуатацию, а результаты после внедрения защит не опубликованы.
HBA работает через QPACK, формат сжатия заголовков HTTP/3. Клиент передаёт короткий индекс вместо полного заголовка, но HTTP/1.1 такого механизма не знает. CDN приходится восстановить исходное содержимое и отправить его серверу в развёрнутом виде. Несколько байтов на стороне атакующего превращаются в крупный HTTP/1.1-запрос на стороне жертвы. Самый сильный вариант опирается на динамическую таблицу QPACK: злоумышленник сначала посылает большой заголовок, CDN помещает его в таблицу, после чего множество потоков ссылаются на запись крошечным индексом. Alibaba, Baidu и Tencent объявляли таблицу объёмом 4 КБ и допускали отдельную запись размером до 3072 байт.
Максимальное усиление около 350 раз относится только к CDN с динамической таблицей. Строка Baidu в исходных результатах повреждена и сохранилась как «06x»; по контексту речь, вероятно, шла примерно о 350,06×, но точное число подтвердить по опубликованному фрагменту нельзя. У Alibaba измерили 65,8×, у Tencent — 54,08×. Amazon CloudFront без динамической таблицы дал 51,2×, Cloudflare — 48,27×, Fastly — 36,41×. Усиление росло примерно до 64 одновременных потоков, затем снижалось. Авторы связали спад с нагрузкой на процессоры пограничных узлов CDN, хотя замеров CPU в работе нет.
При проверках HBA атакующему требовалось менее 500 Кбит/с против Alibaba, Baidu и Tencent и менее 5 Мбит/с против Cloudflare, CloudFront и Fastly. На исходном сервере расход трафика всё это время превышал 100 Мбит/с. Здесь проходит граница эксперимента: канал сервера искусственно ограничили 100 Мбит/с, канал атакующего — 30 Мбит/с. Испытаний выше этих значений не проводили. Заявление о масштабировании CDN Tsunami на более мощные серверы остаётся расчётным, а не проверенным результатом.
HCA расходует уже не пропускную способность, а запас соединений. Пять CDN открывали TCP/HTTP/1.1-соединение с исходным сервером сразу после получения кадра HEADERS, не дожидаясь тела HTTP/3-запроса. Благодаря мультиплексированию одна клиентская сессия HTTP/3 несёт десятки независимых потоков, и каждый способен породить отдельное серверное соединение. Затем атакующий крайне медленно передаёт DATA, оставляя запросы незавершёнными. Cloudflare избежал HCA: сервис буферизует заголовки и тело целиком и лишь потом подключается к исходному серверу.
Тестовый Apache имел тайм-аут 300 секунд и предел в 256 соединений. Четыре HTTP/3-соединения по 96 потоков создавали 384 соединения с сервером: 4 × 96 = 384. Для Fastly понадобилось 48 соединений по восемь потоков, поскольку сервис ограничивал число серверных подключений десятью на одну HTTP/3-сессию. У обычных клиентов Alibaba задержка доходила до 60 секунд. Baidu и Amazon CloudFront отвечали через 90 секунд кодом HTTP 504 Gateway Timeout, Fastly задерживал ответ до 15 секунд и возвращал HTTP 503 Service Unavailable. Tencent примерно через 10 секунд закрывал клиентское соединение после пробного запроса, не прислав ответа.
Масштаб возможной экспозиции оценивали по поддоменам из Tranco Top 1M. Исследователи перебрали их записи CNAME и NS, сопоставили доменные суффиксы с адресами CDN и проверили кандидатов с помощью aioquic. У шести провайдеров нашлось 151 685 поддоменов, из которых 42 330 ответили по HTTP/3 и были помечены как потенциально уязвимые. На Amazon CloudFront пришлось 17 431, на Cloudflare — 12 371, на Fastly — 11 606. Такой ответ доказывает лишь доступность HTTP/3 на узле CDN. Он не подтверждает, что конкретный исходный сервер можно вывести из строя; чужие серверы за пределами тестового стенда исследователи не атаковали.
Предшественником CDN Tsunami была работа CDN Judo 2020 года о переводе HTTP/2 в HTTP/1.1. Тогда получили усиление около 44× со статической таблицей и 166× с динамической. В случае HTTP/3 и QPACK верхняя оценка поднялась примерно до 350×. Предложенные меры должны внедрять сами CDN: отклонять до пересылки HTTP/1.1-запросы крупнее рекомендуемых 64 КБ, получать HEADERS и DATA целиком перед соединением с сервером, ограничивать число серверных подключений от одной HTTP/3-сессии и закрывать такое подключение после 30 секунд без передачи содержательных данных, независимо от состояния клиентской сессии.
Baidu и Tencent подтвердили сообщения и внедрили предложенные ограничения. Tencent, в частности, сократил число CDN-соединений с исходным сервером и допустимый размер заголовков в динамической таблице QPACK. Baidu выплатил исследователям около 350 долларов, Tencent — около 150 долларов. Alibaba, Cloudflare, Amazon CloudFront и Fastly подтвердили получение материалов и продолжили внутреннее обсуждение. Публикация не сообщает, проверялись ли Baidu и Tencent повторно после исправлений. Неясно также, появятся ли в открытом доступе код атаки и измерительный инструментарий.
У CDN Tsunami нет присвоенных идентификаторов CVE, случаев эксплуатации в реальных атаках тоже не зарегистрировано. Работу подготовили специалисты National University of Singapore, Fuzhou University, University of Sheffield и Johns Hopkins University; индивидуальные имена в доступных материалах не указаны. Доклад запланирован на Symposium on Reliable Distributed Systems, который пройдёт в Риме 22–24 сентября 2026 года.
Отдельную ошибку QPACK 8 июля раскрыл Sébastien Féry из FoxIO. Примерно 260 байт корректного по спецификации трафика могли аварийно завершить любой сервер на XQUIC. Эта библиотека Alibaba реализует QUIC и HTTP/3 для веб-сервера Tengine, используемого в облачной и CDN-инфраструктуре компании; к механике CDN Tsunami уязвимость напрямую не относится. 13 августа OpenSSL Project сообщил о другой проблеме QUIC, CVE-2026-14456 с низкой степенью опасности. Сервер OpenSSL ставил в очередь входящие каналы с неизвестными идентификаторами целевого соединения и не ограничивал их число. Исправление «вводит ограничение для ожидающих соединений»; стандартный предел равен 256.
В ту же неделю Cloudflare выпустил H1 2026 DDoS Threat Report. По формулировке компании, «центр тяжести сместился от ботнет-флудов к отражению и усилению». В первой половине 2026 года DNS-атаки составили 34,3% всей активности на сетевом уровне. CDN Tsunami укладывается в этот сдвиг по механике усиления, но пока остаётся лабораторно подтверждённой техникой с существенными оговорками: оценка 350× доступна не всем провайдерам, пределы выше 100 Мбит/с на сервере не проверялись, сканирование Интернета не доказывало эксплуатацию, а результаты после внедрения защит не опубликованы.