另一个答案不正确。版本1.x. CVE-2021-4104 也存在漏洞：
在1.x版的Java日志库Apache Log4j中发现了一个缺陷。Log4j 1.x中的JMSAppender易受不受信任数据的反序列化攻击。如果部署的应用程序配置为使用JMSAppender和攻击者的JMS代理，则这使得远程攻击者能够在服务器上执行代码。
要缓解此漏洞，请执行以下操作：
以下是1.x版中此缺陷的可能缓解措施：

• 在Log4j配置中注解掉或删除JMSAppender（如果使用了它
• 从类别路径中移除JMSAppender类别。例如：

zip -q -d log4j-*.jar org/apache/log4j/net/JMSAppender.class

• 限制运行应用程序的平台上的操作系统用户的访问权限，以防止攻击者修改Log4j配置。

由于您使用的是Log4j 1，因此specific vulnerability不在此处。但是，请注意 * Comments on the log4shell(CVE-2021-44228) vulnerability * 中的以下内容：
log4j 1.x是否易受攻击？
鉴于log4j 1.x版仍在广泛部署，可能是log4j 2.x版的10倍，我们一直收到关于log4j 1.x版漏洞的问题。
由于log4j 1.x未在消息级别提供JNDI查找机制，因此不会受到CVE-2021-44228的影响。
但是，log4j 1.x附带了JMSAppender，如果在log4j的配置文件（即 log4j.properties 或 log4j.xml）中启用了该JMSAppender，它将执行JNDI查找。
已经对log4j配置文件具有写访问权限的攻击者需要将JMSAppender添加到被恶意连接参数毒害的配置中。请注意，先前合法使用JMSAppender与攻击者成功发起攻击的能力无关。
另请注意，仅使配置文件中毒是不够的。攻击者还需要强制log4j使用中毒的参数重新加载其配置文件。由于log4j 1.x不提供自动重新加载，中毒的配置文件通常只有在应用程序重新启动时才生效。
然而，虽然这样的攻击并不容易，但也不是不可能的，因此，通过从log4j-1.2.17.jar中删除JMSAppender，使攻击者的工作变得更加困难是有意义的。
如果没有新的log4j 1.x版本，您可以自己从log4j-1.2.17.jar工件中删除JMSAppender。

zip -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class

如果您没有访问“zip”的权限，也可以使用“jar”命令。

# assuming log4j-1.2.17.jar exists in current directory

mkdir tmp
cd tmp
jar xvf ../log4j-1.2.17.jar
rm org/apache/log4j/net/JMSAppender.class
jar cvf ../log4j-1.2.17-patched.jar .

不用说，一旦log4j-1.2.17.jar打了补丁，您就需要部署它。