Уязвимость TDengine с оценкой CVSS 7.5 позволяет без учетных данных уронить сервер базы данных одним специально сформированным сетевым пакетом. По данным Dark Reading, проблема затрагивает open source time-series базу, которую используют в промышленности, IoT, энергетике и автомобильных проектах. Для русскоязычных команд это не абстрактная история про чужой OT: такие базы часто оказываются внутри телеметрии, мониторинга оборудования и платформ, которые «просто работают» годами без лишнего внимания безопасников.
Баг получил идентификатор CVE-2026-42542. Он затрагивает TDengine версий с 3.4.0.0 по 3.4.1.5; исправление вышло в 3.4.1.6. Исследователи Ridge Security нашли проблему при тестировании open source-приложений для IoT и операционных технологий. По их оценке, уязвимость находится в обработке сообщений до аутентификации: сервер еще не проверил, кто к нему подключается, а опасный код уже выполняется.
Технически речь идет об integer underflow — ошибке, при которой вычитание дает значение меньше допустимого диапазона, а система интерпретирует его как очень большое число. В обычном веб-сервисе это неприятно. В базе, которая собирает телеметрию с датчиков, производственных линий или инфраструктурных метрик, это уже может означать слепую зону для эксплуатации. Сервер падает, данные перестают поступать в дашборды, аналитика и алерты остаются без источника. И все это не требует ни пароля, ни установленной сессии.
Особенно неприятная деталь — сетевой контур. TDengine по умолчанию слушает RPC на TCP-порту 6030. Исследователь Ridge Security Ян Чжоу говорит, что атакующему с доступом к этому порту достаточно одного некорректного пакета. По его оценке, воспроизведение атаки по данным из advisory и изменений в патче может занять часы, а не недели. Публичного эксплойта, по данным Ridge Security, пока нет; собственный proof of concept компания публиковать не стала. Признаков эксплуатации в реальных атаках на момент публикации тоже не зафиксировано.
Но отсутствие публичного эксплойта здесь слабое утешение. TDengine заявляет о более чем 730 тыс. запущенных инстансов, а среди клиентов компании упоминаются Siemens, McDonald’s, Sinopec и NavInfo. Это не значит, что все они уязвимы или выставили базу наружу. Но масштаб установки показывает, почему single-packet DoS в такой системе быстро превращается из «ну, база упала» в вопрос устойчивости производственных процессов.
Рекомендация понятная и скучная, как все хорошие рекомендации по безопасности: обновиться до TDengine 3.4.1.6 и ограничить доступ к порту 6030. Если патч нельзя поставить сразу из-за окна обслуживания, зависимости от вендорского appliance или старой интеграции, нужно хотя бы сократить сетевую поверхность: закрыть доступ из лишних сегментов, проверить firewall-правила, убрать прямую доступность из недоверенных сетей, добавить мониторинг попыток подключения. В OT и промышленном IoT «потом обновим» часто означает «после следующего квартального простоя», поэтому сетевые ограничения здесь не косметика, а временный ремень безопасности.
Для разработчиков и платформенных команд эта история еще раз напоминает неприятную вещь: компоненты для хранения временных рядов давно вышли за пределы красивых графиков CPU и температуры. Они становятся частью операционного контура, где отказ базы данных влияет не только на SLA приложения, но и на способность инженеров видеть состояние оборудования. Уязвимость TDengine показывает, что pre-auth парсеры, дефолтные порты и «внутренние» сервисы заслуживают такого же внимания, как публичные API.
Следующий практический вопрос для компаний — не только «обновили ли TDengine», а «знаем ли мы вообще, где он у нас запущен». В средах с IoT-шлюзами, промышленными панелями, вендорскими коробками и самописной телеметрией инвентаризация часто отстает от реальности. Именно там уязвимость TDengine может оказаться не в списке срочных задач, а в слепом пятне, пока один пакет не превратит мониторинг в пустой экран; подробнее о находке написал .