所有日志服务软件发布分发都使用来自日志服务 PMC 的密钥使用 GPG 签名KEYS 文件。有关如何验证发布签名的信息将在下载页面中进一步说明。因此，应在您的构建过程中验证 GPG 签名。

应用程序的所有配置源都必须由程序员信任。从磁盘加载配置文件时（尤其是在配置监视器间隔以定期重新加载文件时），配置文件的位置必须保持安全，防止未经授权的修改。同样，在通过网络（例如通过 HTTP）加载配置文件时，应将其配置为使用 TLS 或一般具有强身份验证保证的安全连接。此远程位置必须保持安全，防止未经授权的修改。当通过 JMX 修改配置时，应安全地配置 JMX 服务器以要求身份验证，如果通过网络访问，则应使用安全连接。当通过 JNDI 提供配置时，这些配置应仅使用 java 方案在 Java EE 或 Jakarta EE 应用程序服务中共享配置。JNDI 源配置不应使用其他 JNDI 提供程序，例如 LDAP、DNS 或 RMI，因为所有这些提供程序都很难妥善保护。

不应使用Java 对象序列化流协议 从不受信任的来源反序列化数据。有关详细信息，请参阅相关的 OWASP 指南。

当使用包含模板参数（如 {}）的日志消息时，仅评估格式字符串以供替换参数。消息参数本身不会被评估为参数；它们仅包含在与其模板位置相对应的格式字符串中。消息参数转换为字符串是在需要时完成的，具体取决于所使用的布局。当需要对日志消息数据进行结构保留转换时，应使用 Message API 来记录结构化数据，并结合结构化布局（例如，JsonTemplateLayout）。格式字符串应为编译时常量，在任何情况下都不应使用用户控制的输入数据构建格式字符串。

当使用非结构化布局（如 PatternLayout）时，无法保证输出格式。此布局主要用于开发目的，不应在生产应用程序中依赖。例如，如果日志消息包含换行符，则除非配置的模式使用 %encode{pattern}{CRLF} 包装模式转换器（它将回车符编码为字符串 \r，并将换行符编码为字符串 \n）或其他一些 %encode 选项，否则这些换行符不会被转义或特殊编码。请注意，除非已存在，否则 %xEx 将附加到模式。同样，其他编码选项可用于其他格式，但模式布局不能对整个输出做出假设。因此，在使用非结构化布局时，不应在日志中包含任何用户控制的输入。强烈建议在这种情况下使用结构化布局（例如，JsonTemplateLayout）。请注意，包含用户提供输入的 StrLookup 插件（那些在配置文件中由 ${…​} 模板引用的插件）不应由布局引用。

当使用结构化布局（除模式布局之外的大多数布局）时，日志消息将根据各种输出格式进行编码。这些安全地编码了包含在日志消息中的各种字段。例如，JsonTemplateLayout 可以配置为以各种 JSON 结构输出日志消息，其中所有日志数据都正确编码为安全可解析的 JSON。这是与依赖于日志文件或任意输出流的日志解析和日志收集工具一起使用的推荐操作模式。

Log4j 3 不再支持在自定义 SecurityManager 中运行或使用自定义 SecurityManager。此 Java 功能已在 Java 21 中弃用，以便在将来版本中删除。Log4j 2 包含对在安全管理器下运行的部分支持。

Log4j 与任何其他通用日志记录库一样，无法通用地支持敏感数据的日志屏蔽。虽然可以开发自定义插件来尝试屏蔽各种正则表达式（例如看起来像信用卡号的字符串），但日志屏蔽的总体问题等同于计算机科学中的停机问题，其中敏感数据始终可以以一种方式进行混淆，以避免被日志屏蔽检测到。因此，开发人员有责任正确划分敏感数据，以便可以通过日志屏蔽插件一致地屏蔽它。这种用例应该使用 Message API 来更好地控制此类数据的输出。

Log4j 竭尽全力最大限度地减少性能开销，以及最大限度地减少延迟或最大限度地提高吞吐量的选项。但是，如果追加器无法跟上正在写入的日志，我们无法保证应用程序的可用性。同步日志记录会导致应用程序阻塞并等待日志消息写入。异步日志记录也会导致应用程序阻塞并等待，具体取决于配置的等待策略和队列已满策略。在应用程序中配置过大或过多的缓冲区也会导致内存不足错误。

如果日志压缩与自定义加密一起使用，其中日志包含用户控制的输入，那么这会导致CRIME 攻击 样式的漏洞，其中选择明文攻击与压缩算法处理不同输入的方式导致的信息泄漏相结合。避免此问题的最简单方法是在编码用户控制的输入时，永远不要将压缩与加密结合使用。

