| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Impact:
undici's ProxyAgent silently drops the requestTls option when configured with a SOCKS5 proxy URI (socks5:// or socks://). The target HTTPS connection through the SOCKS5 tunnel falls back to Node's default trust store, ignoring user-configured ca, cert, key, rejectUnauthorized, and servername settings.
Applications that pin to an internal or corporate CA via requestTls.ca will, when their proxy URI is SOCKS5, get the default Mozilla CA bundle as the trust anchor instead. Any cert signed by any publicly-trusted CA for the target hostname is accepted, breaking the intended pin and enabling MITM read and tamper of the HTTPS exchange.
Affected applications are those that use undici's ProxyAgent (or Socks5ProxyAgent directly) with SOCKS5 AND rely on requestTls for TLS scope restriction. The bug was introduced in undici 7.23.0 when SOCKS5 support was added.
Patches:
Upgrade to undici v7.28.0 or v8.5.0.
Workarounds:
No workaround is available within the SOCKS5 path. If a SOCKS5 proxy with TLS scope restriction is required and an upgrade is not yet possible, route the traffic through an HTTP-proxy ProxyAgent instead, where requestTls is honored correctly. |
| A flaw was found in the Windows Machine Config Operator (WMCO) for Red Hat OpenShift Container Platform. WMCO establishes SSH connections to Windows worker nodes without verifying the remote server host key. An adjacent-network attacker who can intercept or redirect WMCO's SSH session can capture WICD and kubelet bootstrap credentials transferred during node configuration, enabling compromise of Windows node identities in the cluster. |
| IBM Db2 on Cloud Pak for Data and Db2 Warehouse on Cloud Pak for Data versions 4.8, 5.0, 5.1, 5.2, 5.3 could allow a privileged user to perform operations and obtain sensitive information outside of their authority due to improper token validation. |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. |
| Dell PowerFlex Manager, versions prior to 4.5.1.1, contain an improper certificate validation vulnerability. A remote unauthenticated attacker could potentially exploit this vulnerability leading to man-in-the-middle attack in tandem with DNS cache poisoning. |
| Improper validation of SSH host keys in Canon EOS Network Setting Tool Version 1.5.0 or earlier |
| Improper validation of server certificates in Canon EOS Network Setting Tool Version 1.5.0 or earlier |
| In OCaml-TLS before 2.1.0, the client implementation does insufficient checks of the certificate provided by the server, which allows impersonation with certificates that are not meant for server authentication (because of KeyUsage and ExtendedKeyUsage). |
| In OCaml-TLS before 2.1.0, the server implementation does insufficient checks of the certificate provided by the client (when doing client authentication), which allows impersonation with certificates that are not meant for client authentication (because of KeyUsage and ExtendedKeyUsage). |
| A flaw was found in gnutls. A remote attacker could exploit this vulnerability by presenting a specially crafted certificate that contains Uniform Resource Identifier (URI) or Service (SRV) Subject Alternative Names (SANs). This could cause the certificate validation process to incorrectly fall back to checking DNS hostnames against the Common Name (CN), potentially allowing the attacker to spoof legitimate services or intercept sensitive information. |
| A flaw was found in gnutls. This vulnerability occurs because permitted name constraints were incorrectly ignored when previous Certificate Authorities (CAs) only had excluded name constraints. A remote attacker could exploit this to bypass critical name constraint checks during certificate validation. This bypass could lead to the acceptance of invalid certificates, potentially enabling spoofing or man-in-the-middle attacks against affected systems. |
| An attacker with network-level access between the SUSE Virtualization
and Rancher Manager in SUSE Harvester before 1.8.0 could interfere with the TLS handshake and abuse it
to bypass TLS as a security control. |
| A flaw was found in assisted-migration-agent. The application hardcodes insecure Transport Layer Security (TLS) connections when communicating with vCenter. This vulnerability allows a Man-in-the-Middle (MITM) attacker to intercept and harvest vCenter administrator credentials. This can lead to unauthorized access to vCenter. |
| Issue Summary: An error in the callback used to verify the certificate
provided in a Root CA key update Certificate Management Protocol (CMP)
message response rendered the certificate validation ineffectual, which
could lead to escalation of credentials from the Registration Authority (RA)
level to the root Certification Authority (root CA) level.
Impact Summary: The Registration Autority could replace the root CA
certificate for the CMP clients with an arbitrary root CA certificate.
One of the parts of the Certificate Management Protocol (CMP), specified in
RFC 9810, is Root Certification Authority (root CA) key Rollover,
which is sent by the server in a message with type 'id-it-rootCaKeyUpdate'.
As part of these messages, 'newWithOld' certificate, the new root CA
certificate signed with the old root CA key, is provided, and verifying its
signature is crucial for transferring the trust from the old CA key to the
new one.
The 'id-it-rootCaKeyUpdate' messages are expected to be processed with
OSSL_CMP_get1_rootCaKeyUpdate(), that is expected to verify the 'newWithOld'
certificate. A typo in the certificate chain building code led to adding
an incorrect certificate ('newWithOld' instead of 'oldRoot') to the
certificate chain, rendering the certificate verification process ineffectual
(only the issuer name and the algorithm OIDs were verified by other parts
of the verification code).
An attacker who already has credentials that satisfy the CMP message
protection checks can generate a new key pair and use a crafted self-signed
certificate in its 'id-it-rootCaKeyUpdate' CMP messages which affected CMP
clients would accept as a new trust anchor.
Significant preconditions for the attack (having valid RA-level credentials)
are the reason the issue was assigned Low severity.
The FIPS modules are not affected by this issue, as the affected code is
outside the OpenSSL FIPS module boundary. |
| Idira Endpoint Privilege Manager Agent versions prior to 26.5 exhibit improper access control within internal agent validation processes. A local attacker could potentially bypass built-in security controls or cryptographic validations. Under specific circumstances, this could allow the attacker to circumvent agent self-defense mechanisms and execute unauthorized operations. CyberArk Security Bulletin: CA26-19 |
| Idira Privilege Cloud Connector versions prior 1.1.100504 under specific conditions and configuration scenarios, TLS certificate validation may not be fully enforced. CyberArk Security Bulletin: CA26-17 |
| The crypton-x509-validation Haskell library fails to enforce X.509 NameConstraints, allowing TLS clients to accept certificates whose Subject Alternative Names fall outside the issuing CA’s permitted subtrees. This oversight enables an attacker who compromises a name-constrained sub-CA to impersonate domains beyond its intended scope. |
| Spring Boot's Mail auto-configuration does not enable hostname verification. Applications that set the relevant JavaMail property, such as spring.mail.properties.mail.smtp.ssl.checkserveridentity=true, are not affected.
Affected versions:
Spring Boot 4.0.0 through 4.0.6; 3.5.0 through 3.5.14; 3.4.0 through 3.4.16. |
| Improper comparison with the certificates trusted list in S2OPC allows an attacker well-formed untrusted certificate to be considered trusted |
| A weakness in the certificate validation logic of the deprecated IKEv1 key exchange may allow an unauthenticated attacker positioned as a man-in-the-middle to bypass certificate validation in VPN site-to-site connections that use certificate-based authentication. Successful exploitation could allow interception or modification of traffic traversing the VPN tunnel. |
