Gnutls: gnutls: security bypass due to incorrect name constraint handling

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.

Improper certificate validation for some Intel(R) TDX Workload Attestation software within Ring 3: User Applications may allow an escalation of privilege. Unprivileged software adversary with an unauthenticated user combined with a low complexity attack may enable data manipulation. This result may potentially occur via local access when attack requirements are present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (none), integrity (high) and availability (none) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.

Multiple Vulnerabilities in IBM API Connect

IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote attacker to bypass security restrictions due to improper certificate validation.

Active Directory Domain Services Elevation of Privilege Vulnerability

Improper certificate validation in Windows Active Directory allows an authorized attacker to elevate privileges locally.

Windows Cryptographic Services Security Feature Bypass Vulnerability

Improper certificate validation in Windows Cryptographic Services allows an unauthorized attacker to bypass a security feature over a network.

Improper Certificate Validation in Dell Secure Connect Gateway 5.0 Enables Unauthorized Remote Access

Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Improper Certificate Validation vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to unauthorized access.

Dell Secure Connect Gateway (SCG) Policy Manager, versions prior to 5.34.00.16, Versions prior to 5.36, contains an Improper Certificate Validation vulnerability. An unauthenticated attacker with adjacent network access could potentially exploit this vulnerability, leading to Information disclosure, Information tampering, and Protection mechanism bypass.

Botan: directoryName nameConstraint bypass via multi-AVA RDN flattening in matches_dn

Botan is a C++ cryptography library. Prior to 3.13.0, Botan's X.509 Distinguished Name decoder flattens the Attribute-Value Assertions in each Relative Distinguished Name and loses multi-value RDN grouping before DN name-constraint enforcement. An attacker controlling a name-constrained intermediate CA can issue a certificate with a multi-value RDN whose first Common Name matches the permitted constraint and whose second Common Name is attacker-chosen, causing the constraint check to accept the flattened first value. If the certificate contains no subjectAlternativeName extension, the second Common Name can then be accepted as a hostname; Botan does not fall back to Common Name hostname matching when any subjectAlternativeName is present. The exposure is limited to deployments using DN name constraints, which are uncommon outside internal PKIs, and to certificates without a subjectAlternativeName. This issue is fixed in version 3.13.0.

Active Directory Federation Services (AD FS) Spoofing Vulnerability

No cwe for this issue in Active Directory Federation Services (AD FS) allows an unauthorized attacker to perform spoofing over a network.

Kyverno before 1.19.2 Cosign Identity Check Bypass via Empty SAN Certificates

Kyverno before 1.19.2 contains an authentication bypass in matchCertificateData that skips verifyImages subject and subjectRegExp checks when the signing certificate has no Subject Alternative Name. Attackers holding a leaf certificate from a configured private trust root can omit the SAN, set the expected Fulcio issuer OID, and sign malicious images that are admitted despite signer pinning.

Insecure Server Certificate Addition During Headless IDE Runs

In JetBrains IntelliJ IDEA before 2026.3 improper checks allowed server certificates to be added to the trust store during headless runs

Forge: verifyCertificateChain() removes trusted CA certificates with the same subject from the CA store

Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the affected implementation used pki.verifyCertificateChain(), pki.createCaStore(), duplicate subject names to process the relevant input or security decision. node-forge modified the CA store while trying certificates that shared a subject name during pki.verifyCertificateChain(). A failed chain verification could permanently remove trusted CA certificates from the store, causing later valid chains to fail and creating a persistent availability impact for applications that reused the store. This issue is fixed in version 1.4.1.

Forge: X.509 pathLenConstraint not enforced by verifyCertificateChain() for CA certificates without keyUsage

Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, node-forge enforced an X.509 CA certificate's basicConstraints.pathLenConstraint only when that certificate also carried a keyUsage extension. Exploitation requires a path-length-constrained CA without keyUsage that chains to a root trusted by the application, and an attacker who holds that CA's private key or obtains a subordinate CA certificate from it. The attacker could then construct a chain exceeding the declared path length that still passed pki.verifyCertificateChain(). Public web PKI CA certificates normally include keyUsage; private PKIs with CA certificates created without it are more likely to be affected. This issue is fixed in version 1.4.1.

