Common Weakness Enumeration

CWE-297

Allowed

Improper Validation of Certificate with Host Mismatch

Abstraction: Variant · Status: Incomplete

API response cwe.mitre.org

The product communicates with a host that provides a certificate, but the product does not properly ensure that the certificate is actually associated with that host.

101 vulnerabilities reference this CWE, most recent first.

GHSA-4H8F-2WVX-GG5W

Vulnerability from github – Published: 2024-05-03 18:30 – Updated: 2026-04-17 13:22
VLAI
Summary
Bouncy Castle Java Cryptography API vulnerable to DNS poisoning
Details

An issue was discovered in the Bouncy Castle Crypto Package For Java before BC TLS Java 1.0.19 (ships with BC Java 1.78, BC Java (LTS) 2.73.6) and before BC FIPS TLS Java 1.0.19. When endpoint identification is enabled in the BCJSSE and an SSL socket is created without an explicit hostname (as happens with HttpsURLConnection), hostname verification could be performed against a DNS-resolved IP address in some situations, opening up a possibility of DNS poisoning.

Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.bouncycastle:bcprov-jdk18on"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.61"
            },
            {
              "fixed": "1.78"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.bouncycastle:bcprov-jdk15to18"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.61"
            },
            {
              "fixed": "1.78"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.bouncycastle:bcprov-jdk14"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.61"
            },
            {
              "fixed": "1.78"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.bouncycastle:bcprov-jdk12"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.61"
            },
            {
              "fixed": "1.78"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.bouncycastle:bctls-fips"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.bouncycastle:bcprov-lts8on"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.73.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.bouncycastle:bcprov-jdk15on"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.61"
            },
            {
              "fixed": "1.78"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-34447"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-297"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-03T20:34:32Z",
    "nvd_published_at": "2024-05-03T16:15:11Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in the Bouncy Castle Crypto Package For Java before BC TLS Java 1.0.19 (ships with BC Java 1.78, BC Java (LTS) 2.73.6) and before BC FIPS TLS Java 1.0.19. When endpoint identification is enabled in the BCJSSE and an SSL socket is created without an explicit hostname (as happens with HttpsURLConnection), hostname verification could be performed against a DNS-resolved IP address in some situations, opening up a possibility of DNS poisoning.",
  "id": "GHSA-4h8f-2wvx-gg5w",
  "modified": "2026-04-17T13:22:45Z",
  "published": "2024-05-03T18:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34447"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bcgit/bc-java/issues/1656"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bcgit/bc-java"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902024%E2%80%9034447"
    },
    {
      "type": "WEB",
      "url": "https://www.bouncycastle.org/latest_releases.html"
    },
    {
      "type": "WEB",
      "url": "http://security.netapp.com/advisory/ntap-20240614-0007"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Bouncy Castle Java Cryptography API vulnerable to DNS poisoning"
}

GHSA-4M7W-QMGQ-4WJ5

Vulnerability from github – Published: 2026-06-15 20:11 – Updated: 2026-06-15 20:11
VLAI
Summary
aiohttp: TLS Server Hostname Override Is Ignored When Reusing HTTPS Connections
Details

Summary

The server_hostname TLS SNI check can be bypassed when an existing connection is reused.

Impact

If an application makes multiple requests to the same domain, but with different per-request server_hostname parameters, then the later calls may succeed by reusing the existing connection when they should have been rejected due to the TLS SNI check.

Workaround

Disable keep_alive if you need to change the server_hostname check between requests.

Patch: https://github.com/aio-libs/aiohttp/commit/0ca2b6c28a25726527a8b60f25960262a91ed0e0

