Jenkins Codefresh Integration Plugin 1.8 and earlier disables SSL/TLS and hostname verification globally for the Jenkins master JVM.

Jenkins ElectricFlow Plugin 1.1.5 and earlier disabled SSL/TLS and hostname verification globally for the Jenkins master JVM when MultipartUtility.java is used to upload files.

Jenkins Proxmox Plugin 0.6.0 and earlier disables SSL/TLS certificate validation globally for the Jenkins controller JVM when configured to ignore SSL/TLS issues.

A man in the middle vulnerability exists in Jenkins Inedo BuildMaster Plugin 1.3 and earlier in BuildMasterConfiguration.java, BuildMasterConfig.java, BuildMasterApi.java that allows attackers to impersonate any service that Jenkins connects to.

Jenkins Mailer Plugin 1.32 and earlier does not perform hostname validation when connecting to the configured SMTP server.

Jenkins Email Extension Plugin 2.75 and earlier does not perform hostname validation when connecting to the configured SMTP server.

Jenkins Amazon EC2 Plugin 1.50.1 and earlier unconditionally accepts self-signed certificates and does not perform hostname validation, enabling man-in-the-middle attacks.

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.

It was found that jenkins-ssh-slaves-plugin before version 1.15 did not perform host key verification, thereby enabling Man-in-the-Middle attacks.

Jenkins SAML Single Sign On(SSO) Plugin 2.1.0 and earlier unconditionally disables SSL/TLS certificate validation for connections to miniOrange or the configured IdP to retrieve SAML metadata, which could be abused using a man-in-the-middle attack to intercept these connections.

Jenkins NeuVector Vulnerability Scanner Plugin 1.22 and earlier unconditionally disables SSL/TLS certificate and hostname validation when connecting to a configured NeuVector Vulnerability Scanner server.

Jenkins Image Tag Parameter Plugin 2.0 improperly introduces an option to opt out of SSL/TLS certificate validation when connecting to Docker registries, resulting in job configurations using Image Tag Parameters that were created before 2.0 having SSL/TLS certificate validation disabled by default.

Jenkins View26 Test-Reporting Plugin 1.0.7 and earlier does not perform hostname validation when connecting to the configured View26 server that could be abused using a man-in-the-middle attack to intercept these connections.

A flaw was found in Keycloak. A Keycloak server configured to support mTLS authentication for OAuth/OpenID clients does not properly verify the client certificate chain. A client that possesses a proper certificate can authorize itself as any other client, therefore, access data that belongs to other clients.

Versions of the package djoser before 2.3.0 are vulnerable to Authentication Bypass when the authenticate() function fails. This is because the system falls back to querying the database directly, granting access to users with valid credentials, and eventually bypassing custom authentication checks such as two-factor authentication, LDAP validations, or requirements from configured AUTHENTICATION_BACKENDS.

It was found that SAML authentication in Keycloak 3.4.3.Final incorrectly authenticated expired certificates. A malicious user could use this to access unauthorized data or possibly conduct further attacks.

A flaw was found in JBCS httpd in version 2.4.37 SP3, where it uses a back-end worker SSL certificate with the keystore file's ID is 'unknown'. The validation of the certificate whether CN and hostname are matching stopped working and allow connecting to the back-end work. The highest threat from this vulnerability is to data integrity.

In SPIRE 0.8.1 through 0.8.4 and before versions 0.9.4, 0.10.2, 0.11.3 and 0.12.1, specially crafted requests to the FetchX509SVID RPC of SPIRE Server’s Legacy Node API can result in the possible issuance of an X.509 certificate with a URI SAN for a SPIFFE ID that the agent is not authorized to distribute. Proper controls are in place to require that the caller presents a valid agent certificate that is already authorized to issue at least one SPIFFE ID, and the requested SPIFFE ID belongs to the same trust domain, prior to being able to trigger this vulnerability. This issue has been fixed in SPIRE versions 0.8.5, 0.9.4, 0.10.2, 0.11.3 and 0.12.1.