Malware Risk
Nexus Repository detects malware within your repository and warns users when malicious components are found. We highly recommend Nexus Repository administrators remove the artifacts as quickly as possible to limit these malicious components' impact on their environment.
Recommended Action
Nexus Repository administrators are recommended to contact Sonatype to learn how to remediate the risk quickly.
Discovered Malware Banner
Users logging into Nexus Repository see a warning banner when Malware components are found in their repositories. We recommend users contact their system administrators to report the discovery and request they remove the components immediately.
The banner is updated every 24 hours.
What is Malware Risk?
Open-source malware is deliberately crafted to execute harmful actions that can severely compromise your system and significantly increase risk. These packages are designed to look legitimate but are malicious entities that often do not even pretend to be working code. They infiltrate software supply chains by exploiting the automation in build or dependency managers, frequently executing on download.
Once downloaded, the damage is often already done. Even one malicious component is too many as it may compromise your entire build pipeline by stealing data, installing more malware, and hijacking systems, sometimes without immediate detection. The more malicious components you have, the greater the risk of exposure, and the more complex it becomes to manage and remediate.
The severity of these threats cannot be overstated. Even when discovered and removed from repositories like PyPI or npm, the absence of a CVE complicates efforts to track and address the threat, leaving systems vulnerable and risk mitigation challenging.
Difference from Open Source Vulnerability
An open-source vulnerability is a weakness that can be exploited to gain unauthorized access to a system or network to cause damage or manipulate it somehow. They are not intentionally malicious.
Packages with vulnerabilities may be used when they do not violate existing policies, and in many cases, a different version of the package can be used that does not have the vulnerability. Regardless, vulnerabilities, whether intentional or not, can leave a system vulnerable to attack. When a vulnerability is identified it is assigned a CVE so developers know about the vulnerability.
Learn more from our closer look at Differentiating Software Vulnerabilities and Malware