CVE-2026-92131 in Groovy Libraries Plugin
Summary
by MITRE • 09/16/2026
Jenkins Pipeline: Groovy Libraries Plugin 805.va_fc79344957d and earlier does not restrict the library path provided to the library Pipeline step to a relative path inside the SCM checkout, and follows symbolic links to locations outside of the SCM checkout when retrieving the library, resulting in a path traversal vulnerability, allowing attackers able to configure Pipelines to read files in a resources directory and to delete files in a test directory on the Jenkins controller file system.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/16/2026
The Groovy Libraries Plugin for Jenkins versions 805.va_fc79344957d and earlier contains a critical path traversal vulnerability that stems from insufficient validation of library paths specified within Pipeline configurations. When users define libraries using the library step, the plugin is designed to load code from source control management systems by checking out repositories into specific directories on the Jenkins controller file system. However, the implementation fails to strictly enforce that these library paths remain relative and confined within the boundaries of the SCM checkout directory. Instead, the underlying logic follows symbolic links without adequate restriction, allowing an attacker who has the ability to configure or modify Pipelines to direct the plugin toward arbitrary locations on the host operating system rather than limiting access to the intended repository contents.
This technical flaw effectively bypasses the security isolation expected between Jenkins jobs and the broader server environment. By exploiting this lack of path normalization and restriction, a malicious actor can construct library references that utilize symbolic links or relative path sequences such as dot-dot-slash constructs to escape the sandboxed SCM directory. This capability grants unauthorized access to sensitive areas of the Jenkins controller file system. The operational impact is severe because it allows attackers not only to read arbitrary files but also potentially delete critical data, depending on the permissions associated with the user account running the Jenkins service.
The consequences of this vulnerability extend beyond simple information disclosure. Attackers can exfiltrate configuration files containing credentials, API keys, and other secrets stored in resources directories or similar locations accessible via the traversal path. Furthermore, the ability to delete files in test directories or other writable areas on the controller file system introduces a risk of denial of service and data integrity compromise. This could disrupt ongoing builds, destroy historical build artifacts, or remove essential configuration files required for Jenkins operation, leading to significant downtime and operational instability within the CI/CD pipeline infrastructure.
From a classification perspective, this vulnerability aligns with CWE-22 Improper Limitation of a Pathname to a Restricted Directory, as it involves accessing resources outside the intended restricted directory through path manipulation. Additionally, because it allows an attacker who has been granted access to configure Pipelines to execute actions that impact system integrity and availability, it relates to ATT&CK techniques involving resource hijacking or data destruction within containerized or isolated environments where boundary enforcement is critical for security posture.
Mitigation strategies must prioritize immediate updates to the latest version of the Groovy Libraries Plugin which addresses this path validation logic. Administrators should also implement strict least-privilege principles by ensuring that the Jenkins controller process runs under a dedicated service account with minimal file system permissions, thereby limiting the potential damage even if an attacker successfully exploits the traversal flaw. Furthermore, organizations should audit existing Pipeline configurations to remove any reliance on dynamic library loading from untrusted sources and consider disabling the ability for lower-privileged users to define custom libraries unless absolutely necessary. Regular monitoring of Jenkins logs for unusual file access patterns can also aid in detecting potential exploitation attempts before significant damage occurs.