CVE-2026-7494

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.