CVE-2026-92137 in Robot Framework Plugin
Summary
by MITRE • 09/17/2026
Jenkins Robot Framework Plugin 6.2.2 and earlier does not check that the archive directory configured for Robot Framework report files is contained within the build directory on the Jenkins controller, allowing attackers with Item/Configure permission to create or replace arbitrary files on the Jenkins controller file system with attacker-specified content, which can lead to remote code execution.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability in Jenkins Robot Framework Plugin versions 6.2.2 and earlier stems from a critical path traversal flaw within the artifact archiving mechanism. When users configure the plugin to archive Robot Framework report files, the software fails to validate that the specified destination directory is strictly contained within the expected build workspace or output directory on the Jenkins controller file system. This lack of input validation allows an attacker who possesses Item/Configure permissions for a specific job to manipulate the path configuration parameters. By utilizing standard directory traversal sequences such as dot-dot-slash, the attacker can escape the intended sandboxed environment and specify arbitrary absolute paths on the underlying operating system where the Jenkins controller is running.
This technical flaw effectively bypasses the security boundaries established by the Jenkins permission model. While Item/Configure permissions are generally restricted to managing job settings rather than direct file system access, this vulnerability elevates that privilege level significantly. An attacker can write files to sensitive locations such as configuration directories, library paths, or other areas accessible by the Jenkins process user account. The ability to create or replace arbitrary files with attacker-specified content creates a direct pathway for code execution if the written file is subsequently loaded or executed by the system. For instance, writing malicious scripts into plugin directories or modifying existing executable binaries can lead to remote code execution on the controller node.
The operational impact of this vulnerability is severe as it compromises the integrity and availability of the Jenkins server itself. Since Jenkins controllers often manage build agents and store sensitive credentials, source code artifacts, and deployment configurations, gaining control over the file system allows an attacker to exfiltrate confidential data, inject malicious code into future builds, or disrupt continuous integration pipelines entirely. This represents a significant risk in enterprise environments where multiple teams share Jenkins instances with varying levels of trust and permission scopes. The vulnerability aligns with CWE-22 Improper Limitation of a Pathname to a Restricted Directory, as the application fails to enforce proper restrictions on relative path resolution. Furthermore, it relates to CWE-434 Unrestricted Upload of File with Dangerous Type if the uploaded content is executable or interpreted by the system.
From an ATT&CK perspective, this vulnerability facilitates initial access and privilege escalation techniques commonly observed in supply chain attacks. The ability to write arbitrary files corresponds to T1505 Server Software Component: Web Shell or T1204 User Execution depending on how the written file is triggered. Attackers can leverage this flaw to establish persistence by modifying startup scripts or configuration files that are read upon Jenkins service restarts. This enables long-term unauthorized access even if initial entry points are patched or detected.
Mitigation strategies should prioritize immediate upgrading of the Robot Framework Plugin to version 6.2.3 or later, where path validation has been implemented to ensure all archive directories remain within the designated build workspace boundaries. In environments where updating is not immediately feasible, administrators can implement network-level controls such as firewalls to restrict Jenkins controller access to only trusted IP addresses and users. Additionally, applying principle of least privilege by auditing Item/Configure permissions ensures that fewer users have the ability to modify job configurations that interact with file system operations. Regular monitoring of file system changes on the Jenkins host using integrity checking tools can also help detect unauthorized modifications resulting from exploitation attempts.