Severity
2.7 (Low)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:U
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.14.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "aiohttp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.14.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54275"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-297"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-15T20:11:13Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Summary\n\nThe `server_hostname` TLS SNI check can be bypassed when an existing connection is reused.\n\n### Impact\n\nIf an application makes multiple requests to the same domain, but with different per-request `server_hostname` parameters, then the later calls may succeed by reusing the existing connection when they should have been rejected due to the TLS SNI check.\n\n### Workaround\n\nDisable keep_alive if you need to change the `server_hostname` check between requests.\n\n-----\n\nPatch: https://github.com/aio-libs/aiohttp/commit/0ca2b6c28a25726527a8b60f25960262a91ed0e0",
  "id": "GHSA-4m7w-qmgq-4wj5",
  "modified": "2026-06-15T20:11:13Z",
  "published": "2026-06-15T20:11:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/aio-libs/aiohttp/security/advisories/GHSA-4m7w-qmgq-4wj5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/aio-libs/aiohttp"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "aiohttp: TLS Server Hostname Override Is Ignored When Reusing HTTPS Connections"
}

GHSA-568Q-9FW5-28WF

Vulnerability from github – Published: 2018-10-19 16:53 – Updated: 2020-06-16 21:00
VLAI
Summary
Moderate severity vulnerability that affects org.postgresql:pgjdbc-aggregate
Details

A weakness was found in postgresql-jdbc before version 42.2.5. It was possible to provide an SSL Factory and not check the host name if a host name verifier was not provided to the driver. This could lead to a condition where a man-in-the-middle attacker could masquerade as a trusted server by providing a certificate for the wrong host, as long as it was signed by a trusted CA.

Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.postgresql:pgjdbc-aggregate"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "42.2.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2018-10936"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-297"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T21:00:08Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "A weakness was found in postgresql-jdbc before version 42.2.5. It was possible to provide an SSL Factory and not check the host name if a host name verifier was not provided to the driver. This could lead to a condition where a man-in-the-middle attacker could masquerade as a trusted server by providing a certificate for the wrong host, as long as it was signed by a trusted CA.",
  "id": "GHSA-568q-9fw5-28wf",
  "modified": "2020-06-16T21:00:08Z",
  "published": "2018-10-19T16:53:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-10936"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10936"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-568q-9fw5-28wf"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/9317fd092b257a0815434b116a8af8daea6e920b6673f4fd5583d5fe@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://www.postgresql.org/about/news/1883"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/105220"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Moderate severity vulnerability that affects org.postgresql:pgjdbc-aggregate"
}

GHSA-5CC2-282F-JJQ2

Vulnerability from github – Published: 2026-07-16 09:32 – Updated: 2026-07-16 09:32
VLAI
Details

Improper TLS hostname verification in Snowflake Connector for Python versions prior to 4.7.1 may have allowed a network-positioned attacker to bypass certificate hostname validation on HTTPS connections made by the connector. An attacker with on-path network access could exploit this by intercepting or redirecting network traffic and presenting a certificate signed by any trusted CA for any domain, causing the connector to accept connections without validating that the certificate matched the requested hostname. Successful exploitation requires an on-path traffic interception capability (e.g. ARP/DNS poisoning, rogue access point, BGP hijacking, or malicious proxy/exit node). This vulnerability may have exposed credentials, query data, and staged file contents to interception and tampering, and may have enabled the attacker to issue arbitrary SQL within the context of the victim's connector session. Impact is limited by the privileges of the affected Snowflake role. The fix is available in Snowflake Connector for Python version 4.7.1. Users must manually upgrade.

