CVE-2026-92140 in Gitee Plugin
Summary
by MITRE • 09/16/2026
Jenkins Gitee Plugin 1301.v8957053c7902 and earlier does not escape the sender name from Gitee push webhook payloads in build causes, resulting in a stored cross-site scripting (XSS) vulnerability exploitable by attackers able to trigger builds via the Jenkins Gitee Plugin webhook endpoint.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The Jenkins Gitee plugin version 1301.v8957053c7902 and earlier contains a critical stored cross-site scripting (XSS) vulnerability that stems from insufficient input validation and output encoding when processing data received via webhooks. This flaw specifically affects the handling of sender name information within Gitee push webhook payloads, which are used to trigger automated builds in Jenkins environments integrated with the Gitee code hosting platform. When a user pushes changes to a repository monitored by this plugin, the webhook payload includes metadata about the event, including the identity of the person who initiated the push. The vulnerability arises because the application fails to properly escape or sanitize the sender name field before incorporating it into build cause descriptions that are subsequently rendered in the Jenkins web interface without adequate encoding mechanisms.
This technical flaw allows an attacker with write access to a connected Gitee repository to inject malicious JavaScript code directly into the system by crafting a push event where the sender name contains script tags or other executable HTML content. Because this data is stored within the build cause metadata and displayed in the Jenkins user interface, it persists across sessions until manually removed or overwritten. The persistence of this payload classifies the vulnerability as stored XSS rather than reflected XSS, significantly increasing its potential impact since any administrator or authorized user viewing the build history will have their browser execute the injected code automatically upon loading the affected page.
The operational impact of this vulnerability is substantial within a typical DevOps workflow context. Jenkins administrators and developers who regularly monitor build statuses are at risk of having their sessions compromised if they view builds triggered by malicious pushes. Successful exploitation can lead to session hijacking, where attackers steal authentication cookies or tokens associated with the victim's Jenkins account. This could allow unauthorized access to sensitive project configurations, source code repositories, and deployment pipelines. Furthermore, attackers may use this vector to perform actions on behalf of the user, such as triggering destructive builds, modifying pipeline definitions, or exfiltrating confidential data stored within the CI/CD environment. The attack surface is expanded because it requires only repository write access rather than direct administrative privileges over Jenkins itself, making it a viable lateral movement technique for attackers who have breached source control systems.
From a classification perspective, this vulnerability aligns with CWE-79 Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting. It also maps to MITRE ATT&CK techniques related to Client-side Execution and potentially Credential Access through browser session manipulation. The lack of proper output encoding violates fundamental web security principles regarding the separation of code and data, allowing user-controllable input to be interpreted as executable commands by the client's browser engine.
Mitigation strategies should focus on immediate remediation and defensive configuration changes. Users running affected versions must upgrade the Jenkins Gitee plugin to a version that includes proper output encoding for all fields rendered in the web interface, particularly those derived from external webhook payloads. In environments where upgrading is not immediately feasible, administrators can implement network-level controls such as Web Application Firewalls configured to detect and block XSS patterns within HTTP request bodies or response headers containing script tags. Additionally, enabling Content Security Policy directives that restrict inline script execution can provide a layer of defense in depth by preventing the injected JavaScript from running even if it is successfully stored in the DOM. Regular auditing of webhook configurations and restricting write access to critical repositories further reduces the risk surface associated with this vulnerability type.