CVE-2026-17595 in Nexus Repository
Summary
by MITRE • 08/07/2026
Nexus Repository 3 did not fully sandbox JEXL expressions used in Content Selectors. An account holding the nexus:selectors:create permission could construct an expression that read Java object properties not intended to be exposed to the expression engine, disclosing internal JVM class metadata such as class and classloader names. This issue does not permit method invocation, object construction, or arbitrary code execution. This has been fixed by restricting property access in the JEXL sandbox to the intended data types.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/07/2026
The vulnerability identified in Nexus Repository 3 represents a significant information disclosure issue that emerged from inadequate sandboxing mechanisms within the JEXL expression engine used for Content Selectors. This flaw specifically affected systems where users possessed the nexus:selectors:create permission, creating a scenario where authenticated attackers could exploit the relaxed security boundaries of the expression evaluation system. The vulnerability stems from the insufficient restriction of property access within the JEXL sandbox implementation, allowing maliciously crafted expressions to traverse object hierarchies and expose internal JVM metadata that should remain hidden from user-controlled expressions.
The technical nature of this vulnerability aligns with CWE-200, which addresses exposure of sensitive information, and more specifically relates to CWE-470, concerning unsafe object deserialization, though in this case the exposure occurs through property traversal rather than direct deserialization. The flaw operates by permitting access to Java object properties that should be restricted within the expression context, enabling attackers to extract class names, classloader information, and other internal JVM metadata through carefully constructed JEXL expressions. This information disclosure represents a reconnaissance opportunity for potential attackers seeking to understand the underlying system architecture and identify possible attack vectors.
The operational impact of this vulnerability extends beyond simple information exposure, as it provides attackers with valuable insights into the internal structure of the Nexus Repository system and its JVM implementation. While the vulnerability does not permit direct code execution or method invocation, the disclosure of internal class names and classloader metadata can significantly aid in crafting more sophisticated attacks against the system. Attackers could potentially use this information to identify specific Java classes that might contain vulnerabilities or to understand the system's internal behavior patterns. The restriction of access to only intended data types in the patched version demonstrates a proper defense-in-depth approach that limits the attack surface by ensuring that expression evaluation contexts cannot traverse beyond predetermined boundaries.
Mitigation efforts should focus on implementing robust sandboxing mechanisms that strictly enforce property access controls within expression engines, as recommended by ATT&CK technique T1059.1.007 for preventing command and script injection. Organizations should ensure that all third-party expression engines used in repository management systems undergo comprehensive security review to validate their sandboxing capabilities. The fix implemented by restricting property access to intended data types represents a sound approach that aligns with secure coding practices and follows the principle of least privilege. Additionally, regular security assessments of repository configurations and permission models should be conducted to ensure that users cannot acquire unintended privileges that might enable exploitation of similar sandboxing vulnerabilities in other components of the system.