Severity
9.2 (Critical)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-15925"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-297"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-16T07:16:47Z",
    "severity": "CRITICAL"
  },
  "details": "Improper TLS hostname verification in Snowflake Connector for Python versions prior to 4.7.1 may have allowed a network-positioned attacker to bypass certificate hostname validation on HTTPS connections made by the connector. An attacker with on-path network access could exploit this by intercepting or redirecting network traffic and presenting a certificate signed by any trusted CA for any domain, causing the connector to accept connections without validating that the certificate matched the requested hostname. Successful exploitation requires an on-path traffic interception capability (e.g. ARP/DNS poisoning, rogue access point, BGP hijacking, or malicious proxy/exit node). This vulnerability may have exposed credentials, query data, and staged file contents to interception and tampering, and may have enabled the attacker to issue arbitrary SQL within the context of the victim\u0027s connector session. Impact is limited by the privileges of the affected Snowflake role. The fix is available in Snowflake Connector for Python version 4.7.1. Users must manually upgrade.",
  "id": "GHSA-5cc2-282f-jjq2",
  "modified": "2026-07-16T09:32:17Z",
  "published": "2026-07-16T09:32:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15925"
    },
    {
      "type": "WEB",
      "url": "https://github.com/snowflakedb/snowflake-connector-python/releases/tag/v4.7.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-5FVG-QWCP-R325

Vulnerability from github – Published: 2026-03-03 12:31 – Updated: 2026-03-04 20:17
VLAI
Summary
Apache Ranger Vulnerable to Improper Validation of Certificate with Host Mismatch
Details

Hostname verification bypass issue in Apache Ranger NiFiRegistryClient/NiFiClient is reported in Apache Ranger versions <= 2.7.0.

Users are recommended to upgrade to version 2.8.0, which fixes this issue.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.ranger:ranger-nifi-registry-plugin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-59060"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-297"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-04T20:17:28Z",
    "nvd_published_at": "2026-03-03T11:16:14Z",
    "severity": "MODERATE"
  },
  "details": "Hostname verification bypass issue in Apache Ranger NiFiRegistryClient/NiFiClient is reported in Apache Ranger versions \u003c= 2.7.0.\n\nUsers are recommended to upgrade to version 2.8.0, which fixes this issue.",
  "id": "GHSA-5fvg-qwcp-r325",
  "modified": "2026-03-04T20:17:28Z",
  "published": "2026-03-03T12:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59060"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/ranger"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/c4plx81z3xs86vgl3fd95y3q7hhtff05"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/03/02/4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Apache Ranger Vulnerable to Improper Validation of Certificate with Host Mismatch"
}

GHSA-5GM2-C485-9Q6Q

Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2022-05-24 19:03
VLAI
Details

A flaw was found in rsync in versions since 3.2.0pre1. Rsync improperly validates certificate with host mismatch vulnerability. A remote, unauthenticated attacker could exploit the flaw by performing a man-in-the-middle attack using a valid certificate for another hostname which could compromise confidentiality and integrity of data transmitted using rsync-ssl. The highest threat from this vulnerability is to data confidentiality and integrity. This flaw affects rsync versions before 3.2.4.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-14387"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-297"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-27T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in rsync in versions since 3.2.0pre1. Rsync improperly validates certificate with host mismatch vulnerability. A remote, unauthenticated attacker could exploit the flaw by performing a man-in-the-middle attack using a valid certificate for another hostname which could compromise confidentiality and integrity of data transmitted using rsync-ssl. The highest threat from this vulnerability is to data confidentiality and integrity. This flaw affects rsync versions before 3.2.4.",
  "id": "GHSA-5gm2-c485-9q6q",
  "modified": "2022-05-24T19:03:34Z",
  "published": "2022-05-24T19:03:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14387"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1875549"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-67FW-W8F2-88WP

Vulnerability from github – Published: 2024-08-01 18:32 – Updated: 2024-08-16 18:39
VLAI
Summary
casdoor's use of`ssh.InsecureIgnoreHostKey()` disables host key verification
Details

An issue discovered in casdoor v1.636.0 allows attackers to obtain sensitive information via the ssh.InsecureIgnoreHostKey() method.

Severity
3.7 (Low)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/casdoor/casdoor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.541.0"
            },
            {
              "last_affected": "1.636.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-41264"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-295",
      "CWE-297"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-08-02T13:29:15Z",
    "nvd_published_at": "2024-08-01T16:15:06Z",
    "severity": "MODERATE"
  },
  "details": "An issue discovered in casdoor v1.636.0 allows attackers to obtain sensitive information via the `ssh.InsecureIgnoreHostKey()` method.",
  "id": "GHSA-67fw-w8f2-88wp",
  "modified": "2024-08-16T18:39:40Z",
  "published": "2024-08-01T18:32:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41264"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/nyxfqq/33ceaccbc9b05d439a944c2b55fa1c0f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/casdoor/casdoor"
    },
    {
      "type": "WEB",
      "url": "https://github.com/casdoor/casdoor/blob/v1.636.0/object/viaSSHDialer.go"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2024-3026"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "casdoor\u0027s use of`ssh.InsecureIgnoreHostKey()` disables host key verification"
}

