CVE-2026-17603 is a High severity flaw in Sonatype Nexus Repository 3. The datastore configuration API did not restrict connection-pool properties, so a user with the datastore update permission could run arbitrary SQL on every new connection, and on the default H2 database reach remote code execution. It scores 8.8. Confirm the fix in Sonatype's advisory.
What's affected
Sonatype Nexus Repository 3 is named in the record. It applies to accounts holding the nx-datastores-update permission. The record singles out the default H2 backend as the one where code execution was possible.
The fixed version is not stated in the NVD record. The record points to the Sonatype Nexus Repository 3.95.0 release notes and to a Sonatype support article. We could read the release notes: they list 3.95.0 on 5 August 2026 and 3.95.1 to 3.95.4 after it, but they do not name this CVE. The support article returned an access error when we fetched it. So we cannot confirm the exact fixed version here. Check the Sonatype support article for this CVE and upgrade to the version it names or a newer release.
The record scores it 8.8 (High) with vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.
How to check if you're exposed
Find the version you run, then compare it with the fixed version in the Sonatype article. The web interface shows the version in the About entry of the Help menu. If you run Nexus in a container, check the image tag you deployed.
docker ps
That lists running containers with their image names and tags, which is a quick way to spot old Nexus tags. Because the record does not state a fixed version, do not assume that any 3.x release is safe; use the Sonatype article. Then check which database backend you use, since the record names the default H2 backend, and list who holds nx-datastores-update.
What to do now
- Find your Nexus Repository 3 version and compare it with the fixed version in Sonatype's advisory.
- Upgrade to the fixed release or newer.
- Check which accounts hold
nx-datastores-update, and remove it from any that do not administer the database. - Run the Nexus process as a dedicated, low-privilege operating system user, and confirm that it cannot write outside its own directories.
- Review the datastore configuration for properties you do not recognise, in particular any connection initialisation setting.
Why it matters
The record classes the weakness as CWE-94, Improper Control of Generation of Code (code injection). Nexus uses HikariCP to manage database connections, and the datastore configuration API passes properties to it. The flaw is that the API did not limit which properties could be set. One of them, connectionInitSql, runs SQL when each new connection starts. So a user with the update permission could make the database run arbitrary SQL every time a connection opened. The record classes it as CWE-94, improper control of generation of code.
On the default H2 backend, the record says this could be turned into remote code execution as the Nexus process user. That step explains the high score: the attack moves from a configuration screen to running code on the server.
The permission is narrow and held by few people, which is why this is not rated Critical. But it is a clean example of an API that exposes more of a library's settings than it should. If you accept configuration from users, an allow list of safe properties is safer than a block list. The record does not report exploitation and the CVE is not in the CISA catalog.
Quick check
Does this affect PostgreSQL deployments?
The record says arbitrary SQL could run on whichever database is configured, and names H2 as the backend where code execution was possible. Do not assume PostgreSQL is unaffected.
Who can trigger it?
An account with the nx-datastores-update permission.
Sources
- Sonatype Nexus Repository 3.95.0 to 3.95.4 release notes, fetched 18 October 2026
- Sonatype support article for CVE-2026-17603, listed in the record but could not be read when fetched
Last reviewed: 18 October 2026.
