Уязвимость высокой степени опасности в реализации DTLS затрагивает все поддерживаемые ветки OpenSSL, включая 4.0, 3.6, 3.5, 3.4, 3.0, 1.1.1 и 1.0.2. Удалённый собеседник может получить содержимое памяти процесса в открытом виде либо уронить его. Вендор отнёс проблему к уровню High, идентификатор - CVE-2026-84782. Бюллетень опубликован 29 сентября 2026 года.
Узявимость CVE-2026-84782
DTLS - это TLS поверх транспорта без гарантии доставки, чаще всего поверх UDP. Пакеты там теряются, поэтому протокол умеет отправлять сообщения рукопожатия повторно. Именно на этом механизме и спотыкается библиотека.
Приложение пишет сообщение рукопожатия несколькими фрагментами. Когда транспорт временно не принимает данные, запись замирает на середине. В этот момент срабатывает таймер повторной отправки, и OpenSSL решает переслать более раннее сообщение из очереди. Позицию чтения в буфере при этом не сбрасывают, поэтому повтор начинается с того места, где остановилась незавершённая запись. Собеседник получает сообщение с чужой меткой, а его тело состоит из остатков другого, более крупного сообщения, которое ещё не ушло. Часть этих байтов лежит за границей выделенного буфера.
Отсюда два следствия. Первое - раскрытие данных: в рукопожатие попадают остатки памяти, оказавшиеся там раньше. Речь идёт о фрагментах структур приложения или библиотек, а не о предсказуемом наборе байтов. Надёжного чтения произвольной памяти вендор не подтверждает. Второе - падение процесса. Если чтение уходит в незанятую область, приложение аварийно завершается. Для сервиса, принимающего DTLS-трафик от кого угодно, это готовый способ вызвать отказ в обслуживании.
Есть и третий слой, уже внутри самой библиотеки. Повторная отправка переписывает служебные данные, по которым приостановленная запись должна продолжиться. Когда приложение возвращается к ней и снова вызывает чтение, запись, установку или подключение, состояние не совпадает с сообщением. В отладочных сборках процесс на этом останавливается.
Чтобы всё это сработало, приложение должно писать рукопожатия фрагментами и работать с транспортом, который временно отказывает в приёме данных. Обычный TLS таких условий не создаёт. Зато долгие DTLS-сессии с непрерывным обменом подходят идеально.
DTLS встречается там, где важен обмен в реальном времени: в VPN, IP-телефонии, системах видеосвязи, промышленных шлюзах и многочисленных устройствах интернета вещей. Многие из них годами несут в себе старые сборки OpenSSL. Обновить прошивку роутера или камеры сложнее, чем пересобрать серверное приложение. Поэтому у проблемы долгий хвост.
Тем же бюллетенем вендор закрыл ещё одну ошибку в OpenSSL 4.0 - CVE-2026-84783. При первом одновременном использовании одного и того же сертификата удостоверяющего центра несколькими потоками кэш его расширений может освободиться, пока другой поток ещё держит на него указатели. Многопоточный клиент или сервер, запрашивающий сертификаты у клиентов, рискует упасть. Уровень - Moderate, остальные ветки не затронуты.
Остальные записи бюллетеня относят к низкому уровню. В стеке QUIC несколько ошибок ведут к неконтролируемому росту памяти: соединение может занять около 100 МБ вместо положенных 768 КБ, а поток новых идентификаторов соединения при отказе подтверждать пакеты - сотни мегабайт. Ещё одна ошибка заставляет стек тратить процессорное время квадратично от числа фрагментов, если пакеты приходят вразнобой. В QUIC-сервере без проверки адреса нарушен лимит усиления трафика, оговорённый в RFC 9000. Ни одна из этих проблем не даёт доступа к чужим данным, но каждая помогает вывести узел из строя.
Дальше идут утечки через время выполнения. Подписи SM2 считаются переменным по времени кодом, а на ARM64 и RISC-V то же самое происходит с оптимизированной реализацией. Эллиптические кривые без выделенной реализации, например brainpoolP384r1, тоже выдают секрет через замеры времени. Кривые NIST P-256, P-384 и P-521 этим не страдают, поскольку для них написан отдельный код с постоянным временем работы. Замеров для атаки нужно очень много, и на практике такой канал редко используется против обычных сервисов.
Отдельная группа ошибок затрагивает протокол CMP, обработку длины записей DTLS 1.2 и переключение контекста во время рукопожатия. Все они требуют редких условий или неудобной для злоумышленника конфигурации, поэтому их оценка ниже.
Исправления вышли в сборках 4.0.3, 3.6.5, 3.5.9 и 3.4.8. Ветки 3.0, 1.1.1 и 1.0.2 поддерживают только по платной подписке, для них подготовили 3.0.23, 1.1.1zj и 1.0.2zs. Модуль FIPS не затронут ни одной из перечисленных уязвимостей: весь уязвимый код лежит за его границей. Об ошибке в DTLS 17 августа 2026 года сообщил Лоран Гаффи из SecuRizon, исправление подготовил Райан Хупер. Ветки 3.1, 3.2 и 3.3 не проверяли, их сняли с поддержки.
Администраторам стоит найти сервисы, которые принимают DTLS-соединения из интернета, и обновить как системные пакеты, так и библиотеки, встроенные в приложения. Проверку адреса в QUIC-серверах тоже лучше включить: без неё чужой трафик можно направить на усиление распределённой атаки. Встраиваемым устройствам обновление придётся ждать от производителя, и это самая медленная часть всей истории.
Ссылки
