CVE-2026-97665 in Nexus Repository
Summary
by MITRE • 10/15/2026
A missing authorization check in Nexus Repository 3's NuGet Components API upload path allows an account holding only repository read and browse privileges to upload and persist NuGet symbol packages (.snupkg) to a hosted repository, bypassing the write-permission check enforced for ordinary package uploads. Exploitation requires a hosted NuGet repository with Symbol Server enabled. If anonymous access is enabled, the built-in anonymous user holds read and browse privileges across all repositories by default, so this precondition can also be met without an authenticated account.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability in Nexus Repository 3 represents a critical authorization bypass within the NuGet Components API upload mechanism, specifically targeting the handling of symbol packages with the .snupkg extension. In standard software development workflows, particularly those involving Microsoft technologies, developers often publish both binary package files (.nupkg) and corresponding symbol packages to facilitate debugging in production environments or for compliance purposes. The architecture of Nexus Repository 3 distinguishes between these two types of uploads by enforcing different permission models. While the upload of regular NuGet packages is strictly gated behind write permissions on the target repository, the endpoint responsible for accepting .snupkg files fails to perform an equivalent authorization check. This discrepancy creates a significant security gap where the system treats symbol package ingestion as a read-only or public operation rather than a privileged administrative action.
From a technical perspective, this flaw stems from incomplete access control logic within the API layer that processes NuGet requests. When a client initiates an upload to the repository's component endpoint, the server validates the request against the user's assigned roles and permissions. For standard packages, the system correctly rejects attempts by users lacking write privileges. However, for symbol packages, the validation routine either skips the permission check entirely or relies on a flawed condition that does not account for the specific privilege level of the authenticated principal. This allows any actor with read access to interact with this endpoint in a way that modifies repository state by adding new files. The persistence of these uploaded symbols means they become available for download and indexing, effectively altering the content of the hosted repository without proper oversight or approval workflows typically associated with package publication.
The operational impact of this vulnerability is severe due to its potential for abuse in supply chain attacks and data exfiltration scenarios. An attacker who gains access to a system with read-only privileges can upload malicious symbol packages that may contain embedded malware, backdoors, or sensitive intellectual property disguised as debugging information. If the repository serves symbols to developers via integrated development environments like Visual Studio, these compromised files could be downloaded during normal operations, potentially leading to code injection or credential theft at the developer level. Furthermore, because symbol servers are often used for crash dump analysis and security auditing, injecting malicious symbols can corrupt forensic investigations by providing false trace data that misleads incident responders about the root cause of software failures.
The risk is significantly amplified in environments where anonymous access is enabled on NuGet repositories. By default, Nexus Repository 3 grants the built-in anonymous user read and browse privileges across all repositories if this feature is activated. Consequently, an unauthenticated attacker from the internet can exploit this vulnerability without needing valid credentials to log into the application interface. This transforms a local privilege escalation issue into a remote code execution or data integrity compromise vector accessible by any external actor with network connectivity to the Nexus instance. The requirement for the repository to have its Symbol Server feature enabled is typically met in many enterprise setups that support .NET development, making this vulnerability widely applicable across vulnerable installations.
Mitigation strategies must address both the immediate technical flaw and broader access control practices. Administrators should immediately disable anonymous access on all NuGet repositories unless absolutely necessary, ensuring that every upload operation requires explicit authentication with appropriate write permissions. It is also critical to review role-based access controls within Nexus Repository 3 to ensure that no user or service account possesses read-only privileges if they have any need for repository interaction beyond browsing existing content. Upgrading to a patched version of Nexus Repository 3 where this authorization check has been corrected in the NuGet Components API upload path is essential. Additionally, organizations should implement network-level controls such as firewalls and intrusion detection systems to monitor for unusual upload patterns or large volumes of symbol package requests from unexpected sources.
This vulnerability aligns with CWE-862, which describes Missing Authorization, as the application fails to enforce proper access control on a protected resource. It also maps to MITRE ATT&CK technique T1505.003, Server Component Binary Injection, where an adversary implants malicious components into legitimate software distribution channels. By exploiting this flaw, attackers can compromise the integrity of the development supply chain, affecting downstream consumers who rely on these repositories for building and debugging applications. Continuous monitoring of repository activity logs for unauthorized upload attempts and regular audits of user permissions are recommended to maintain a secure posture against such authorization bypasses in artifact management systems.