During my recent work I have discovered 2 security vulnerabilities in Nexus Repository that affect all users under default settings.

This post is a dive into the said vulnerabilities, which exposed thousands of private artifacts across a broad range of industries, including financial services, healthcare, communications, government agencies and countless private companies. But first, let’s see what a Nexus Repository Manager is.

Sonatype Nexus Repository Manager

Sonatype Nexus Repository Manager is a universal repository manager. It allows you to proxy, collect, and manage your Java dependencies, Docker images, Python packages and much more.

It makes it easy to distribute your software. Internally, you configure your build to publish artifacts to Nexus and they then become available to other developers.

From Sonatype’s website:

10 million developers trust Nexus.

The perfect system of record for all your software parts.

  • Manage components, build artifacts, and release candidates in one central location.
  • Understand component security, license, and quality issues.
  • Modernize software development with intelligent staging and release functionality.
  • Scale DevOps delivery with high availability and active/active clustering.
  • Sleep comfortably with world-class support and training.

Universal support for all your favorite formats and tools.
  • Store and distribute Maven/Java, npm, NuGet, RubyGems, Docker, P2, OBR, APT and YUM and more.
  • Manage components from dev through delivery: binaries, containers, assemblies, and finished goods.
  • Awesome support for the Java Virtual Machine (JVM) ecosystem, including Gradle, Ant, Maven, and Ivy.
  • Integrated with popular tools like Eclipse, IntelliJ, Hudson, Jenkins, Puppet, Chef, Docker, and more.

    If you are still not sure what exactly Nexus is providing, here is a great post by Tim OBrien from Sonatype, explaining Nexus for non-programmers.

    The Nexus repository manager surfaced on my radar while I was looking for new applications in the cloud ecosystem, as we tend to look at these and try to pinpoint security pitfalls in them. While exploring an application from this ecosystem, I usually tend to search for, and count the exposed instances in order to understand the magnitude of the situation, a similar approach has been taken during my work on the Docker Registry, but this time the numbers (and the content) where far grater, mostly because of the fast adoption and the maturity of the ecosystem.

    More than 120,000 active instances

    According to Sonatype, the number of active Nexus Repositories is more than 120,000.

    The screen above is the Welcome screen of a Nexus Repository. Unauthenticated access to this screen indicates an open registry (in more than 80% of the cases we checked) which allows anyone to grab any resource from the repository, even without any authentication.

    Vulnerabilities Information

    Now in the era of Docker and the cloud, users tend to skip a lot of configuration steps and let the software run under default settings with minor modification., Thanks to the “docker one-liner” that anyone can find on Docker Hub, you can run Sonatype Nexus too:

    docker run -d -p 8081:8081 --name nexus sonatype/nexus3

    Under normal circumstances, users tend to see that the image is up and running, and leave everything else as it is.
    This is usually acceptable, unless the default settings of the product are somehow not aligned with the best practices for security, like in the case of Nexus Repository:

    In the Nexus repository there are 2 main problems (unrelated to each other) that arise from the default settings:

    • The default user is always set to be admin/admin123 – CWE-521
    • Any unauthenticated user can read/download resources from Nexus – CWE-276

    This means all the images in the repository can be download just by accessing the repository, with no authentication needed, or by authenticating as the default admin account if unchanged. While walking some of these internet accessible repositories I have found that at least 50% of them are using the default settings – meaning they are both affected by CWE-521 and CWE-276

    These vulnerabilities place a lot of users in a position in which they expose all of their private artifacts (images,packages, etc…) to the internet unintentionally, a scenario that it is more common than you might think.

    Armed with the idea that Nexus has a default user, and that it is possible to read resources without authentication we can encounter 3 possible scenarios while looking at a repository:

    1. The Nexus repository is properly configured, and is secured:
      • You will be presented with a login screen, without the welcome message and without the ability to view anything; the default account will not be present on the system

    2. The Nexus Repository Manager has Incorrect Default Permissions:
      • You will be presented with the Welcome screen, the default user may or may not be present on the system – but that will not stop you from downloading the resources;
        All you need to do is to go from the welcome page to the Components page

      and from there navigate the browser to the resource you desire

      Now you can just click on the Path link, and the resource will be yours

    3. The Nexus Repository Manager has the default account in place:
      • This situation is even more devastating than the previous, because under the default account the adversary will have full control of the repository, with the ability to add, remove or modify your resources.

    At this point you might think that this scenario is the least popular between the 3, but the numbers amazed me as well, as more than 45% had the default user in place. An interesting insight is that users often forgot to delete the default user, even when they set up different users for their organization with complex password policies and changed the permissions on viewing resources.

    As an example of the impact of this problem, we found a Fortune 100 Technology company that had inadvertently exposed images that included access keys to their cloud environments and other resources. An attacker could use this information to take over those resources and propagate through them. In another example, we found a Fortune 200 company that had images that included the whole private source code to their flagship applications. An attacker could use this source to much more easily compromise the apps or steal business secrets.


    This is yet another wakeup call on the subject of weak defaults, emphasizing the magnitude of the problem. Ease-of-use is a great property – but it should not come at the cost of security, especially when we talk about authentication and permission management.

    A similar issue (CWE-521) was found by Twistlock in Docker Registry a while back, the fix that we proposed can be found in these PR’s: [distribution-library-image/pull/58], [distribution/pull/2362].

    We requested CVE IDs for both issues.

    1. The default user is always set to be admin/admin123 – CWE-521

      This issue was assigned CVE-2019-9629

    2. Any unauthenticated user can read resources on Nexus – CWE-276

      This issue was assigned CVE-2019-9630

    Disclosure timeline and fix

    As we do with any vulnerability we find at Twistlock Labs, we prepared a detailed advisory in which we reported the issues to the security team of Sonatype. Unfortunately, it took us multiple attempts to convince Sonatype to address these vulnerabilities, and we had to wait a long time to get a fix we considered sufficient for these issues. Given the high sensitivity of the content we found affected by these vulnerabilities, we decided to patiently wait for the fixes as not to put any user at immediate risk caused by an early publication of the vulnerabilities.

    No mention of these vulnerabilities or the fix appears in the release notes of Nexus releases.

    Nexus repository version 3.16.2 includes a warning regarding the issue of default users, but this was insufficient as a fix.

    The final fix, in version 3.17.0, disables the default admin user and fixed the permission issues on resources by requiring the admin to explicitly enable anonymous access when desired.

    We highly recommend all Nexus users to update to version 3.17.0.

    March 11th, 2019 – Reported the problems to Sonatype.
    March 13th, 2019 – Pinged sonatype to receive an acknowledgment.
    March 18th, 2019 – First response received – bugs were not acknowledged at this point.
    April 4th, 2019 – Another ping to Sonatype, expressing our worry about the damage that this might expose, an acknowledgement of the issues was received later that day.
    April 10th, 2019 – Another ping to Sonatype asking for status
    May 1st, 2019 – Another ping to Sonatype, no response up to this point
    May 12, 2019 – Another attempt to contact Sonatype
    May 13th, 2019 – Response received, stating that on April 16th a version with a warning on this issue was released, a fix was not introduced yet and planned for end of May or the beginning of June.
    June 10, 2019 – Another ping to Sonatype
    June 24, 2019 – Nexus Repository 3.17 released, which includes the fixes for the vulnerabilities