CVE-2024-23901 is a medium severity vulnerability affecting the Jenkins GitLab Branch Source Plugin, specifically versions 684.vea_fa_7c1e2fe3 and earlier. This plugin integrates Jenkins with GitLab, allowing Jenkins to discover and build projects from GitLab repositories. The vulnerability arises because the plugin unconditionally discovers projects shared with the configured owner group without proper access validation. An attacker who can configure and share a project within the owner group can exploit this flaw to have a crafted Jenkins Pipeline automatically built during the next group scan. This means that an attacker can inject malicious pipeline code that Jenkins will execute, potentially leading to unauthorized code execution within the Jenkins environment. The CVSS 3.1 base score is 6.5 (medium severity), reflecting that the vulnerability can be exploited remotely over the network without authentication or user interaction, and it impacts confidentiality and integrity but not availability. The vulnerability does not require prior privileges or user interaction, making it easier to exploit if the attacker can share a project with the owner group. There are no known exploits in the wild at the time of publication, and no patches or mitigations have been explicitly linked yet. The root cause is insufficient validation of project sharing permissions within the GitLab Branch Source Plugin, leading to unintended pipeline execution of attacker-controlled code.

For European organizations using Jenkins with the GitLab Branch Source Plugin, this vulnerability poses a significant risk. Jenkins is widely used in CI/CD pipelines across industries, including finance, manufacturing, and technology sectors prevalent in Europe. Exploitation could allow attackers to execute arbitrary pipeline code, potentially leading to unauthorized access to build environments, leakage or tampering of source code, and injection of malicious artifacts into software supply chains. This can undermine software integrity and confidentiality, disrupt development workflows, and potentially lead to further compromise of internal networks. The fact that exploitation requires no authentication means that if an attacker can share a project with the owner group (which might be possible in organizations with lax GitLab sharing policies or compromised accounts), they can trigger malicious builds. This risk is heightened in collaborative environments with multiple teams and external contributors. The vulnerability could also be leveraged for lateral movement or persistence within the Jenkins infrastructure, impacting availability indirectly by corrupting build processes.

European organizations should immediately audit their Jenkins GitLab Branch Source Plugin versions and upgrade to a patched version once available. Until a patch is released, organizations should restrict project sharing permissions in GitLab to trusted users only, minimizing the risk that an attacker can share a malicious project with the owner group. Implement strict access controls and review group membership regularly. Additionally, Jenkins administrators should monitor build logs and pipeline configurations for unusual or unauthorized changes. Employ network segmentation to isolate Jenkins servers and limit their access to only necessary resources. Consider disabling automatic scanning or builds triggered by group scans if feasible, or implement manual approval workflows for pipeline execution. Enforce strong authentication and multi-factor authentication (MFA) on GitLab and Jenkins accounts to reduce the risk of account compromise. Finally, maintain an incident response plan to quickly address any signs of exploitation.