CVE-2026-77123 in Nexus Repository
Summary
by MITRE • 09/02/2026
Nexus Repository 3 contains a sensitive information disclosure vulnerability in the capability read API. An account holding the nexus:capabilities:read privilege can retrieve the plaintext shared secret configured on a webhook capability, which is intended to be masked from all API responses. This issue affects Nexus Repository 3 versions 3.2.0 through 3.95.x, and is fixed in version 3.96.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/03/2026
The vulnerability identified within Nexus Repository Manager 3 represents a critical failure in the implementation of sensitive data masking for webhook configurations. Specifically, this flaw resides in the capability read API endpoint, which is designed to allow users with specific privileges to inspect system capabilities and their associated settings. The core technical issue involves the improper handling of shared secrets configured on webhook capabilities. While these secrets are intended to be masked or obscured in all standard API responses to prevent unauthorized access, a logic error allows an authenticated user possessing only the nexus:capabilities:read privilege to retrieve the plaintext value of this secret. This indicates that the server-side filtering mechanism responsible for redacting sensitive fields failed to apply consistently across all code paths accessible via the read operation, effectively bypassing the intended security controls designed to protect credential material.
From a technical perspective, this vulnerability is classified under CWE-200: Information Exposure, as it involves the accidental disclosure of information that could be used by an attacker to compromise other systems or services. The shared secret in question is typically utilized for cryptographic signing and verification of webhook payloads sent from Nexus Repository to external endpoints such as CI/CD pipelines or issue trackers like Jira or GitHub. By obtaining this plaintext secret, a malicious actor can forge valid webhook requests that appear to originate legitimately from the Nexus instance. This capability undermines the integrity guarantees provided by HMAC signatures, allowing for potential injection of malicious artifacts into downstream build processes or triggering unauthorized actions in integrated services without detection.
The operational impact of this vulnerability is significant due to its low barrier to entry and high potential for lateral movement within an organization's DevOps infrastructure. An attacker who has gained access to a user account with the nexus:capabilities:read privilege, which is often granted broadly to developers or build service accounts for monitoring purposes, can extract these secrets without needing higher-level administrative rights. Once obtained, the plaintext shared secret enables the creation of spoofed webhooks that could trigger malicious builds, exfiltrate data through outbound requests controlled by the attacker, or disrupt continuous integration workflows. This effectively transforms a read-only privilege into a vector for write operations and system compromise in connected environments, violating the principle of least privilege expected in secure software design.
This behavior aligns with MITRE ATT&CK technique T1530: Data from Cloud Storage Objects if the secrets are stored remotely, or more accurately T1608: Stage Capabilities via Webhooks when considering the abuse of webhook mechanisms for malicious payload delivery. The vulnerability highlights a common pitfall in API design where security controls such as field masking are implemented inconsistently across different endpoints or methods within the same service module. It underscores the necessity for rigorous code review processes that specifically test edge cases involving sensitive data serialization and deserialization, ensuring that redaction logic is applied uniformly regardless of the access level or specific API method invoked by the client application.
Mitigation strategies must prioritize immediate remediation through software updates as well as compensating controls to limit exposure in environments where patching may be delayed due to operational constraints. The primary resolution involves upgrading Nexus Repository Manager 3 to version 3.96.0 or later, which contains the corrected code that properly masks shared secrets across all API responses including those from the capability read endpoint. For organizations unable to upgrade immediately, it is critical to audit user permissions and restrict the nexus:capabilities:read privilege exclusively to security administrators who require visibility into system configurations for auditing purposes, rather than granting it broadly to development or build service accounts. Additionally, implementing network-level controls such as web application firewalls can help detect anomalous patterns of secret retrieval if they become part of a larger attack chain involving other vulnerabilities. Regular rotation of webhook shared secrets is also recommended to minimize the window of exposure should any future disclosure occur, ensuring that compromised credentials do not remain valid indefinitely within the integrated ecosystem.