On Friday, the internet was set on fire with news of the extremely widespread Log4j vulnerability and quick mass scanning efforts to exploit it by bad actors. Almost no organization is unaffected.
We wanted to let you know that Sonatype products do not use log4j-core. This means our software, including Nexus Lifecycle, Nexus Firewall, Nexus Repository Manager OSS, and Nexus Repository Manager Pro in versions 2.x and 3.x, is NOT affected by CVE-2021-44228. We still advise keeping your software upgraded at the latest version.
We are actively monitoring these issues and updating our blog; however, we also wanted to provide a product-specific breakdown to help answer your questions which can be found on our Help site.
Unsure if your organization is impacted? See our Find & Fix Log4j guide for help as you investigate your applications and environments for this vulnerability.
Explore the very latest findings around the Log4shell vulnerability in our resource center.
If you have any additional questions about this, we are happy to answer them in the thread below.
More information about this ongoing situation can also be found on the Sonatype Blog.
Hi @mfrost, is there any recommendation for Sonatype Nexus OSS version 1.9.2.2 log4j vulnerability. I can see CVE-2019-17571 and CVE-2021-4104 vulnerability reported for log4j1.2.x for this platform.
Thanks
Which version of nexus repository are you using? I believe you are seeing a false-positive. Our products do not use log4j but logback and are not vulnerable to any log4j CVEs.
Hi @mmartz . Thank you for your response.
We are currently using Nexus OSS 1.9.2.2 on-prem
You can download from here Download Archives - Repository Manager OSS
Vulnerable component ie.log4j-1.2.14.jar can be found in the location nexus-oss-webapp-1.9.2.2-bundle.zip\nexus-oss-webapp-1.9.2.2\runtime\apps\nexus\lib\log4j-1.2.14.jar
Previously I guess nexus war file was provided on download site but war generation was stopped later years.
I believe the 1.x line actually uses log4j not logback. Based on Log4j – Apache Log4j Security Vulnerabilities I believe that it’s not vulnerable as it’s the 1.x line of log4j not the 2.x line. I’d still recommend upgrading as soon as practical as it’s entirely possible that there are many other vulnerabilities in software that old.
We have added the upgraded plane being there are a couple of ongoing works this upgrade may take some more time to execute.
Can you please provide the required mitigation for the above two CVE and their impact on the current version we are using? and any mitigation we can do to fix it for now.
@shyamaspari Thanks for your patience- at this time, our recommendation is to simply upgrade as soon as possible since the version you are using is about 10 years old. You can read more about our software support policy here, particularly under the Product Maintenance section
Hi, as with others, our internal security scanning tools are picking up (many) log4j files that are not the latest. Even though Nexus does not use log4j, we are still expected to ‘resolve’ the scan findings by either removing the offending files or upgrading the files to the latest log4j versions. Can you please advise if choosing any of these are options would negatively impact Nexus Repository? NOTE: we already upgraded to the latest version of Nexus, and the files are still showing up in scans. Please advise.
I’d recommend you try it on a new installation first. It’s likely that attempting to remove those files will either break application logging or prevent Sonatype Nexus Repository from starting up entirely. Sonatype Nexus Repository uses logback for logging and does not use log4j, but the log4j-over-slf4j adapter and pax-logging-log4j12 adapters are included and most likely are required for logging to work.