GHSA-6HG6-V5C8-FPHQ

Vulnerability from github – Published: 2026-04-10 18:31 – Updated: 2026-04-14 00:11
VLAI
Summary
Apache Log4j Core: `verifyHostName` attribute silently ignored in TLS configuration
Details

The fix for CVE-2025-68161 was incomplete: it addressed hostname verification only when enabled via the log4j2.sslVerifyHostName system property, but not when configured through the verifyHostName attribute of the <Ssl> element.

Although the verifyHostName configuration attribute was introduced in Log4j Core 2.12.0, it was silently ignored in all versions through 2.25.3, leaving TLS connections vulnerable to interception regardless of the configured value.

A network-based attacker may be able to perform a man-in-the-middle attack when all of the following conditions are met:

  • An SMTP, Socket, or Syslog appender is in use.
  • TLS is configured via a nested element.
  • The attacker can present a certificate issued by a CA trusted by the appender's configured trust store, or by the default Java trust store if none is configured.

This issue does not affect users of the HTTP appender, which uses a separate verifyHostname attribute that was not subject to this bug and verifies host names by default.

Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue.

Severity
6.3 (Medium)
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.logging.log4j:log4j-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.12.0"
            },
            {
              "fixed": "2.25.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.logging.log4j:log4j-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0-alpha1"
            },
            {
              "last_affected": "3.0.0-beta3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34477"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-297"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T00:11:55Z",
    "nvd_published_at": "2026-04-10T16:16:30Z",
    "severity": "MODERATE"
  },
  "details": "The fix for  CVE-2025-68161 was incomplete: it addressed hostname verification only when enabled via the  [`log4j2.sslVerifyHostName`](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property, but not when configured through the [`verifyHostName`](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) attribute of the `\u003cSsl\u003e` element.\n\nAlthough the `verifyHostName` configuration attribute was introduced in Log4j Core 2.12.0, it was silently ignored in all versions through 2.25.3, leaving TLS connections vulnerable to interception regardless of the configured value.\n\nA network-based attacker may be able to perform a man-in-the-middle attack when all of the following conditions are met:\n\n  *  An SMTP, Socket, or Syslog appender is in use.\n  *  TLS is configured via a nested \u003cSsl\u003e element.\n  *  The attacker can present a certificate issued by a CA trusted by the appender\u0027s configured trust store, or by the default Java trust store if none is configured.\n\nThis issue does not affect users of the HTTP appender, which uses a separate [`verifyHostname`](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#HttpAppender-attr-verifyHostName) attribute that was not subject to this bug and verifies host names by default.\n\nUsers are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue.",
  "id": "GHSA-6hg6-v5c8-fphq",
  "modified": "2026-04-14T00:11:55Z",
  "published": "2026-04-10T18:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34477"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/logging-log4j2/pull/4075"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/logging-log4j2"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/lkx8cl46t2bvkcwfcb2pd43ygc097lq4"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/cyclonedx/vdr.xml"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/security.html#CVE-2026-34477"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache Log4j Core: `verifyHostName` attribute silently ignored in TLS configuration"
}

GHSA-6XMJ-596P-G7G7

Vulnerability from github – Published: 2025-06-10 18:32 – Updated: 2025-06-10 18:32
VLAI
Details

A improper validation of certificate with host mismatch in Fortinet FortiClientWindows version 7.4.0, versions 7.2.0 through 7.2.6, and 7.0 all versions allow an unauthorized attacker to redirect VPN connections via DNS spoofing or another form of redirection.