具有写入日志配置访问权限的攻击者可以使用 JDBC 追加器构建恶意配置，该追加器使用数据源引用 JNDI URI，该 URI 可以执行远程代码。此问题通过将 JNDI 数据源名称限制为 java 协议来解决。

升级到 2.3.2（适用于 Java 6）、2.12.4（适用于 Java 7）或 2.17.1（适用于 Java 8 及更高版本）。

在之前的版本中，请确认如果正在使用 JDBC 追加器，则它没有配置为使用 java 以外的任何协议。

Log4j 版本 2.0-alpha1 到 2.16.0（不包括 2.3.1 和 2.12.3）没有防止使用自引用查找实现的失控递归。当日志配置使用非默认模式布局和上下文查找（例如，$${ctx:loginId}）时，控制线程上下文映射 (MDC) 输入数据的攻击者可以制作包含递归查找的恶意输入数据，从而导致 StackOverflowError，这将终止进程。这也称为DoS（拒绝服务）攻击。

升级到 2.3.1（适用于 Java 6）、2.12.3（适用于 Java 7）或 2.17.0（适用于 Java 8 及更高版本）。

或者，可以在配置中缓解此无限递归问题

请注意，只有 log4j-core JAR 文件受到此漏洞的影响。仅使用 log4j-api JAR 文件而不使用 log4j-core JAR 文件的应用程序不受此漏洞的影响。

Akamai Technologies 的 Hideki Okamoto、Trend Micro Research 的 Guy Lederfein（与 Trend Micro 的 Zero Day Initiative 合作）以及另一位匿名漏洞研究人员独立发现。

发现 Log4j 2.15.0 中用于解决 CVE-2021-44228 的修复程序在某些非默认配置中是不完整的。当日志记录配置使用具有线程上下文查找的非默认模式布局（例如，$${ctx:loginId}）时，控制线程上下文映射 (MDC) 的攻击者可以使用 JNDI 查找模式来制作恶意输入数据，从而导致某些环境中的信息泄露和远程代码执行，以及所有环境中的本地代码执行。远程代码执行已在 macOS、Fedora、Arch Linux 和 Alpine Linux 上得到证明。

请注意，此漏洞不仅限于 JNDI 查找。任何其他查找也可能包含在线程上下文映射变量中，并且可能会将私人信息暴露给任何有权访问日志的人。

请注意，只有 log4j-core JAR 文件受到此漏洞的影响。仅使用 log4j-api JAR 文件而不使用 log4j-core JAR 文件的应用程序不受此漏洞的影响。

升级到 Log4j 2.3.1（适用于 Java 6）、2.12.3（适用于 Java 7）或 2.17.0（适用于 Java 8 及更高版本）。

此问题由 iC Consult 的 Kai Mindermann 和 4ra1n 独立发现。

Google 的 Ash Fox、GitHub 的 Alvaro Muñoz 和 Tony Torralba、Praetorian 的 Anthony Weems 以及 RyotaK (@ryotkak) 独立发现了其他漏洞细节。

在 Log4j 中，配置、日志消息和参数中使用的 JNDI 功能无法防御攻击者控制的 LDAP 和其他与 JNDI 相关的端点。能够控制日志消息或日志消息参数的攻击者可以执行从 LDAP 服务器加载的任意代码。

请注意，只有 log4j-core JAR 文件受到此漏洞的影响。仅使用 log4j-api JAR 文件而不使用 log4j-core JAR 文件的应用程序不受此漏洞的影响。

此问题由阿里云安全团队的陈昭俊发现。

SMTP 附加程序中证书主机不匹配的验证不当。这可能允许中间人攻击拦截 SMTPS 连接，从而泄露通过该附加程序发送的任何日志消息。

报告的问题是由 SslConfiguration 中的错误引起的。Log4j Configuration 中使用 SslConfiguration 的任何元素也受到此问题的影响。这包括 HttpAppender、SocketAppender 和 SyslogAppender。通过系统属性配置的 SslConfiguration 的用法不受影响。

升级到 2.12.3（Java 7）或 2.13.2（Java 8 及更高版本）。

或者，用户可以将 mail.smtp.ssl.checkserveridentity 系统属性设置为 true，以启用所有 SMTPS 邮件会话的 SMTPS 主机名验证。

此问题由 Peter Stöckli 发现。

当使用 TCP 套接字服务器或 UDP 套接字服务器从另一个应用程序接收序列化日志事件时，可以发送一个专门制作的二进制有效负载，该有效负载在反序列化时可以执行任意代码。

Java 7 及更高版本的用户应迁移到版本 2.8.2 或避免使用套接字服务器类。Java 6 用户应避免使用 TCP 或 UDP 套接字服务器类，或者他们可以手动将 安全修复提交 从 2.8.2 反向移植。

此问题由 Telstra 红队的 Marcio Almeida de Macedo 发现。