Библиотека OpenSSL шифрует трафик почти везде, от банковских сайтов до промышленных контроллеров. Её ошибки касаются всех, кто пользуется интернетом, а не только разработчиков. 29 сентября 2026 года вышел набор исправлений: четырнадцать уязвимостей в поддерживаемых ветках библиотеки. Одна получила высокую степень опасности, ещё одна среднюю, остальные двенадцать отнесены к низким. Самая серьёзная затрагивает протокол DTLS. Его применяют там, где обычный TLS работает плохо: в видеосвязи, интернет-телефонии, промышленной автоматике и части VPN-решений.
Детали уязвимостей
Механизм CVE-2026-84782 связан с повторной отправкой служебных сообщений. При установке соединения стороны обмениваются рукопожатием, и DTLS умеет передавать такие сообщения частями. Если канал временно переполнен, запись приостанавливается на середине. В этот момент независимо срабатывает таймер повторной передачи. Он требует отправить заново более раннее сообщение, которое уже считается отправленным. Логика берёт тот же внутренний буфер и то же смещение, что и незавершённая запись. Позицию никто не сбрасывает к началу сообщения. Поэтому собеседник получает содержимое, не предназначенное для отправки: обрывки другого, более крупного сообщения. Чтение при этом выходит за границы выделенного буфера.
Последствия двоякие. Либо часть памяти кучи утекает к собеседнику в виде открытого текста, либо процесс падает, наткнувшись на невыделенную область. Второй сценарий даёт отказ в обслуживании. Кроме того, повторная передача затирает служебные счётчики, от которых зависит возобновление приостановленной записи. Когда приложение позже возвращается к прерванной операции, состояние не совпадает с сообщением, и отладочная сборка аварийно завершает процесс.
Вторая по значимости уязвимость, CVE-2026-84783, касается только ветки 4.0. Речь идёт об использовании памяти после её освобождения. Так называют чтение данных, которые программа уже вернула системе. OpenSSL кэширует разобранные расширения сертификата X.509 при первом обращении. В версии 4.0 кэш строится в два этапа: значения вычисляются под блокировкой на чтение, а затем записываются под блокировкой на запись. Блокировка на чтение не мешает другим потокам делать то же самое. Каждый поток, получивший доступ на запись, устанавливает свои результаты и освобождает значения предыдущего потока. Тот поток уже помечен как завершивший работу и мог вернуть указатели вызывающему коду. Обращение по таким указателям приводит к чтению освобождённой памяти и, как правило, к падению процесса.
Опасны здесь только доверенные сертификаты удостоверяющих центров, которые совместно используют все соединения. Если несколько потоков одновременно впервые строят цепочку к одному и тому же корневому сертификату, многопоточный TLS-клиент или сервер, запрашивающий сертификаты у клиентов, может упасть. Сертификаты, присланные собеседником, разбираются отдельно для каждого соединения, поэтому под угрозой они не находятся.
Шесть из четырнадцати уязвимостей приходятся на реализацию QUIC, быстрого транспорта поверх UDP для HTTP/3 и подобных ему протоколов. Здесь преобладают ошибки учёта ресурсов. Стек не проверяет ограничение потока данных на уровне соединения, из-за чего один собеседник заставляет сервер держать в памяти около 100 МБ вместо 768 КБ. Список отзываемых идентификаторов соединения растёт без ограничений, и при отказе подтверждать пакеты очередь разрастается примерно до 400 МБ. Сборка фрагментов потока при беспорядочном приходе пакетов превращается в квадратичную задачу по числу фрагментов. Это даёт нагрузку на процессор при малой пропускной способности атакующего. Отдельная ошибка позволяет удерживать память под буферы пакетов столько, сколько захочет удалённая сторона. Ещё одна связана с неверным подсчётом кредита для непроверенных адресов, что открывает путь к усилению распределённых атак на отказ в обслуживании.
Две уязвимости относятся к утечкам через время выполнения. Первая затрагивает подпись ECDSA и SM2 на эллиптических кривых без отдельной быстрой реализации, например brainpoolP384r1. Вторая проявляется в операциях с ключами SM2 на процессорах ARM64 и RISC-V, где ветвления и обращения к таблицам зависят от секретных битов. В обоих случаях злоумышленник, замеряющий время подписи или расшифрования, постепенно накапливает сведения о секретном одноразовом числе. Собрав достаточно замеров, он может восстановить долговременный закрытый ключ. Кривые P-256, P-384 и P-521 из набора NIST применяют постоянное по времени выполнение и под угрозой не находятся. Рядом стоит ещё одна уязвимость: сертификат размером около 100 КБ с множеством точек распространения списков отзыва заставляет библиотеку выделить сотни мегабайт памяти.
Эксплуатации в реальных атаках разработчики не подтверждают. Все перечисленные проблемы лежат за пределами модуля FIPS, то есть на сертификацию по требованиям регуляторов они не влияют. Исправления вошли в версии 4.0.3, 3.6.5, 3.5.9 и 3.4.8. Для клиентов премиальной поддержки подготовлены 3.0.23, 1.1.1zj и 1.0.2zs. Ветки 3.1, 3.2 и 3.3 сняты с поддержки, их не анализировали, и обновлений для них не будет.
Большинство организаций получает библиотеку в составе дистрибутива или вендорной сборки. Поэтому разумнее дождаться пакетов от поставщика операционной системы, чем собирать OpenSSL вручную. После обновления придётся перезапустить службы, динамически связанные с библиотекой, иначе старая копия останется в памяти работающих процессов. Проверить установленную версию поможет команда "openssl version". Самая молодая часть библиотеки, реализация QUIC, продолжает накапливать ошибки учёта ресурсов. Редкие эллиптические кривые и алгоритм SM2 по-прежнему дают утечки по времени. Ветки 1.1.1 и 1.0.2 получают исправления лишь по платной подписке, а это ускоряет неизбежный переезд на актуальные выпуски.
Ссылки
- https://openssl-library.org/news/secadv/20260929.txt
- https://www.cve.org/CVERecord?id=CVE-2026-35189
- https://www.cve.org/CVERecord?id=CVE-2026-35191
- https://www.cve.org/CVERecord?id=CVE-2026-42772
- https://www.cve.org/CVERecord?id=CVE-2026-54872
- https://www.cve.org/CVERecord?id=CVE-2026-54873
- https://www.cve.org/CVERecord?id=CVE-2026-54875
- https://www.cve.org/CVERecord?id=CVE-2026-72897
- https://www.cve.org/CVERecord?id=CVE-2026-75804
- https://www.cve.org/CVERecord?id=CVE-2026-75805
- https://www.cve.org/CVERecord?id=CVE-2026-75806
- https://www.cve.org/CVERecord?id=CVE-2026-77696
- https://www.cve.org/CVERecord?id=CVE-2026-84782
- https://www.cve.org/CVERecord?id=CVE-2026-84784
- https://www.cve.org/CVERecord?id=CVE-2026-35189
- https://www.cve.org/CVERecord?id=CVE-2026-35191
- https://www.cve.org/CVERecord?id=CVE-2026-42772
- https://www.cve.org/CVERecord?id=CVE-2026-54872
- https://www.cve.org/CVERecord?id=CVE-2026-54873
- https://www.cve.org/CVERecord?id=CVE-2026-54875
- https://www.cve.org/CVERecord?id=CVE-2026-72897
- https://www.cve.org/CVERecord?id=CVE-2026-75804
- https://www.cve.org/CVERecord?id=CVE-2026-75805
- https://www.cve.org/CVERecord?id=CVE-2026-75806
- https://www.cve.org/CVERecord?id=CVE-2026-77696
- https://www.cve.org/CVERecord?id=CVE-2026-84782
- https://www.cve.org/CVERecord?id=CVE-2026-84784