Forge: X.509 basicConstraints bypass in verifyCertificateChain() via deprecated extension OIDs 2.5.29.10 and 2.5.29.13

Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, node-forge parsed deprecated extension OIDs 2.5.29.10 and 2.5.29.13 as basicConstraints, and pki.verifyCertificateChain() used the first extension with that name. Exploitation requires a CA trusted by the application to issue a certificate carrying an attacker-supplied deprecated-OID extension, commonly because the CA copies extensions from a certificate signing request. By placing a permissive deprecated extension before the genuine 2.5.29.19 basicConstraints extension, the certificate holder could have the certificate accepted as a CA and issue certificates for arbitrary names, enabling server or client impersonation. If the issuing CA adds a keyUsage extension without keyCertSign, node-forge rejects the chain. This issue is fixed in version 1.4.1.

Cryptographic issue in the Security Block-lists, Allow-lists, and other State component

Mozilla blocked compromised intermediate eMudhra certificates via OneCRL on the 17th of October which was distributed to clients via RemoteSettings the same day. This update contains the updated OneCRL block list, ensuring clients will block the compromised certificates even if RemoteSettings is disabled by policy or otherwise unavailable in the user's network environment. This vulnerability was fixed in Firefox 158.0.1, Firefox ESR 153.5.1, Firefox ESR 115.43.1, Thunderbird 158.0.1, Thunderbird 153.5.1, and Firefox 158.0.2.

FreeSWITCH: DTLS-SRTP peer certificate is not bound to the SDP fingerprint when FreeSWITCH is the DTLS server

FreeSWITCH is a Software Defined Telecom Stack enabling the digital transformation from proprietary telecom switches to a software implementation that runs on any commodity hardware. Prior to 1.11.2, dtls_state_setup() compared a peer certificate with the SDP a=fingerprint only when FreeSWITCH was the DTLS client, not when it held the DTLS server role. An unauthenticated peer able to reach the negotiated media port could complete the DTLS-SRTP handshake with an unrelated certificate, obtain the leg's SRTP keys, decrypt and inject media, and displace the legitimate endpoint; on ICE-enabled legs the peer also needs the connectivity-check credentials from SDP, which generally requires signaling visibility or a position on its path. WebRTC and SIP DTLS-SRTP legs are affected whenever the peer selects the active role, while FreeSWITCH client-role handshakes already perform fingerprint validation. Version 1.11.2 introduces the remediation, which requires rtp_dtls_client_cert_verify_mode=fingerprint.

Incorrect validation of TLS certificates in the MatchPoint Android app

Incorrect validation of TLS certificates in the MatchPoint Android app due to a TrustManager that accepts any certificate and a permissive hostname validator. Additionally, the app allows unencrypted HTTP traffic. An attacker capable of intercepting the victim's traffic could read and modify communications, including credentials and personal data.

Malicious IMS Message Leading to Information Exposure via SIP Flow

An attacker may send a malicious IMS message to the target device, potentially leading to information exposure through the SIP message flow.

V Programming Language net.http TLS Certificate Validation Bypass

V programming language standard library net.http through version 0.5.2 prior to commit 4077484 contains a TLS certificate validation bypass vulnerability that allows on-path attackers to intercept HTTPS traffic by exploiting the default false value of SSLConnectConfig.validate and FetchConfig.validate, which completes TLS handshakes without verifying certificates in both the mbedtls and OpenSSL backends. Attackers can present an expired, self-signed, wrong-hostname, or untrusted-root certificate to successfully complete the handshake via http.get, http.post, or http.fetch, enabling interception or modification of HTTPS traffic unless validate: true is explicitly configured.

SSLContext.wrap_bio() missing validation of server_hostname parameter

ssl.SSLContext.wrap_bio() didn't require the server_hostname argument to not be None if ssl.SSLContext.check_hostname was set. Due to a missing parameter check in SSLObject, if the server_hostname argument isn't supplied then hostname verification would be silently skipped. This defect could lead to programs where certificate hostname verification *appeared* to be succeeding with SSLContext.check_hostname = True and no ValueError being raised due to misconfiguration. If the program passes a server_hostname value that isn't an empty string or None to any of these APIs then certificate hostname verification proceeds as expected and the program is not affected by this vulnerability. Mitigating this vulnerability doesn't require updating Python or applying the patch. To mitigate, pass a valid non-None and non-empty server_hostname value to SSLContext.wrap_bio(), asyncio.create_connection(), or asyncio.loop.start_tls() and certificate hostname verification will proceed as expected. Upgrading to the latest version of Python or applying the patch only changes the behavior from silently skipping hostname verification to raising a ValueError, similar to SSLContext.wrap_socket(), when server_hostname isn't supplied.