Две уязвимости в Erlang/OTP затрагивают защищённые соединения и разбор сертификатов. Одна из них, CVE-2026-89422, получила 9.3 по шкале CVSS 4.0. Клиент TLS 1.3 принимает сервер, который не предъявил ни сертификата, ни закрытого ключа. Вторая, CVE-2026-65634 с оценкой 8.2, даёт удалённому отправителю способ надолго занять процессор одним полем в сертификате. Исправления вышли 22 сентября 2026 года в выпусках OTP 27.3.4.18, 28.5.0.7 и 29.1.1.
Детали ууязвимостей
Первую проблему вызывает лишнее расширение в ответе сервера. Клиент инициирует рукопожатие и получает ответное сообщение с расширением pre_shared_key (предварительно согласованный ключ), которого сам не предлагал. Расширение означает возврат к прежней сессии, хотя прежней сессии нет. Вместо проверки библиотека ssl помечает соединение как возобновлённое и уходит сразу к финальному шагу. Поэтому проверка цепочки сертификатов, сверка имени узла, списки отзыва CRL и проверка статуса по OCSP не выполняются вовсе. Код, который открывает защищённое соединение средствами библиотеки ssl, получает рабочий сокет, хотя на другом конце нет ни сертификата, ни закрытого ключа, ни сохранённого состояния сессии.
Дальше злоумышленник читает всё, что приложение отправляет. В зону его доступа попадают учётные данные, токены и тела запросов. Ответы он подделывает по своему усмотрению. Атака "человек посередине" здесь не обязательна: подойдёт и роль узла, к которому клиент обращается сам. Поскольку настройки по умолчанию уязвимы, под угрозой любой код, где согласуется TLS 1.3. Это HTTP-клиент, драйверы баз данных и брокеров сообщений, клиенты распределённого Erlang.
Затронуты OTP начиная с 22.2 и библиотека ssl с версии 9.5. Выпуски 27.3.4.18, 28.5.0.7 и 29.1.1 закрывают проблему. Обходной путь один: ограничить клиент TLS 1.2, задав в настройках {versions, ['tlsv1.2']}. Настройки, которая сохраняет TLS 1.3 и снимает риск, нет. Клиенты, работающие только по TLS 1.2, не затронуты.
Проверка сертификата - единственный механизм, который отличает настоящий сервер от подставного. Клиент Erlang применяет её при HTTPS-запросах, подключениях к базам данных, обмене сообщениями между узлами и обращении к платёжным интерфейсам. Если этот шаг пропускается, приложение не получает даже ошибки. Соединение выглядит успешным, сокет открыт, обмен идёт. Заметить подмену со стороны клиента почти невозможно, потому что в журнал попадает обычная запись об удачном подключении.
Вторая уязвимость связана с разбором ASN.1, языка описания структур данных, на котором построены сертификаты X.509. Декодер идентификаторов объектов собирает большое число по байтам, и каждая операция обходится тем дороже, чем длиннее уже собранное значение. Итоговая сложность растёт квадратично. Один идентификатор с продолжением на 262 КБ съедает около 13 секунд процессорного времени на обычном железе. Те же свойства показывают варианты разбора для двоичного кодирования, упакованного представления и описания в JSON. Длина поля почти ничем не ограничена, поэтому размер входа задаёт сам атакующий. Отправителю не нужны ни учётная запись, ни подпись: значение приходит прямо в рукопожатии TLS.
Разбор сертификата идёт до проверки подписи и цепочки доверия. Значит, порядком проверок защититься нельзя. Декодер попадает во все модули ASN.1, где встречается идентификатор объекта, включая структуры открытых ключей. Уязвимы любые службы на Erlang, которые разбирают сертификат собеседника: клиенты TLS по умолчанию и серверы с взаимной аутентификацией. Несколько таких запросов подряд занимают ядра надолго, и служба перестаёт отвечать на остальные обращения.
Проблема с процессором существует с OTP 17.0. Ветки библиотеки asn1 исправлены в 5.3.4.3, 5.4.3.1 и 5.5.2. Про выпуски OTP до 17.0 данных нет: неизвестно, подвержены они или нет. Правки затрагивают две библиотеки сразу, ssl и asn1, поэтому обновлять нужно весь комплект OTP, а не отдельный модуль.
Об эксплуатации в реальных атаках сведений пока нет. Однако Erlang/OTP лежит в основе телекоммуникационного оборудования, брокеров сообщений, систем мгновенного обмена сообщениями и распределённых баз данных. Такие узлы работают круглосуточно, и остановка на десятки секунд уже заметна для абонентов. Потеря аутентификации в TLS-клиенте означает, что перехват трафика не оставляет следов в журналах приложения. Отказ в обслуживании на разборе сертификатов опасен ещё и тем, что не требует никаких учётных данных. Повторяя рукопожатия, можно вывести из строя узел, который не принимает ни одного соединения от посторонних.
Правки вышли сразу в трёх поддерживаемых ветках, что случается нечасто. Обе проблемы опубликованы 22 сентября вместе с выпусками, а описание уязвимости в TLS подробно разбирает цепочку состояний рукопожатия.
Обновление до 27.3.4.18, 28.5.0.7 или 29.1.1 закрывает обе уязвимости. Тем, кто не может обновиться сразу, остаётся временный перевод клиентов на TLS 1.2. Проверить, какой протокол согласует клиент, можно по журналам соединений. Для серверов с взаимной аутентификацией разумно ограничить число одновременных рукопожатий и следить за нагрузкой на процессор. О найденных проблемах сообщили tynus2, Lukas Backström, а также Milad Nasr и Luna Tong из Anthropic.
Обе уязвимости затрагивают не прикладной код, а базовые библиотеки, которыми пользуется почти любой проект на Erlang. Разбор сертификатов и согласование ключей годами остаются местом, где одна неверная ветка условия отменяет всю защиту соединения. Пока обновление не установлено, полагаться на аутентификацию сервера в клиентах Erlang нельзя.
Ссылки
