CVE-2026-17603

CVE-2026-17603 in Sonatype Nexus Repository 3 centers on the nx-datastores-update permission, which appears to grant standard datastore administration capabilities—rotating credentials, adjusting pool sizing, updating connection endpoints. In practice, this permission exposes the HikariCP connection pool's connectionInitSql property through the datastore configuration API, and that property executes arbitrary SQL against the database every time a connection is pulled from the pool. On the default H2 embedded database, this translates directly to code execution. H2's ALIAS feature lets you define SQL aliases that call Java methods, including Runtime.getRuntime().exec() or similar process-spawning calls. A user with nx-datastores-update can set a connectionInitSql value like 'CREATE ALIAS EXEC AS "void exec(String cmd) throws Exception{Runtime.getRuntime().exec(cmd);}" CALL EXEC('whoami')' and then trigger any datastore operation to establish a connection and execute it. What makes this critical is the permission-to-impact gap. The nx-datastores-update permission does not sound like code execution—it sounds like infrastructure configuration. No role-based access control review would flag 'datastore update' as equivalent to DB admin access, yet functionally it is. The vulnerability is actually an API design failure: no REST endpoint should expose HikariCP connection pool properties that execute SQL at connection initialization, regardless of what permission gates it. That entire class of dangerous properties—connectionInitSql, connectionTestQuery, and similar—belongs in static configuration files, not admin APIs. The H2 default amplifies this significantly. H2's ALIAS feature and its ability to load Java classes from the classpath make reliable RCE straightforward. If Nexus is configured with an external database (PostgreSQL, MySQL), the RCE path closes, but the permission still grants arbitrary SQL execution against your production datastore—still a severe data integrity and confidentiality failure. Check your current state: audit who holds nx-datastores-update in your Nexus 3 deployment, review any custom roles or RBAC provisioning that may have granted this more broadly than intended, and verify whether H2 remains your active datastore. The remediation is two-layered: technically, restrict the API from accepting connectionInitSql and similar execution-adjacent properties, and organizationally, audit and tighten permission assignments that were made under the assumption this was a benign configuration permission.

Reviewed through automated stages and approved by a human before publication.