CVE-2023-28672

The Jenkins OctoPerf Load Testing Plugin, versions 4.5.1 and earlier, fails to enforce a permission check on a connection test HTTP endpoint [1]. This means the endpoint is accessible to any authenticated user who holds the Overall/Read permission, which is a relatively low-privilege permission in Jenkins [2]. The root cause is the absence of a required permission check in the servlet or controller that handles connection test requests.

An attacker with Overall/Read permission can exploit this by sending a crafted HTTP request to the connection test endpoint. The attacker can specify both a URL and a credentials ID to be used for that connection [1][2]. If the attacker has previously obtained a valid credentials ID (e.g., via another vulnerability or by guessing), the plugin will use that stored credential to authenticate to the attacker-controlled URL. The attack does not require any further privileges beyond Overall/Read.

The impact is significant: the attacker can capture Jenkins-stored credentials by observing the authentication challenge from their own server [1][2]. If the credential is one that Jenkins uses to authenticate to external services (e.g., API tokens, SSH keys, passwords), exfiltration can lead to lateral movement or compromise of integrated systems. The captured credentials are sent during the connection attempt and can be logged or intercepted by the attacker's server.

Jenkins has released a fix in version 4.5.2 of the OctoPerf Load Testing Plugin [1]. Users should upgrade immediately. As a workaround, administrators can revoke Overall/Read from untrusted users or restrict network access from the Jenkins controller to untrusted destinations. This vulnerability is not known to be on the CISA KEV list as of the publication date [1][2].