Log4j-core
Уязвимости
4
Эксплуатируемые
0
Макс. CVSS
6.9
Макс. EPSS
0.0086
Распределение по критичности
Критический
0
Высокий
0
Средний
4
Низкий
0
Затронутые диапазоны версий
2.0-alpha1–2.25.42.0-beta9–2.25.32.12.0–2.25.42.21.0–2.25.4
Топ уязвимостей
CVE-2026-34480Apache Log4j Core's XmlLayout https://logging.apache.org/log4j/2.x/manual/layouts.html#XmlLayout https://logging.apache.org/log4j/2.x/manual/layouts.html#XmlLayout https://www.w3.org/TR/xml/#charsets, производящие недействительный XML.
Влияние зависит от используемой реализации StAX:
* Встроенный StAX JRE: Запретные символы молча пишутся на выход, производя деформированный XML. Соответствие парсеров должно отклонять такие документы со смертельным исходным погрешием, что может привести к тому, что системы обработки логов по течению сбросят затронутые записи.
Альтернативные реализации StAX (например, Woodstox https://github.com/FasterXML/woodstox, транзитивная зависимость модуля Jackson XML Dataformat): Исключение брошено во время звонка, и событие журнала никогда не передается в предполагаемый аппаренд, только для внутреннего регистратора состояния Log4j.
Пользователям рекомендуется обновиться до Apache Log4j Core 2.25.4, что исправляет эту проблему, дезинфицируя запрещенные символы перед выводом XML.
CVE-2026-34478Apache Log4j Core's Rfc5424Layout https://logging.apache.org/log4j/2.x/manual/layouts.html#RFC5424Layout, в версиях 2.21.0-2.25.3, уязвим для инъекций журнала через последовательности CRLF из-за недокументированных переименов в атрибуты конфигурации, соответствующие безопасности.
Две различные проблемы затрагивают пользователей потоковых сервисов syslog, которые настраивают Rfc5424Layout напрямую:
* Новый атрибут LineEscape был бесшумно переименован, в результате чего новая линия перестала работать для пользователей TCP-кадрования (RFC 6587), подвергая их воздействию инъекций CRLF в бревно-выпуске.
* Атрибут useTlsMessageFormat был бесшумно переименован, в результате чего пользователи обрамления TLS (RFC 5425) были молча понижены до нерамного TCP (RFC 6587), без выхода новой линии.
Пользователи SyslogAppender не затронуты, так как его настройки атрибуты не были изменены.
Пользователям рекомендуется обновиться до Apache Log4j Core 2.25.4, что исправляет эту проблему.
CVE-2026-34477Исправление для CVE-2025-68161 https://logging.apache.org/security.html#CVE-2025-68161 было неполным: оно адресовано проверке имени хоста только при включении через log4j2.sslVerifyHortName https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyH.stName https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName атрибут <Ssl>.
Хотя атрибут конфигурации checkHostName был введен в Log4j Core 2.12.0, он был молча игнорируется во всех версиях через 2.25.3, что оставляло соединения TLS уязвимыми для перехвата независимо от настроенного значения.
Сетевой злоумышленник может выполнять атаку «человек посередине», когда выполняются все следующие условия:
* Используется SMTP, Socket или Syslog appender.
* TLS сконфигурирован через вложенный элемент <Ssl>.
* Злоумышленник может предъявить сертификат, выданный CA, которому доверяют настроенный трастовый магазин приложения, или по умолчанию трастовый магазин Java, если ни один из них не настроен.
Эта проблема не затрагивает пользователей HTTP-приложения, который использует отдельную проверкуHostname https://logging.apache.org/log4j/2.x/manual/appenders/network.html#Html#Httpender-attr-verifyHotme атрибут, который не подвергался этой ошибке, и проверяет имена хоста по умолчанию.
Пользователям рекомендуется обновиться до Apache Log4j Core 2.25.4, что исправляет эту проблему.
CVE-2025-68161Приложение для гнезда в версиях Apache Log4j Core 2.0-beta9-по 2.25.2 не выполняет проверку имени хоста TLS сертификата однорангового узла, даже при проверкеHostName https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SlConfiguration-attr-verifyHotNameСвойство системыache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName свойство системы истинно.
Эта проблема может позволить злоумышленнику перехватывать или перенаправлять трафик журнала при следующих условиях:
* Злоумышленник способен перехватывать или перенаправлять сетевой трафик между клиентом и регистратором журнала.
*Злоумышленник может предъявить сертификат сервера, выданный сертификационным органом, которому доверяют настроенный трастовый магазин Socket Appender (или по умолчанию трастовый магазин Java, если не настроенный трастовый магазин).
Пользователям рекомендуется обновиться до Apache Log4j Core версии 2.25.3, которая решает эту проблему.
В качестве альтернативного смягчения приложение Socket может быть сконфигурировано для использования частного или ограниченного корня доверия для ограничения набора доверенных сертификатов.