When you delete or deactivate a user account in Nexus Repository 3, their existing sessions persist with full cached permissions until natural expiry. This is CVE-2026-17600, and it's a session invalidation gap—not a coding oversight, but a structural decoupling between account management and session management that the CVSS 8.7 score alone doesn't capture.
The vulnerability lives in the permission cache layer. Nexus 3 caches authorization grants for performance; hitting the auth backend on every repository operation would destroy throughput. But that cache only invalidates on explicit logic tied to account state changes—and the account deletion path simply doesn't trigger it. The session remains valid because nothing tells the cache the principal no longer exists.
Here's what you should check and do:
First, determine your session lifetime. The default in Nexus 3 varies by configuration, but expect 1-8 hours for UI sessions and potentially longer for API tokens. Check your nexus.properties or the UI at Administration → Security → Session Timeout. If it's measured in hours rather than minutes, you have a window.
Second, verify your hardening posture. The documented remediation involves clearing the permission cache when users are deleted or deactivated—but you need to confirm this actually happens in your environment, not just that it's documented. Test it: create a test user, grant them repository access, establish a session, then delete the user. Attempt an operation that requires those permissions. If it succeeds, you're vulnerable.
Third, understand the blast radius. Nexus is a supply chain node, not a web app. A persistent session here doesn't just mean 'user can read files they shouldn't'—it means they can pull or inject artifacts that flow into downstream build pipelines. The orphaned session is a time capsule of permissions from a state of the system that no longer exists.
Fourth, audit other account state transitions. This gap doesn't trigger only on deletion. Role demotions, org transfers, and compliance-driven access revocations create the same exposure. Your remediation can't just be 'wire up the delete handler'—it needs to cover every path that modifies account state.
Fifth, consider the temporal dimension. Fixing this vulnerability doesn't retroactively invalidate sessions that were already orphaned before the patch. If you're running a version with this gap, map your recent account deletions against active sessions and audit what artifacts were accessed during that window. This isn't just theoretical—disclosure turns this architectural flaw into an enumerated checklist for attackers.
The root cause is architectural, not incidental. Nexus 3's design decoupled account management from session management for performance, and that decoupling puts the burden of completeness on developers who won't write cache invalidation logic unless the framework forces them to. The fix commit will likely show a one-line cache invalidation call—but the systemic pattern (opt-in coupling between account state and session validity) lives in LDAP, SAML, and OAuth implementations across the industry. Assume this gap exists elsewhere in your identity infrastructure until proven otherwise.