В Log4j 2 обнаружена возможность обойти фильтр десериализации

Уязвимость позволяет обходить фильтры безопасности и удаленно выполнять вредоносный код на серверах. PoC уже появился в открытом доступе. Делимся рекомендациями, как предотвратить эксплуатацию уязвимости

28 августа 2026 г.

В Log4j 2 обнаружен способ обойти allowlist в FilteredObjectInputStream. Проблема связана с java.rmi.MarshalledObject: этот класс разрешен фильтром, но содержимое объекта при распаковке может десериализоваться уже без дополнительной проверки. Из‑за этого сервисы, которые принимают по сети сериализованные LogEvent от недоверенных источников, могут быть уязвимы к небезопасной десериализации. При наличии подходящей цепочки гаджетов на сервере это может привести к удаленному выполнению кода.

По данным опубликованного исследования, затронуты:

log4j‑api 2.11.0–2.26.1;
log4j‑core 2.8.0–2.26.1.

В открытом доступе уже появился PoC с OOB (out‑of‑band) DNS — проверкой, поддержкой RCE‑нагрузок и Nuclei‑шаблоном для поиска доступных сетевых приемников.

Рекомендуем:

Проверить инфраструктуру на наличие сетевых приемников, сериализованных LogEvent, включая TCP Socket Server, SocketAppender и аналоги. Особое внимание — портам 4560/4562/4563/9500, если они доступны из недоверенных сетей.
В качестве временной меры можно использовать параметр при запуске Java‑процесса: ‑Djdk.serialFilter=’!java.rmi.MarshalledObject’. Это блокирует данный путь десериализации, но может нарушить штатную передачу сериализованных LogEvent.
Не рассчитывать только на maxdepth и maxbytes: такие ограничения могут остановить отдельные цепочки гаджетов, но не устраняют сам обход фильтра.

Для пользователей BI.ZОNE WAF уже доступны правила, которые предотвращают попытки эксплуатации.