Skip to content

Log4Shell Help for Central Publishers⚓︎

Hint

At Sonatype we delivered a Dashboard with stats of the current global adoption and usage of Log4j versions. You can look at it from this link Log4j Updates.

Updated on 2022-01-03

The Apache Log4j Team released versions 2.12.4 for Java 7 and 2.3.2 for Java 6 as a backport fix of CVE-2021-44832 for users running those Java versions.

Updated on 2021-12-28

The Apache Log4j Team currently recommends upgrading to the just released version 2.17.1, for Java 8 and up to address CVE-2021-44832.

Versions 2.12.4 for Java 7 and 2.3.2 for Java 6 are close to be published to address the same vulnerability.

Updated on 2021-12-22

The Apache Log4j Team released versions 2.12.3 for Java 7 and 2.3.1 for Java 6 as a backport fix for users running those Java versions.

Updated on 2021-12-20

The Apache Log4j Team currently recommends upgrading to 2.17.0 for Java 8 and up, which addresses CVE-2021-45105 as Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups.

The Apache Log4j Team is preparing the release of 2.12.3 for Java 7 and 2.3.1 for Java 6 (both still unreleased) as a backport fix for users running those Java versions.

Updated on 2021-12-14

The Apache Log4j Team currently recommends upgrading to 2.16.0, which addresses CVE-2021-45046.

The Apache Log4j Team has also released version 2.12.2 as a backport fix for users running their software on Java 7.

Hello Publishers,

As many of you know a recent 0 day was disclosed in the logging framework log4j that allows for remote code execution through its JNDI features. Along with the disclosure, a Proof of Concept was released to the public making the exploit easily accessible. While the Apache Log4j team quickly published a fix for the vulnerability, it is going to take significant time and effort for all applications and artifacts reliant on the vulnerable version to update.

The easiest way to know if you are using a vulnerable version of log4j-core is to use the Maven dependency plugin and search your projects for log4j-core.

mvn dependency:tree | grep log4j-core

If log4j-core between versions 2.0 and 2.17.0 shows up, the project is vulnerable for any of the recent vulnerabilities. Updating to version 2.17.1 will remove the vulnerability to CVE-2021-44228, CVE-2021-45046, CVE-2021-45105 and CVE-2021-44832.

Apache team also released version 2.12.4 for Java 7 and 2.3.2 for Java 6 as a backport fix for all the above vulnerabilities.

For those who cannot update and run software that uses a log4j between 2.10 and 2.14.1, setting an environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS="true" will remediate the vulnerability.

Updated on 2021-12-16

The Apache Log4j Team has discredited using an environmental variable as a mitigation measure.

In order to assist Central Maintainers in this process Sonatype has:

  • Emailed all Central publishers to notify them of the problem and provided free tools to identify if this is an issue for their projects.
  • Continued our efforts to inform all OSSRH publishers of the Software Bill of Materials (SBOM) of their artifacts along with any security implications of these dependencies including this 0 day.
  • Published Nexus Intelligence, our enterprise quality security analysis, data around the Log4Shell vulnerability for free to OSS Index and Lift users.

For awareness of the components you use along with any quality or security implications of these components, Sonatype Lift provides GitHub projects with continual analysis and intelligent feedback within Pull Requests. Sonatype Lift is free for open source projects to aid in ensuring quality software so developers can focus on innovating.

--Brian Fox
CTO & Cofounder Sonatype