Дыра в Erlang/OTP: TLS 1.3-клиент принимает сервер без сертификата

Коротко о главном

22 сентября 2026 года команда Erlang/OTP раскрыла критическую уязвимость CVE-2026-89422 (CVSS 9.3, класс CWE-322) в TLS-стеке модуля ssl. Суть проста и опасна: TLS 1.3-клиент, получив в ответе сервера расширение pre_shared_key, которого он сам не запрашивал, считает соединение возобновлённой сессией и полностью пропускает проверку сертификата. В результате ssl:connect возвращает {ok, Socket} к узлу, у которого нет ни валидного сертификата, ни закрытого ключа, ни предыстории. Это позволяет атакующему на пути трафика (MITM) выдать себя за легитимный сервер. Единственная надёжная реакция — немедленное обновление; если вы отвечаете за инфраструктуру, стоит сразу заказать аудит информационной безопасности, чтобы найти все уязвимые узлы.

Масштаб задаёт не сам Erlang, а то, что на нём построено. Стек OTP лежит в основе брокеров сообщений, телеком-платформ, баз данных и языка Elixir с фреймворком Phoenix; уязвимость затрагивает любой вызов ssl:connect, который согласует TLS 1.3 в конфигурации по умолчанию. Это значит, что под ударом исходящие защищённые соединения — обращения к API, межсервисный трафик, подключения к внешним брокерам. Клиенты, жёстко ограниченные TLS 1.2, не затронуты, но полагаться на это как на стратегию нельзя. Проверить, достижимы ли уязвимые сервисы извне, помогает внешний пентест.

Урок шире одного модуля: ошибка живёт в логике конечного автомата рукопожатия, а не в «одной кнопке», и все прежние проверки — путь сертификата, verify_fun, сверка имени хоста, CRL и OCSP — обходятся разом при выполнении одного условия. Именно поэтому подобные дефекты правильнее ловить на этапе разработки под ключ и в регулярном аудите, а не после публикации CVE.

Что именно нашли

CVE-2026-89422 относится к классу CWE-322 — «обмен ключами без аутентификации сторон». В штатном сценарии TLS 1.3 клиент, который хочет возобновить сессию, сам отправляет расширение pre_shared_key в ClientHello; сервер отвечает тем же расширением, и стороны переиспользуют ранее согласованный секрет вместо полной проверки сертификата. Уязвимость в том, что клиент Erlang/OTP принимает pre_shared_key в ServerHello по одному лишь факту его наличия — не сверяя, предлагал ли он PSK вообще.

Технически виновата обработка ответа сервера: tls_client_connection_1_3:handle_server_hello/2 передаёт полученное расширение в tls_gen_connection_1_3:handle_resumption/2, который выставляет флаг resumption = true просто потому, что расширение пришло. Дальше maybe_resumption/1 уводит конечный автомат прямиком в состояние wait_finished, минуя все состояния, отвечающие за работу с сертификатом. В итоге проверка цепочки сертификатов, пользовательская verify_fun, сверка имени хоста, partial_chain, проверка отзыва (CRL) и OCSP-стейплинг не выполняются вовсе.

Ключевая деталь для оценки риска — атакующему не нужны учётные данные и не нужна прежняя сессия. Достаточно оказаться на пути трафика и внедрить в ServerHello незапрошенное расширение. При оценке 9.3 по CVSS это ставит брешь в разряд тех, что закрывают вне очереди: успешная атака означает полноценный man-in-the-middle с расшифровкой и подменой данных, которые приложение считает пришедшими от доверенного сервера.

Кого и какие версии задело

Уязвимость затрагивает Erlang/OTP начиная с версии 22.2 и во всех выпусках вплоть до исправленных сборок. Патчи вышли в трёх ветках: OTP 27.3.4.18, OTP 28.5.0.7 и OTP 29.1.1 — им соответствуют версии модуля ssl 11.2.12.13, 11.6.0.6 и 11.7.7. Обновляться нужно на одну из этих сборок (или новее в своей ветке). Затронута именно конфигурация клиента по умолчанию; узлы, жёстко ограниченные TLS 1.2, под удар не попадают, но это побочный эффект, а не защитная мера.

