CVE-2022-45390 is a medium-severity vulnerability identified in the Jenkins loader.io Plugin version 1.0.1 and earlier. Jenkins is a widely used open-source automation server that facilitates continuous integration and continuous delivery (CI/CD) pipelines. The loader.io Plugin integrates the loader.io service with Jenkins, enabling performance testing workflows. The vulnerability arises due to a missing permission check within the plugin, specifically allowing any user with Overall/Read permission on the Jenkins instance to enumerate credential IDs stored in Jenkins. This permission level is relatively low and commonly granted to many users in Jenkins environments, including developers and testers. The flaw is categorized under CWE-862 (Missing Authorization), indicating that the plugin fails to properly enforce authorization controls before disclosing sensitive information. The vulnerability does not allow direct access to credential secrets but enables attackers to enumerate credential identifiers, which could be leveraged in further attacks such as targeted phishing or privilege escalation if combined with other vulnerabilities or misconfigurations. The CVSS v3.1 score is 4.3 (medium), reflecting that the attack vector is network-based (AV:N), requires low attack complexity (AC:L), requires privileges (PR:L) but no user interaction (UI:N), and impacts confidentiality only (C:L), without affecting integrity or availability. No known exploits are reported in the wild, and no official patches have been linked yet. The vulnerability was published on November 15, 2022, and is recognized by the Jenkins project and CISA enrichment.

For European organizations utilizing Jenkins with the loader.io Plugin, this vulnerability poses a risk primarily to the confidentiality of stored credential identifiers. While the direct impact is limited since secrets are not exposed, enumerating credential IDs can aid attackers in reconnaissance, enabling them to identify valuable credentials for further exploitation. This could facilitate targeted attacks, social engineering, or privilege escalation if combined with other vulnerabilities or insider threats. Organizations with large Jenkins deployments, especially those in sectors with stringent compliance requirements (e.g., finance, healthcare, critical infrastructure), may face increased risk due to the potential exposure of credential metadata. Additionally, since Jenkins is often used in DevOps pipelines, any compromise or leakage of credential information can indirectly affect the integrity of software delivery processes. The medium severity and requirement of Overall/Read permission mean that internal users or compromised accounts with limited privileges could exploit this vulnerability, emphasizing the need for strict access control and monitoring. However, the absence of known exploits and the limited scope of impact reduce the immediate threat level.

1. Restrict Overall/Read permissions strictly to trusted users only, minimizing the number of users who can access Jenkins instances with such privileges. 2. Regularly audit user permissions and remove unnecessary access rights, especially for the loader.io Plugin and credential management areas. 3. Monitor Jenkins logs for unusual enumeration activities or repeated access patterns that could indicate exploitation attempts. 4. Implement network segmentation and access controls to limit exposure of Jenkins servers to only necessary personnel and systems. 5. Stay updated with Jenkins project advisories and apply patches or updates to the loader.io Plugin as soon as they become available. 6. Consider disabling or uninstalling the loader.io Plugin if it is not actively used, reducing the attack surface. 7. Employ credential vaulting best practices, such as using ephemeral or short-lived credentials, to limit the impact if credential IDs are enumerated. 8. Integrate Jenkins with centralized authentication and authorization systems (e.g., LDAP, SSO) to enhance access control and auditing capabilities.