OpenSSL закрыла уязвимость с утечкой данных из буфера и пакет январских багов: что из этого реально опасно

В OpenSSL вышли исправления для нескольких уязвимостей, и одна из них действительно связана с возможной утечкой чувствительных данных. Речь о CVE-2026-31790, опубликованной 7 апреля 2026 года. По официальному advisory OpenSSL, проблема возникает в механизме RSA KEM RSASVE encapsulation: приложение может отправить удаленной стороне содержимое неинициализированного буфера вместо корректного криптографического результата. Это потенциально ведет к утечке чувствительных данных из предыдущего выполнения процесса.

Суть бага в том, что при ошибке RSA_public_encrypt() возвращает -1, но уязвимый код проверял лишь то, что возвращаемое значение не равно нулю. В результате операция могла ошибочно считаться успешной, длины выходных данных выставлялись как валидные, а вызывающая сторона продолжала использовать содержимое буфера как будто это корректный KEM-шифротекст. Если приложение применяет EVP_PKEY_encapsulate() с RSA/RSASVE на атакерском некорректном публичном ключе и заранее не проверяет этот ключ, атакующему может утечь «старое» содержимое памяти.

OpenSSL указывает, что для эксплуатации нужен достаточно специфичный сценарий: приложение должно использовать именно RSA/RSASVE encapsulation через EVP_PKEY_encapsulate(), причем на непроверенном публичном ключе, который приходит от атакующего. Это не история про «любой HTTPS-сервер на OpenSSL внезапно сливает память». Но если OpenSSL встроена в прикладную криптографическую логику, особенно экспериментальную или постквантовую, риск уже практический. В качестве временного обходного пути проект рекомендует вызывать EVP_PKEY_public_check() или EVP_PKEY_public_check_quick() перед encapsulation.

Патчи уже выпущены. Уязвимость затрагивает ветки 3.6.0–3.6.1, 3.5.0–3.5.5, 3.4.0–3.4.4, 3.3.0–3.3.6 и 3.0.0–3.0.19. Исправления вошли в 3.6.2, 3.5.6, 3.4.5, 3.3.7 и 3.0.20. Отдельно OpenSSL отмечает, что FIPS-модули этой проблемой затронуты, потому что код находится внутри соответствующей границы для затронутых веток.

Напомним про январские уязвимости OpenSSL 2026 года: часть проблем вела к отказу в обслуживании при разборе недоверенных файлов, часть — к деградации TLS, и только одна январская уязвимость имела высокий уровень опасности из-за потенциального выполнения кода.

Самая заметная из январских проблем — CVE-2025-15467. Это High severity: переполнение стека при разборе CMS (Auth)EnvelopedData. При обработке специально сформированного CMS-контента приложение может аварийно завершиться, а в зависимости от защит платформы не исключается и выполнение кода. Но и здесь есть важная оговорка: атакующему нужно заставить приложение разобрать вредоносный CMS-объект.

Еще одна заметная январская уязвимость — CVE-2025-11187 с уровнем Moderate. Она касается проверки MAC в PKCS#12: отсутствие валидации параметров PBMAC1 может привести к переполнению стека, ошибке указателя или NULL dereference. Это в первую очередь проблема для приложений, которые обрабатывают недоверенные PKCS#12-файлы; в обычных сценариях такие файлы чаще считаются доверенными, поэтому severity ниже.

Среди менее опасных, но все равно неприятных багов выделяется CVE-2025-66199. Это история про TLS 1.3 certificate compression: атакующий может заставить соединение выделить до примерно 22 МБ памяти на одно соединение и нагрузить процессор, что способно привести к деградации сервиса или истощению ресурсов. Речь идет о конфигурациях, где скомпилирована поддержка сжатых сертификатов и реально согласуется соответствующее расширение. Для временного снижения риска можно отключить прием сжатых сертификатов через SSL_OP_NO_RX_CERTIFICATE_COMPRESSION.

Отдельно стоит упомянуть и CVE-2026-2673, опубликованную в марте 2026 года. Она не про утечку данных и не про RCE, а про то, что сервер OpenSSL TLS 1.3 может выбрать не ту предпочитаемую группу обмена ключами, если в конфигурации использован DEFAULT в новом синтаксисе group tuples. Риск здесь низкий: это скорее ошибка согласования криптографических параметров, особенно заметная на фоне новых гибридных постквантовых групп.

*

OpenSSL — это криптографическая библиотека, которую используют не только веб-серверы, но и почтовые шлюзы, VPN, прикладные клиенты, системы подписи, менеджеры сертификатов и корпоративные интеграции. Поэтому один и тот же CVE может по-разному проявляться в зависимости от того, как именно библиотека встроена в продукт.

PKCS#12 — формат контейнера для сертификатов и закрытых ключей. Именно на разборе таких файлов завязана часть январских багов OpenSSL 2026 года. Если приложение не принимает внешние PKCS#12-файлы от пользователей или интеграций, риск для него заметно ниже.

CMS — Cryptographic Message Syntax, формат для защищенных криптографических сообщений, включая S/MIME. Высокая январская уязвимость CVE-2025-15467 относится именно к разбору такого контента, а не к обычному HTTPS-трафику.

RSA KEM / RSASVE encapsulation — более специализированный криптографический механизм, чем привычный большинству администраторов TLS. Апрельская уязвимость с утечкой данных затрагивает именно его использование через EVP_PKEY_encapsulate().