CVE-2026-17601 is a High severity privilege escalation in Sonatype Nexus Repository 3. A user allowed to update privilege definitions could edit a wildcard privilege on their own role to grant broader rights, including full administrator access, with no further check. It scores 7.2. Confirm the fixed version in Sonatype's advisory.
What's affected
Sonatype Nexus Repository 3 is named in the record. It applies to users who hold permission to update privilege definitions.
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 7.2 (High) with vector CVSS:3.1/AV:N/AC:L/PR:H/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 list the roles that can update privilege definitions, and the wildcard privileges assigned to them. Those are the roles in scope.
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.
- List the roles that can update privilege definitions, and who is assigned to them. Remove the capability from anyone who does not manage access.
- Review wildcard privileges attached to those roles and compare them with what you intended to grant.
- Record the current privilege definitions now, so you can compare them after the upgrade and spot unexplained broadening.
Why it matters
The record classes the weakness as CWE-862, Missing Authorization. Role based access control relies on a simple rule: you can change who has what, but you cannot hand yourself more than you were given. Here that rule was not enforced for one case. A wildcard privilege already assigned to your role could be edited to cover more, without a check and without reassigning roles. The record classes the weakness as CWE-862, missing authorization.
The result in the record is that a user could reach full administrative access. The vector shows network access with high privileges required, which fits: the person already holds a powerful permission and the bug lets them grow it.
For most teams the useful lesson is about how widely the permission to edit privileges is given. It is easy to hand it to anyone who administers a project, and then forget. Repository managers feed builds and deployments, so unexplained rights there matter well beyond the tool. Patch, and then audit who can edit privileges. No exploitation is reported in the record, and the CVE is not in the CISA catalog.
Quick check
Can any Nexus user do this?
No. The record says the user must hold permission to update privilege definitions.
Why does a wildcard privilege matter?
It matches many actions. Editing one that is already on your role can widen your access without any role change.
Sources
- Sonatype Nexus Repository 3.95.0 to 3.95.4 release notes, fetched 18 October 2026
- Sonatype support article for CVE-2026-17601, listed in the record but could not be read when fetched
Last reviewed: 18 October 2026.
