CVE-2024 Log4Shell всё ещё актуально в 2025 году стоит ли проверять старые проекты

[platon_crypto77]

Знаю что Log4Shell (CVE-2021-44228) уже несколько лет как известна, но на новом проекте обнаружил что в зависимостях тянется log4j 2.14.1 через транзитивные зависимости какой-то старой библиотеки. Коллеги говорят «да кто нас атакует», но мне неспокойно. Насколько реально эксплуатирование в 2025 году и как быстро это можно исправить?

[lev1814]

«Кто нас атакует» — классика, которая заканчивается инцидентом. Log4Shell по-прежнему активно эксплуатируется: в отчётах CISA и различных threat intel-командах она стабильно входит в топ-5 наиболее используемых уязвимостей уже который год. Автоматизированные сканеры ботнетов проверяют её на всех доступных хостах — это не таргетированная атака, это массовый шум. Чиниться нужно.

[cpp_veteran]

Исправление зависит от ситуации. Идеально — обновить log4j до 2.17.1+ (для Java 8) или 2.12.4+ (Java 7). Если не можешь обновить саму библиотеку (транзитивная зависимость в чужом артефакте) — есть workaround: JVM-флаг `-Dlog4j2.formatMsgNoLookups=true` для версий 2.10+, или переменная среды `LOG4J_FORMAT_MSG_NO_LOOKUPS=true`. Для совсем старых версий (ниже 2.10) помогает удаление класса JndiLookup: `zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class`.

[tanya_pixel80]

Для поиска уязвимого log4j во всём проекте используй `log4j-detector` от Google или `syft` + `grype`. Команда `grype dir:. --only-fixed` покажет все найденные CVE с исправленными версиями — быстро и наглядно. Ещё есть `log4j-scan` от fullhunt — утилита специально под эту CVE с активной проверкой через JNDI-колбэк.

[matvey5884]

Добавлю про SBOM (Software Bill of Materials) — после Log4Shell многие команды начали генерировать манифесты зависимостей и интегрировать SCA (Software Composition Analysis) в CI/CD. Инструменты типа Dependabot, Snyk или trivy в пайплайне автоматически поймают следующую такую проблему ещё до деплоя. Один инцидент типа Log4Shell окупает настройку такого пайплайна с лихвой.

[egor9725]

Ещё момент про транзитивные зависимости в Maven/Gradle: добавь в pom.xml явную зависимость на безопасную версию log4j-core — она override-нет транзитивную. В Maven это называется dependency management, в Gradle — resolutionStrategy. Это быстрый фикс пока разбираешься с первопричиной.