MEDIUM 5.4

CVE-2026-57292: Jenkins Gitee Plugin CSRF Vulnerability

Jenkins Gitee Plugin versions up to and including 1288.v18b_deb_c9069b_ contain a cross-site request forgery (CSRF) vulnerability that allows authenticated attackers to force actions on the Jenkins instance without explicit user consent. Specifically, an attacker can trick a logged-in Jenkins administrator or user into unknowingly establishing a connection to an attacker-controlled URL using credentials that the attacker has identified. The vulnerability requires the attacker to already know valid credential IDs within the target Jenkins instance, suggesting a multi-stage attack scenario.

Source data · NVD / CISA · public domain

CVSS
3.1 · 5.4 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Weaknesses (CWE)
CWE-352
Affected products
0 configuration(s)
Published / Modified
2026-06-24 / 2026-06-25

NVD description (verbatim)

A cross-site request forgery (CSRF) vulnerability in Jenkins Gitee Plugin 1288.v18b_deb_c9069b_ and earlier allows attackers to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method.

1 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

The vulnerability is classified as CWE-352 (Cross-Site Request Forgery) with a CVSS v3.1 score of 5.4 (Medium severity). The vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N indicates that the attack is network-accessible, requires low attack complexity, mandates a low privilege level (authenticated user), requires no user interaction once the CSRF is triggered, is confined to the Jenkins scope, and results in low impact to both confidentiality and integrity with no availability impact. The flaw resides in the Gitee Plugin's handling of connection requests, where insufficient CSRF protections allow an attacker to initiate connections to arbitrary URLs on behalf of an authenticated user using pre-existing credential identifiers.

Business impact

This vulnerability poses a moderate risk to Jenkins deployments using the Gitee Plugin. A successful exploit could lead to unauthorized connections being established to external systems, potentially exposing Jenkins credentials or enabling lateral movement within integrated development environments. Organizations integrating Gitee repositories with Jenkins are at direct risk. The attack does not cause direct service disruption or data destruction, but it can compromise the integrity of build pipelines and potentially expose sensitive authentication tokens or configurations to attacker-controlled endpoints.

Affected systems

Jenkins instances with Gitee Plugin version 1288.v18b_deb_c9069b_ and all earlier versions are affected. Organizations should verify their plugin version by navigating to Jenkins > Manage Jenkins > Manage Plugins > Installed and locating the Gitee Plugin entry. The vulnerability impacts any organization using Jenkins with this plugin enabled, regardless of underlying infrastructure or operating system.

Exploitability

The vulnerability requires an authenticated attacker with knowledge of valid credential IDs within the target Jenkins instance. An attacker would typically obtain this information through reconnaissance, prior access, or information disclosure. The attack is delivered via CSRF, meaning the attacker crafts a malicious link or page that a logged-in Jenkins user visits, triggering an unintended action. The low attack complexity and lack of required user interaction (once the CSRF payload is delivered) make this relatively straightforward to exploit for attackers with the necessary preconditions. However, the requirement for authentication and prior knowledge of credential IDs limits the immediate attack surface compared to unauthenticated vulnerabilities.

Remediation

Jenkins administrators should update the Gitee Plugin to a patched version released after 1288.v18b_deb_c9069b_. Verify the specific patched version against the official Jenkins Plugin site or vendor advisory. As an interim mitigation, organizations should enforce strong CSRF token validation at the Jenkins application level and restrict network egress from Jenkins servers to trusted Gitee endpoints and repositories only. Regularly audit and rotate credential IDs to limit the utility of leaked credentials.

Patch guidance

Check the official Jenkins Gitee Plugin repository for the latest available version. Update via Jenkins > Manage Jenkins > Manage Plugins > Updates, or verify the patch version against the vendor advisory before updating. After patching, restart the Jenkins service to ensure the new plugin code is loaded. Test connectivity to Gitee repositories post-update to confirm functionality is preserved. Organizations on extended support cycles should prioritize this update as soon as a patched version is available.

Detection guidance

Monitor Jenkins audit logs and access logs for suspicious connection attempts originating from plugin endpoints. Look for unexpected requests to establish connections to non-standard or external URLs, particularly if they correlate with CSRF-like request patterns (requests without explicit user interaction or from external referrers). Network monitoring can detect outbound connections initiated by Jenkins to unusual or attacker-controlled endpoints. Implement Web Application Firewall (WAF) rules to identify and block CSRF attempts targeting Jenkins administrative interfaces.

Why prioritize this

This vulnerability merits prompt but not emergency-level remediation. The CVSS score of 5.4 places it in the Medium severity range, and the requirement for authentication plus prior knowledge of credential IDs limits immediate exploitability. However, the attack can occur without user awareness once a CSRF payload is delivered, making it a credible lateral movement or credential exposure vector. Organizations heavily invested in Gitee integration with Jenkins should prioritize patching within 30 days. Those with less critical Gitee workflows can extend the timeline to 60 days, provided compensating controls are in place.

Risk score, explained

The CVSS v3.1 score of 5.4 reflects the combination of network accessibility, low attack complexity, and low privilege requirements offset by the mandatory authentication and credential ID knowledge preconditions. The low confidentiality and integrity impacts indicate that the breach does not directly expose all Jenkins data or allow full system compromise, but rather enables unauthorized actions that could lead to credential exposure or lateral movement. The absence of availability impact reflects that the vulnerability does not cause service outages or denial of service.

Frequently asked questions

Does this vulnerability allow unauthenticated attackers to exploit Jenkins?

No. The vulnerability requires an authenticated user with an active Jenkins session. However, in environments where Jenkins is internally accessible or where CSRF defenses are weak, an attacker can trick an authenticated admin into triggering the malicious action without their explicit knowledge.

What is the practical impact if an attacker connects to an unauthorized URL using stolen credential IDs?

An attacker could potentially exfiltrate credentials, access sensitive information from integrated Gitee repositories, or establish persistence through compromised integrations. The exact impact depends on what the attacker-specified URL is configured to do and how the Jenkins instance is networked.

Are versions of Jenkins itself affected, or only the Gitee Plugin?

Only the Gitee Plugin is affected. The core Jenkins application is not vulnerable. However, any Jenkins instance with this plugin installed and enabled is exposed.

Can this vulnerability be exploited without knowing credential IDs in advance?

The CVE description states that attacker-specified credential IDs must be obtained through another method, implying they cannot be discovered as part of the CSRF attack itself. This makes the vulnerability part of a multi-stage attack chain rather than a standalone vulnerability.

This analysis is provided for informational purposes and is based on publicly disclosed vulnerability data as of the publication date. Security teams should verify all recommendations against their own infrastructure and risk models. CVSS scores and vulnerability details are subject to updates from the vendor. Organizations should consult official Jenkins and vendor advisories for definitive patching guidance. This vulnerability intelligence does not constitute a guarantee of security; it is one component of a comprehensive risk management program. Source: NVD (public-domain), retrieved 2026-07-30. Analysis generated by SEC.co (claude-haiku-4-5).