Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
12 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
In Jenkins Active Directory Plugin 2.41.1 and earlier, the Windows native (ADSI) authentication path does not escape the user name before building the LDAP search filter. This allows unauthenticated attackers to inject LDAP wildcard characters into the user name, enabling them to enumerate directory user and group names, and to authenticate as a matching user when they know that user’s password but not their exact user name. Active Directory Plugin 2.41.2 escapes the user name in the Windows native (ADSI) authentication path before building the LDAP search filter.
Recommended action: Upgrade to 2.41.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins Active Directory Plugin 2.41 and earlier follows LDAP referrals from the configured Active Directory server by default. These can forward to an RMI URL that causes Jenkins to deserialize attacker-controlled data, resulting in Remote Code Execution (RCE) on the Jenkins controller if deserialization "gadgets" are available on the classpath. This allows attackers able to control the configured Active Directory server, or able to perform a machine-in-the-middle attack, to execute code on the Jenkins controller. Active Directory Plugin 2.41.1 no longer follows LDAP referrals by default. Administrators unable to update to a fixed version can start Jenkins with the Java system property hudson.plugins.activedirectory.referral.ignore set to true to mitigate the vulnerability. Administrators of Jenkins controllers requiring following LDAP referrals can set the Java system property hudson.plugins.activedirectory.referral.ignore to false to restore the previous behavior.
Recommended action: Upgrade to 2.41.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins Active Directory Plugin 2.41 and earlier follows LDAP referrals from the configured Active Directory server by default. These can forward to an RMI URL that causes Jenkins to deserialize attacker-controlled data, resulting in Remote Code Execution (RCE) on the Jenkins controller if deserialization "gadgets" are available on the classpath. This allows attackers able to control the configured Active Directory server, or able to perform a machine-in-the-middle attack, to execute code on the Jenkins controller. Active Directory Plugin 2.41.1 no longer follows LDAP referrals by default. Administrators unable to update to a fixed version can start Jenkins with the Java system property hudson.plugins.activedirectory.referral.ignore set to true to mitigate the vulnerability. Administrators of Jenkins controllers requiring following LDAP referrals can set the Java system property hudson.plugins.activedirectory.referral.ignore to false to restore the previous behavior.
Recommended action: Upgrade to 2.41.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins Active Directory Plugin allows testing a new, unsaved configuration by performing a connection test (the button labeled "Test Domain"). Active Directory Plugin 2.30 and earlier ignores the "Require TLS" and "StartTls" options and always performs the connection test to Active directory unencrypted. This allows attackers able to capture network traffic between the Jenkins controller and Active Directory servers to obtain Active Directory credentials. This only affects the connection test. Connections established during the login process are encrypted if the corresponding TLS option is enabled. Active Directory Plugin 2.30.1 considers the "Require TLS" and "StartTls" options for connection tests.
Recommended action: Upgrade to 2.30.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins Active Directory Plugin 2.19 and earlier does not perform a permission check in an HTTP endpoint. This allows attackers with Overall/Read permission to access the domain health check diagnostic page. Jenkins Active Directory Plugin 2.20 requires Overall/Administer permission to access the domain health check diagnostic page.
Recommended action: Upgrade to 2.20 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins Active Directory Plugin implements two separate modes: Integration with ADSI on Windows, and an OS agnostic LDAP-based mode. Optionally, to reduce lookup time, a cache can be configured to remember user lookups and user authentications. In Active Directory Plugin prior to 2.20 and 2.16.1, when run in Windows/ADSI mode, the provided password was not used when looking up an applicable cache entry. This allows attackers to log in as any user using any password while a successful authentication of that user is still in the cache. As a workaround for this issue, the cache can be disabled. Active Directory Plugin 2.20 and 2.16.1 includes the provided password in cache entry lookup. Additionally, the Java system property hudson.plugins.activedirectory.CacheUtil.noCacheAuth can be set to true to no longer cache user authentications.
Recommended action: Upgrade to 2.20 or 2.16.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins Active Directory Plugin implements two separate modes: Integration with ADSI on Windows, and an OS agnostic LDAP-based mode. The LDAP-based mode in Active Directory Plugin starting in version 1.44 and prior to versions 2.16.1 and 2.20 shares code between user lookup and user authentication and distinguishes these behaviors through the use if a magic constant used in place of a real password. This allows attackers to log in as any user if the magic constant is used as the password in Active Directory Plugin prior to 2.16.1 and 220. Active Directory Plugin 2.16.1 and 2.20 no longer uses a magic constant to distinguish between user lookup and user authentication.
Recommended action: Upgrade to 2.20 or 2.16.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins Active Directory Plugin 2.19 and earlier does not require POST requests for multiple HTTP endpoints implementing connection and authentication tests, resulting in cross-site request forgery (CSRF) vulnerabilities. This vulnerability allows attackers to perform connection tests, connecting to attacker-specified or previously configured Active Directory servers using attacker-specified credentials. Active Directory Plugin 2.20 requires POST requests for the affected HTTP endpoints.
Recommended action: Upgrade to 2.20 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins Active Directory Plugin implements two separate modes: Integration with ADSI on Windows, and an OS agnostic LDAP-based mode. The Windows/ADSI mode does not specifically prohibit use of empty passwords in Active Directory Plugin prior to 2.20 and 2.16.1. If the Active Directory server allows the unauthenticated bind operation, this allows attackers to log in to Jenkins as any user by providing an empty password. Jenkins Active Directory Plugin 2.20 and 2.16.1 prohibits the use of an empty password to log in.
Recommended action: Upgrade to 2.20 or 2.16.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
It was found that the Active Directory Plugin for Jenkins up to and including version 2.2 did not verify certificates of the Active Directory server, thereby enabling Man-in-the-Middle attacks.
Recommended action: Upgrade to 2.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An improper certificate validation vulnerability exists in Jenkins Active Directory Plugin 2.10 and earlier in src/main/java/hudson/plugins/activedirectory/ActiveDirectoryDomain.java, src/main/java/hudson/plugins/activedirectory/ActiveDirectorySecurityRealm.java, src/main/java/hudson/plugins/activedirectory/ActiveDirectoryUnixAuthenticationProvider.java that allows attackers to impersonate the Active Directory server Jenkins connects to for authentication if Jenkins is configured to use StartTLS.
Recommended action: Upgrade to 2.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins Active Directory Plugin 2.25 and earlier does not encrypt the transmission of data between the Jenkins controller and Active Directory servers in most configurations.
Recommended action: Upgrade to 2.25.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.