Nexus Repository 3 vulnerabilities

Nexus Repository 3 did not sufficiently restrict which HikariCP connection-pool properties could be set through the DataStore configuration API. A user with 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.

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.

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 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.

Nexus Repository 3 had an endpoint for changing the administrator password during initial onboarding. It did not verify that onboarding was still in progress, relying on a local artifact. An account with nexus:* permission could invoke the endpoint outside the intended flow to replace the admin password, and existing sessions were not invalidated.

Sonatype Nexus Repository 3 did not properly filter internal configuration keys from user-supplied task properties when creating or updating scheduled tasks via the admin UI. An account with permission to create at least one task type could supply a crafted value that overwrote the configuration of an unrelated existing task instead of creating a new one.

Nexus Repository 3 has a Server-Side Request Forgery (SSRF) vulnerability in the email configuration verification feature. A user with nexus:settings:update permission could submit arbitrary host and port values to the email test endpoint, causing the server to attempt outbound connections to internal or restricted addresses. Response differences could be used to infer reachability of internal hosts and ports. Affects up to 3.94.1, fixed in 3.95.0.

Nexus Repository 3 is vulnerable to stored cross-site scripting (XSS). A user with nexus:blobstores:create or nexus:blobstores:update permission could set a blob store name containing malicious script, which would later execute in another user's browser when viewing system health-check status. Fixed in version 3.95.0.

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

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.

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 contained a privilege escalation vulnerability in the REST privileges API. An authenticated user with permission to manage privileges could, under certain role configurations, escalate their own access to full administrator by exploiting a type-confusion flaw in the privilege update endpoint.

An SSRF vulnerability in Nexus Repository 3 allows an attacker controlling a proxy repository upstream server to redirect requests to internal network addresses or cloud metadata endpoints. A user with read access to such a repository may receive sensitive information, including cloud IAM credentials.

A vulnerability in Nexus Repository 3 allows a user with Capability Administration permission to send HTTP requests to internal network locations (SSRF). The lack of destination URL validation in the global webhook configuration enables an attacker to use the server to scan or attack internal systems.

Nexus Repository 3 is vulnerable to Server-Side Request Forgery (SSRF) via the SSL Certificate Retrieval endpoint. A user with the nexus:ssl-truststore:read permission can cause the server to initiate outbound connections to internal or restricted network hosts.

An authorization bypass vulnerability in Nexus Repository 3's component upload API allows 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.