Threat database

An account holding the nexus:settings:update permission in Nexus Repository 3 (or the equivalent nexus:settings permission in the legacy Nexus Repository 2) could submit arbitrary values as realm identifiers through an internal configuration API that did not validate them against the set of registered realms. Because unrecognized entries were persisted and re-evaluated on every realm load via a legacy code path, this could result in unintended code executing inside the Nexus Repository process, and in some cases a persistent authentication lockout that was not visible through the administrative UI.

Nexus Repository 3 CE/Pro versions 3.0.0 through 3.94.x contain an incorrect authorization vulnerability (CWE-863) in the repository-creation user interface. An individual user account holding a delegated repository-admin privilege scoped to a specific repository format could create a repository of a different, unauthorized format, because authorization was checked against one request field while a separate, attacker-controlled field determined the repository format actually created. This does not affect the anonymous user, which cannot hold this privilege by default. Fixed in version 3.95.0.

Nexus Repository 3 did not fully sandbox JEXL expressions used in Content Selectors. An account holding the nexus:selectors:create permission could construct an expression that read Java object properties not intended to be exposed to the expression engine, disclosing internal JVM class metadata such as class and classloader names. This issue does not permit method invocation, object construction, or arbitrary code execution. This has been fixed by restricting property access in the JEXL sandbox to the intended data types.

Nexus Repository 3 was found to be vulnerable to stored cross-site scripting (XSS). A user with the nexus:blobstores:create or nexus:blobstores:update permission could set a blob store name containing malicious script content, which would later execute in the browser of another user viewing system health-check status. This issue has been fixed in version 3.95.0.

Sonatype Nexus Repository 3 did not properly filter internal configuration keys from user-supplied task properties when creating or updating a scheduled task through the administrative UI. An account holding permission to create at least one scheduled task type could supply a crafted property value that caused the system to overwrite the configuration of an unrelated, existing task instead of creating a new one.

Nexus Repository 3 contained an endpoint used to change the administrator account password during initial onboarding. This endpoint did not verify that onboarding was still in progress before allowing the password change, relying instead on the presence of a local onboarding artifact. As a result, an account holding the nexus:* permission could invoke the endpoint outside the intended onboarding flow to replace the administrator password, and existing sessions were not invalidated after the change.

Sonatype Nexus Repository 3 did not immediately terminate a user's active login session or revoke their cached permissions when that user's account was deleted, deactivated, or had its password changed. A user whose account was already logged in at the time of one of these actions could continue using their existing session to interact with the repository as though the account were still active, until that session independently expired. Depending on the permissions previously held, this could allow continued unauthorized access to read, modify, or delete repository content after access was intended to be revoked.

A user holding a permission to update privilege definitions could modify a wildcard privilege already assigned to their own role to grant broader permissions than they were authorized to hold, including full administrative access, without any additional authorization check or role reassignment.

Nexus Repository 3 did not sufficiently restrict which HikariCP connection-pool properties could be set through the DataStore configuration API. A user holding the nx-datastores-update permission could set the connectionInitSql property to execute arbitrary SQL against the configured database on every new connection. On the default H2 database backend, this could be leveraged to achieve remote code execution as the Nexus process user.

Nexus Repository 3 contains a Server-Side Request Forgery (SSRF) vulnerability in the email configuration verification feature. A user holding the nexus:settings:update permission could submit arbitrary host and port values to the email test/verification endpoint, causing the server to attempt outbound network connections to internal or otherwise restricted network addresses. Differences in the server's response could be used to infer whether internal hosts and ports are reachable. This issue affects Nexus Repository 3 CE/Pro versions up to and including 3.94.1, and is fixed in version 3.95.0.

Nexus Repository 3 did not apply its existing Server-Side Request Forgery (SSRF) protections to HTTP redirect targets returned by proxy repository upstream servers. Any user with read access to a proxy repository backed by an attacker-controlled or compromised upstream server — including an anonymous user, if anonymous access is enabled — could receive a response from an internal network address or cloud metadata endpoint as repository content, potentially exposing sensitive information such as cloud IAM credentials.

Nexus Repository 3 does not validate the destination of the "Webhook: Global" capability's configured URL before making an outbound HTTP request, allowing a user holding the Capability Administration permission to cause the server to send requests to internal network locations (Server-Side Request Forgery). This permission is granted by role assignment, independent of authentication status, so an unauthenticated user could also trigger this behavior if the anonymous role has been granted the permission.

An authorization bypass in Nexus Repository 3's component upload API allowed a user with only read/browse privileges on a Swift, Terraform, or Conda hosted repository to upload arbitrary artifacts, bypassing the intended write-permission check.

Sonatype Nexus Repository 3 versions from 3.0.0 up to but not including 3.94.0 are vulnerable to a Server-Side Request Forgery (SSRF) via the SSL Certificate Retrieval endpoint. An authenticated user with the nexus:ssl-truststore:read permission can cause the server to make outbound connections to internal or restricted network hosts. The vulnerability has a medium severity with a CVSS 4.0 base score of 5.3.

A vulnerability in Sonatype Nexus Repository Manager's format-specific API key generation may allow a remote attacker to gain unauthorized access to repository operations as a targeted user. A format-specific API key realm (NuGet API Key, Docker Bearer Token, or npm Bearer Token) must be enabled and the targeted user must have an active API key for this vulnerability to be exploitable.

Sonatype Nexus Repository Manager before 3.93.0 contains an authorization vulnerability in the proxy repository configuration that allows a delegated repository administrator to disclose stored upstream proxy credentials.

An authenticated user with the nx-licensing-create privilege can upload a specially crafted license file to execute arbitrary operating system commands as the Nexus process user in Sonatype Nexus Repository 3 versions before 3.92.0.