Severity
4.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-54019"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-297"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-10T17:19:40Z",
    "severity": "MODERATE"
  },
  "details": "A improper validation of certificate with host mismatch in Fortinet FortiClientWindows version 7.4.0, versions 7.2.0 through 7.2.6, and 7.0 all versions allow an unauthorized attacker to redirect VPN connections via DNS spoofing or another form of redirection.",
  "id": "GHSA-6xmj-596p-g7g7",
  "modified": "2025-06-10T18:32:27Z",
  "published": "2025-06-10T18:32:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54019"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.fortinet.com/psirt/FG-IR-24-365"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-72QJ-48G4-5XGX

Vulnerability from github – Published: 2025-05-07 17:32 – Updated: 2026-01-21 16:54
VLAI
Summary
JRuby-OpenSSL has hostname verification disabled by default
Details

Summary

When verifying SSL certificates, jruby-openssl is not verifying that the hostname presented in the certificate matches the one we are trying to connect to, meaning a MITM could just present any valid cert for a completely different domain they own, and JRuby wouldn't complain.

Details

n/a

PoC

An example domain bad.substitutealert.com was created to present the a certificate for the domain s8a.me. The following script run in IRB in CRuby 3.4.3 will fail with certificate verify failed (hostname mismatch), but will work just fine in JRuby 10.0.0.0 and JRuby 9.4.2.0, both of which use jruby-openssl version 0.15.3

require "net/http"
require "openssl"

uri   = URI("https://bad.substitutealert.com/")
https = Net::HTTP.new(uri.host, uri.port)
https.use_ssl      = true
https.verify_mode  = OpenSSL::SSL::VERIFY_PEER

body = https.start { https.get(uri.request_uri).body }
puts body

Impact

Anybody using JRuby to make requests of external APIs, or scraping the web, that depends on https to connect securely

Severity
5.7 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "rubygems:jruby-openssl"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.12.1"
            },
            {
              "fixed": "0.15.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jruby:jruby"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0.0"
            },
            {
              "fixed": "10.0.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jruby:jruby"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.3.4.0"
            },
            {
              "fixed": "9.4.12.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "jruby-openssl"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.12.1"
            },
            {
              "fixed": "0.15.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-46551"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295",
      "CWE-297"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-07T17:32:54Z",
    "nvd_published_at": "2025-05-07T17:15:58Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nWhen verifying SSL certificates, jruby-openssl is not verifying that the hostname presented in the certificate matches the one we are trying to connect to, meaning a MITM could just present _any_ valid cert for a completely different domain they own, and JRuby wouldn\u0027t complain. \n\n### Details\nn/a\n\n### PoC\nAn example domain bad.substitutealert.com was created to present the a certificate for the domain s8a.me. The following script run in IRB in CRuby 3.4.3 will fail with `certificate verify failed (hostname mismatch)`, but will work just fine in JRuby 10.0.0.0 and JRuby 9.4.2.0, both of which use jruby-openssl version 0.15.3\n\n```ruby\nrequire \"net/http\"\nrequire \"openssl\"\n\nuri   = URI(\"https://bad.substitutealert.com/\")\nhttps = Net::HTTP.new(uri.host, uri.port)\nhttps.use_ssl      = true\nhttps.verify_mode  = OpenSSL::SSL::VERIFY_PEER\n\nbody = https.start { https.get(uri.request_uri).body }\nputs body\n```\n\n### Impact\nAnybody using JRuby to make requests of external APIs, or scraping the web, that depends on https to connect securely",
  "id": "GHSA-72qj-48g4-5xgx",
  "modified": "2026-01-21T16:54:31Z",
  "published": "2025-05-07T17:32:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jruby/jruby-openssl/security/advisories/GHSA-72qj-48g4-5xgx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46551"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jruby/jruby-openssl/commit/31a56d690ce9b8af47af09aaaf809081949ed285"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jruby/jruby-openssl/commit/b1fc5d645c0d90891b8865925ac1c15e3f15a055"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jruby/jruby-openssl"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/jruby-openssl/CVE-2025-46551.yml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "JRuby-OpenSSL has hostname verification disabled by default"
}
Mitigation
Architecture and Design

Fully check the hostname of the certificate and provide the user with adequate information about the nature of the problem and how to proceed.

Mitigation
Implementation

If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list