Common Weakness Enumeration
CWE-297
AllowedImproper Validation of Certificate with Host Mismatch
Abstraction: Variant · Status: Incomplete
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.
152 vulnerabilities reference this CWE, most recent first.
GHSA-6486-8HJQ-Q8VF
Vulnerability from github – Published: 2026-08-05 18:31 – Updated: 2026-08-05 18:31
VLAI
Details
IBM Business Automation Workflow containers and traditional 26.0.0, 25.0.0 through 25.0.0 Interim Fix 005, 24.0.1 through 24.0.1 Interim Fix 007, and 24.0.0 through 24.0.0 Interim Fix 009 IBM Business Automation Workflow fails to properly verify that the hostname matches the server certificate potentially allowing connections to an attacker-controlled server.
Severity
{
"affected": [],
"aliases": [
"CVE-2026-12730"
],
"database_specific": {
"cwe_ids": [
"CWE-297"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-05T16:16:49Z",
"severity": "LOW"
},
"details": "IBM Business Automation Workflow containers and traditional 26.0.0, 25.0.0 through 25.0.0 Interim Fix 005, 24.0.1 through 24.0.1 Interim Fix 007, and 24.0.0 through 24.0.0 Interim Fix 009 IBM Business Automation Workflow fails to properly verify that the hostname matches the server certificate potentially allowing connections to an attacker-controlled server.",
"id": "GHSA-6486-8hjq-q8vf",
"modified": "2026-08-05T18:31:35Z",
"published": "2026-08-05T18:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12730"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7282596"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
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
{
"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
{
"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)
{
"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
{
"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"
}
GHSA-76QH-XR7Q-H39M
Vulnerability from github – Published: 2026-06-04 18:30 – Updated: 2026-07-15 22:30
VLAI
Summary
OpenStack oslo.messaging does not verify RabbitMQ broker hostname during TLS handshake
Details
An issue was discovered in OpenStack oslo.messaging 1.0.0 through 17.3.0. The oslo.messaging RabbitMQ driver does not perform TLS hostname verification when connecting to the message broker. When ssl_ca_file is configured, the driver enables certificate chain validation but does not pass the expected broker hostname into the underlying TLS stack. Any certificate signed by the deployment CA is accepted regardless of hostname, allowing an attacker who can intercept control-plane traffic to impersonate the RabbitMQ broker and perform a man-in-the-middle attack on RPC and notification traffic. All OpenStack services using oslo.messaging with RabbitMQ over TLS are affected.
Severity
7.4 (High)
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "oslo.messaging"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"last_affected": "17.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44393"
],
"database_specific": {
"cwe_ids": [
"CWE-295",
"CWE-297"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-15T22:30:07Z",
"nvd_published_at": "2026-06-04T16:16:38Z",
"severity": "HIGH"
},
"details": "An issue was discovered in OpenStack oslo.messaging 1.0.0 through 17.3.0. The oslo.messaging RabbitMQ driver does not perform TLS hostname verification when connecting to the message broker. When ssl_ca_file is configured, the driver enables certificate chain validation but does not pass the expected broker hostname into the underlying TLS stack. Any certificate signed by the deployment CA is accepted regardless of hostname, allowing an attacker who can intercept control-plane traffic to impersonate the RabbitMQ broker and perform a man-in-the-middle attack on RPC and notification traffic. All OpenStack services using oslo.messaging with RabbitMQ over TLS are affected.",
"id": "GHSA-76qh-xr7q-h39m",
"modified": "2026-07-15T22:30:07Z",
"published": "2026-06-04T18:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44393"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-44393"
},
{
"type": "WEB",
"url": "https://bugs.launchpad.net/oslo.messaging/+bug/2150316"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2484835"
},
{
"type": "PACKAGE",
"url": "https://github.com/openstack/oslo.messaging"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-44393.json"
},
{
"type": "WEB",
"url": "https://wiki.openstack.org/wiki/OSSN/OSSN-0096"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "OpenStack oslo.messaging does not verify RabbitMQ broker hostname during TLS handshake"
}
GHSA-7J7J-66CV-M239
Vulnerability from github – Published: 2024-04-25 18:31 – Updated: 2024-11-18 16:26
VLAI
Summary
ZITADEL's Improper Lockout Mechanism Leads to MFA Bypass
Details
Impact
ZITADEL provides users the possibility to use Time-based One-Time-Password (TOTP) and One-Time-Password (OTP) through SMS and Email.
While ZITADEL already gives administrators the option to define a Lockout Policy with a maximum amount of failed password check attempts, there was no such mechanism for (T)OTP checks.
Patches
2.x versions are fixed on >= 2.50.0
Workarounds
There is no workaround since a patch is already available.
References
None
Questions
If you have any questions or comments about this advisory, please email us at security@zitadel.com
Credits
Thanks to Jack Moran from Layer 9 Information Security, Ethan from zxsecurity and Amit Laish from GE Vernova for finding and reporting the vulnerability.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/zitadel/zitadel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.50.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-32868"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-297",
"CWE-307"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-25T18:31:31Z",
"nvd_published_at": "2024-04-26T00:15:08Z",
"severity": "HIGH"
},
"details": "### Impact\nZITADEL provides users the possibility to use Time-based One-Time-Password (TOTP) and One-Time-Password (OTP) through SMS and Email.\n\nWhile ZITADEL already gives administrators the option to define a `Lockout Policy` with a maximum amount of failed password check attempts, there was no such mechanism for (T)OTP checks.\n\n### Patches\n2.x versions are fixed on \u003e= [2.50.0](https://github.com/zitadel/zitadel/releases/tag/v2.50.0)\n\n### Workarounds\nThere is no workaround since a patch is already available.\n\n### References\nNone\n\n### Questions\nIf you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)\n\n### Credits\n\nThanks to Jack Moran from Layer 9 Information Security, Ethan from zxsecurity and Amit Laish from GE Vernova for finding and reporting the vulnerability. \n",
"id": "GHSA-7j7j-66cv-m239",
"modified": "2024-11-18T16:26:40Z",
"published": "2024-04-25T18:31:31Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/zitadel/zitadel/security/advisories/GHSA-7j7j-66cv-m239"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32868"
},
{
"type": "PACKAGE",
"url": "https://github.com/zitadel/zitadel"
},
{
"type": "WEB",
"url": "https://github.com/zitadel/zitadel/releases/tag/v2.50.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "ZITADEL\u0027s Improper Lockout Mechanism Leads to MFA Bypass"
}
GHSA-7JWG-HQ85-C6M6
Vulnerability from github – Published: 2022-09-22 00:00 – Updated: 2022-12-06 19:50
VLAI
Summary
Jenkins SmallTest Plugin missing hostname validation
Details
Jenkins SmallTest Plugin 1.0.4 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. There is currently no known workaround or fix for this issue.
Severity
4.8 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.smalltest:smalltest"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.0.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-41243"
],
"database_specific": {
"cwe_ids": [
"CWE-297"
],
"github_reviewed": true,
"github_reviewed_at": "2022-09-23T13:31:37Z",
"nvd_published_at": "2022-09-21T16:15:00Z",
"severity": "MODERATE"
},
"details": "Jenkins SmallTest Plugin 1.0.4 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. There is currently no known workaround or fix for this issue.",
"id": "GHSA-7jwg-hq85-c6m6",
"modified": "2022-12-06T19:50:46Z",
"published": "2022-09-22T00:00:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41243"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/smalltest-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2022-09-21/#SECURITY-2068"
}
],
"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"
}
],
"summary": "Jenkins SmallTest Plugin missing hostname validation"
}
GHSA-7MC8-G97X-QG4J
Vulnerability from github – Published: 2026-09-08 18:32 – Updated: 2026-09-08 18:32
VLAI
Details
A improper validation of certificate with host mismatch vulnerability in Fortinet FortiOS 7.6.1 through 7.6.6, FortiProxy 7.6.2 through 7.6.6 may allow attacker to information disclosure via
Severity
8.1 (High)
{
"affected": [],
"aliases": [
"CVE-2026-84393"
],
"database_specific": {
"cwe_ids": [
"CWE-297"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-08T17:18:37Z",
"severity": "HIGH"
},
"details": "A improper validation of certificate with host mismatch vulnerability in Fortinet FortiOS 7.6.1 through 7.6.6, FortiProxy 7.6.2 through 7.6.6 may allow attacker to information disclosure via \u003cinsert attack vector here\u003e",
"id": "GHSA-7mc8-g97x-qg4j",
"modified": "2026-09-08T18:32:02Z",
"published": "2026-09-08T18:32:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84393"
},
{
"type": "WEB",
"url": "https://fortiguard.fortinet.com/psirt/FG-IR-26-174"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7PWC-H2J2-RJGJ
Vulnerability from github – Published: 2026-05-05 09:31 – Updated: 2026-06-02 22:10
VLAI
Summary
Apache Thrift has an Improper Validation of Certificate with Host Mismatch Vulnerability
Details
Improper Validation of Certificate with Host Mismatch vulnerability in Apache Thrift.
This issue affects Apache Thrift: before 0.23.0.
Users are recommended to upgrade to version 0.23.0, which fixes the issue.
Severity
7.3 (High)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.22.0"
},
"package": {
"ecosystem": "Maven",
"name": "org.apache.thrift:libthrift"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.23.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-43869"
],
"database_specific": {
"cwe_ids": [
"CWE-297"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-08T19:19:58Z",
"nvd_published_at": "2026-05-05T08:16:01Z",
"severity": "HIGH"
},
"details": "Improper Validation of Certificate with Host Mismatch vulnerability in Apache Thrift.\n\nThis issue affects Apache Thrift: before 0.23.0.\n\nUsers are recommended to upgrade to version [0.23.0](https://github.com/apache/thrift/releases/tag/v0.23.0), which fixes the issue.",
"id": "GHSA-7pwc-h2j2-rjgj",
"modified": "2026-06-02T22:10:43Z",
"published": "2026-05-05T09:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43869"
},
{
"type": "WEB",
"url": "https://github.com/apache/thrift/commit/0919c3d5506151514e283a63e1fe1ce83e2449d8"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/thrift"
},
{
"type": "WEB",
"url": "https://github.com/apache/thrift/releases/tag/v0.23.0"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/3hsgl1b69wzq3ry39scqbv2dhyl3j52r"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/05/05/3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Apache Thrift has an Improper Validation of Certificate with Host Mismatch Vulnerability"
}
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.