Jenkins Gitee Plugin CVE-2026-57291

Exploitation requires a valid Jenkins user account with at least the Overall/Read permission, which is the lowest non-anonymous role in a standard Jenkins deployment and is commonly granted to all authenticated users in shared CI environments. The attacker must also possess a valid Jenkins credential ID obtained through a separate disclosure method before invoking the vulnerable endpoint - the description explicitly notes credentials IDs are 'obtained through another method,' meaning a two-step attack is required. The Jenkins Gitee Plugin must be installed and active on the target Jenkins controller. Exploitation is limited by the mandatory authentication prerequisite (PR:L) and the secondary step of credential ID enumeration. Organizations where all Jenkins users are fully trusted internal employees face negligible practical risk; the concern is elevated in multi-tenant or contractor-accessible Jenkins deployments.

The CVSS 5.4 Medium rating and the AV:N/AC:L/PR:L profile are internally consistent: network reachability and low complexity are offset by the PR:L requirement, which limits exploitation to users who already hold valid Jenkins credentials. SSVC reinforces a measured posture - exploitation is currently none, the attack is not automatable, and technical impact is only partial. C:L and I:L indicate restricted blast radius: an attacker can probe internal URLs and infer credential ID validity, but cannot directly extract secret values or control Jenkins execution. No EPSS score is available in the provided data, so exploitation probability cannot be quantified numerically. The absence of a KEV listing and any reported POC further reduces urgency. The primary practical risk is internal network reconnaissance (SSRF) from the Jenkins controller host and potential credential ID enumeration, both meaningful in enterprise pipeline environments - but only after the attacker has already cleared the authentication bar.

An attacker with a standard Jenkins account (Overall/Read) first obtains a valid credential ID from the Jenkins store through a secondary information-disclosure method. They then send a crafted HTTP request to the Gitee Plugin's connection-test endpoint, specifying an attacker-controlled server as the target URL and supplying the harvested credential ID. The Jenkins controller issues an outbound TCP connection to the attacker's server, revealing internal network reachability and potentially leaking metadata about the credential in use.