根据mitre.org上的CVE-2021-44228注释：
Java 8u121（参见 https://www.oracle.com/java/technologies/javase/8u121-relnotes.html）通过默认“com.sun.jndi.rmi.object.trustURLCodebase”和“com. sun.jndi.cosnaming.object.trustURLCodebase”为“假”。
因此，假设默认设置到位，如果应用程序在 JRE/JDK 8u121 或更高版本上运行，我的面向 Web 的应用程序是否可以免受此漏洞引入的威胁？
不，您确实需要更新 log4j。
以下是LunaSec 公告的摘录：
根据这篇博文（参见翻译），JDK 版本大于
6u211、7u201、8u191、 并且11.0.1不受 LDAP 攻击向量的影响。在这些版本com.sun.jndi.ldap.object.trustURLCodebase中，设置为false意味着 JNDI 无法使用 LDAP 加载远程代码。但是，还有其他针对此漏洞的攻击媒介可能导致 RCE。攻击者仍然可以利用服务器上的现有代码来执行有效负载。这篇博客文章
org.apache.naming.factory.BeanFactory讨论了针对 Apache Tomcat 服务器上的类的攻击。
看起来 8u121 中的更改有所帮助，但它并不能完全阻止 RCE。建议升级 log4j，不要相信 Java 更新来修复它。
不，你不安全。目前我们必须假设JDK版本与关闭此漏洞无关。
反正我会说，安全总比后悔好。我们目前正急于分析和更新我们所有的系统（这是相当多的内部和第 3 方应用程序）以使用 Log4J2 2.16 或将它们完全从 Log4J 中移除（例如，迁移到 Logback 或公共日志记录，以更容易实现为准）迅速）。
由于在大多数应用程序中当然都存在大量对旧版本的临时依赖，这意味着不仅要更改您的直接依赖关系，还要在您的 Maven（或其他）构建文件中添加大量排除项，以确保不会引入旧版本在引擎盖下。
在所有的工作中似乎大多是相当简单的，只是乏味的。
可能不是，至少根据：
https://twitter.com/marcioalm/status/1470361495405875200
基本上，java 属性更改意味着它不会将远程类加载到类路径上。然而，上面链接的帖子表明，远程服务器可以只返回一个带有标准序列化攻击的有效负载（利用任何可用于导致不受信任的代码执行的大量“小工具”类）。