Отдельно стоит держать в голову экосистему поверх OTP. Проекты на Elixir и Phoenix, менеджер пакетов Hex, а также инфраструктурные продукты, встраивающие рантайм BEAM, наследуют этот же ssl-стек — значит, обновлять придётся не только «чистые» Erlang-сервисы. Сопровождающие Hex уже подняли зависимость до OTP 29.1.1, что даёт ориентир по срочности для всей экосистемы.

Почему обход проверки сертификата так критичен

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

Опасность усиливает то, что дефект срабатывает молча и в конфигурации по умолчанию. Разработчик, который аккуратно настроил verify_fun и сверку имени хоста, вправе считать соединение защищённым — но при выполнении условия уязвимости все эти настройки игнорируются, а ssl:connect возвращает успешный сокет. Никакой ошибки, никакого предупреждения. Это делает брешь особенно коварной для сервисов, которые доверяют исходящим TLS-соединениям как каналу передачи чувствительных данных: платёжные шлюзы, обмен с партнёрскими API, репликация между узлами кластера.

Что делать командам прямо сейчас

Практическая последовательность выглядит так. Во-первых, инвентаризируйте рантаймы: найдите все сервисы на Erlang/OTP и Elixir/Phoenix, включая забытые демоны, воркеры и встроенные BEAM-компоненты в сторонних продуктах. Во-вторых, обновите OTP до 27.3.4.18, 28.5.0.7 или 29.1.1 (либо новее в вашей ветке) в приоритетном порядке — временных обходных путей, кроме перевода клиентов на TLS 1.2, не предусмотрено, а такой перевод сам по себе шаг назад. В-третьих, пересоберите и передеплойте приложения, которые статически линкуют или упаковывают собственный рантайм: обновления системного пакета для них недостаточно.

Дальше — ретроспектива и профилактика. Проверьте, какие исходящие TLS 1.3-соединения делают ваши сервисы, и оцените, что мог бы увидеть или подменить посредник на этих маршрутах. На будущее заложите в CI/CD контроль версий рантайма и зависимостей, чтобы критические патчи ssl подхватывались автоматически, а не вручную. Систематически такие места помогает выявлять внешний IT-аудит — до того, как уязвимый узел найдёт кто-то другой.

Часто задаваемые вопросы

Что такое CVE-2026-89422? Это критическая уязвимость (CVSS 9.3, CWE-322) в TLS-стеке модуля ssl Erlang/OTP. TLS 1.3-клиент, получив незапрошенное расширение pre_shared_key в ServerHello, пропускает проверку сертификата и завершает рукопожатие, принимая соединение с потенциально поддельным сервером.

Какие версии уязвимы и где исправление? Затронуты выпуски начиная с OTP 22.2. Исправления вышли в OTP 27.3.4.18, 28.5.0.7 и 29.1.1 (модуль ssl версий 11.2.12.13, 11.6.0.6 и 11.7.7). Нужно обновляться на одну из этих сборок или новее.

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

Затрагивает ли это Elixir и Phoenix? Да. Elixir, Phoenix, менеджер пакетов Hex и любые продукты, встраивающие рантайм BEAM, используют тот же ssl-стек Erlang/OTP, поэтому обновлять нужно и их.

Источники

Erlang/OTP — Security Advisory GHSA-rgxr-4g4w-j875 / CVE-2026-89422, 22 сентября 2026 года (первоисточник вендора).

OffSeq Threat Radar — CVE-2026-89422: CWE-322 Key Exchange without Entity Authentication in Erlang OTP, 22 сентября 2026 года.

OpenCVE / NVD — запись CVE-2026-89422 (CWE-322, CVSS 9.3), сентябрь 2026 года.