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.

156 vulnerabilities reference this CWE, most recent first.

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-5WF9-H793-W73C

Vulnerability from github – Published: 2026-10-02 22:35 – Updated: 2026-10-02 22:35
VLAI
Summary
Xray-core: Pinning a CA certificate via pinnedPeerCertSha256 can lead to the success of MITM attacks
Details

Summary

Pinning a CA certificate via pinnedPeerCertSha256 can lead to the success of MITM attacks in some cases.

Details

https://github.com/XTLS/Xray-core/blob/45cf2898ab12e97a55dd8f1f3d78d903340bdc9e/transport/internet/tls/config.go#L333-L347

If r.Config.ServerName is empty, DNSName will be empty and certs[0].Verify(opts) will not verify against dNSName or iPAddress.

If a user pins a well-known and non-self-signed CA, an attacker can issue a leaf certificate through the Root CA (using the attacker's own domain name or IP address) and hijack the connections.

In Go crypto/tls, either ServerName or InsecureSkipVerify must be specified in the tls.Config. If the user specifies pinnedPeerCertSha256, InsecureSkipVerify will always be true so ServerName can be empty.

In most cases, if the user does not specify the serverName, Xray-core will use the server address as the r.Config.ServerName.

Thanks to GetTLSConfig(tls.WithDestination(dest)), ServerName will usually not be empty.

However, there are some leftovers:

  • https://github.com/XTLS/Xray-core/blob/45cf2898ab12e97a55dd8f1f3d78d903340bdc9e/transport/internet/hysteria/dialer.go#L348

GetTLSConfig() without tls.WithDestination(dest).

  • https://github.com/XTLS/Xray-core/blob/45cf2898ab12e97a55dd8f1f3d78d903340bdc9e/transport/internet/grpc/dial.go#L139-L142

GetTLSConfig() without tls.WithDestination(dest). Although ServerName will not be empty if address is a domain name, ServerName will be left empty if address is an IP address.

ServerName is not equivalent to SNI.

ServerName is used to verify the hostname on the returned certificates unless InsecureSkipVerify is given. It is also included in the client's handshake to support virtual hosting unless it is an IP address.

In these cases, if the user does not specify the serverName, Xray will not use the server address as the r.Config.ServerName and r.Config.ServerName will be left empty.

PoC

client.json 
{
    "log": {
        "loglevel": "debug"
    },
    "inbounds": [
        {
            "listen": "127.0.0.1",
            "port": 1080,
            "protocol": "socks"
        }
    ],
    "outbounds": [
        {
            "protocol": "hysteria",
            "settings": {
                "address": "127.0.0.1",
                "port": 443,
                "version": 2
            },
            "streamSettings": {
                "security": "tls",
                "network": "hysteria",
                "tlsSettings": {
                    "pinnedPeerCertSha256": "e4aa7ea894c9514ca42831cb0c7548a8eabd5e6f588702b9989790c4985d1b2f"
                },
                "hysteriaSettings": {
                    "version": 2,
                    "auth": "auth"
                }
            }
        }
    ]
}
server.json 
{
    "log": {
        "loglevel": "debug"
    },
    "inbounds": [
        {
            "listen": "127.0.0.1",
            "port": 443,
            "protocol": "hysteria",
            "settings": {
                "version": 2
            },
            "streamSettings": {
                "security": "tls",
                "network": "hysteria",
                "tlsSettings": {
                    "certificates": [
                        {
                            "certificateFile": "server2.crt",
                            "keyFile": "server2.key"
                        }
                    ]
                },
                "hysteriaSettings": {
                    "version": 2,
                    "auth": "auth"
                }
            }
        }
    ],
    "outbounds": [
        {
            "protocol": "freedom"
        }
    ]
}
Both `server1.crt` and `server2.crt` are issued by the same CA. `server1.crt` is subjected to 127.0.0.1. `server2.crt` is subjected to 127.0.0.2. 
xray tls hash --cert server1.crt
Leaf SHA256:       7f0f1a28f96b7d74e60bbbc263a108ac1243345110f77c45e5bc2fe02851551d
CA <Root> SHA256:  e4aa7ea894c9514ca42831cb0c7548a8eabd5e6f588702b9989790c4985d1b2f

xray tls hash --cert server2.crt
Leaf SHA256:       32a842063280252bc746a913dce8e38b526021bfc7a2d784632d413dbee0c69c
CA <Root> SHA256:  e4aa7ea894c9514ca42831cb0c7548a8eabd5e6f588702b9989790c4985d1b2f
server1.crt 
-----BEGIN CERTIFICATE-----
MIIDMjCCAhqgAwIBAgIUEt5YzaTYeiyClv/htnnbK8FJ70wwDQYJKoZIhvcNAQEL
BQAwDzENMAsGA1UEAwwEUm9vdDAeFw0yNjA3MDMxMDE0MzZaFw0zNjA2MzAxMDE0
MzZaMBQxEjAQBgNVBAMMCTEyNy4wLjAuMTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAIbLr7M4oU6JPvjnSfkks6oyBl6+j2Ykl32uJX953n/rd1+AO+60
6zzx32eLh0EFGO7SvAsXEsklcGmrwduxCgv7RPjJyMK4pcZ8d3OF5ZxhBJH5i83K
cZkTBNu/oKgAJ75BmjVh5LP3rnMASWTLntpK3sfRcXAaZpvvyCSeKQTsoxmRNSzB
S3JPvtbbpQ7Q2RgH/ZOcRTNp7jjxCdXut1oTWM3R/MX2YSYf7+lIL0T7g04dp0oI
y344uIZISNYFq6LSK2ZLbVqhqC45Zg+TQmqnC3fvhAUPIOxUeJKtf+E2F1qjuXWb
y/dk5885n95ooZ2PqXi6mkfluNzt5CcoqU0CAwEAAaOBgDB+MAkGA1UdEwQCMAAw
CwYDVR0PBAQDAgQwMBMGA1UdJQQMMAoGCCsGAQUFBwMBMA8GA1UdEQQIMAaHBH8A
AAEwHQYDVR0OBBYEFLKSHMaY2Q/VrQYf+dnPctzkYeX9MB8GA1UdIwQYMBaAFAaO
Ih36y0UgXPa9z7/hUwvaasqmMA0GCSqGSIb3DQEBCwUAA4IBAQCvWejnbhNuGrFR
L3FSeFcLXSyNEMl43E0ClUmQ6bZz1wC3C5nPwYijpUatf2s4pCTt6yBPLR4+AgdD
e6IR8qJqU1HC6uKtr4beVLx1900K+7AM9nMIW9reOHVvSmiUb7zbw/xfBBbU/ssw
M30/bM2KaI6d7av7Co1M4PoQfSop9PIN8TNAJSywCstmUara72/qt0I0QDJ433Cy
U5tjtOLDBPszzeS4f7wbTb5V3KULebc6KkjUidrW8E3qFeXaQ/o34huNmYT9HXCS
/v/eWrmUSsroYk+tyBARW2dXZ1CQgdOXd9cxKNaRTUm3glprCWQdNN8Gtu5yyWRQ
29bSzHij
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDATCCAemgAwIBAgIURtJTQ4YzS/SJSsVG2pyuRg4tBg8wDQYJKoZIhvcNAQEL
BQAwDzENMAsGA1UEAwwEUm9vdDAgFw0yNjA3MDMxMDExNTlaGA8yMTI2MDYwOTEw
MTE1OVowDzENMAsGA1UEAwwEUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBANLlP546TAp9/dns0xk482z0ZCVdBbh7BaMx4sY/4Mdu0RatYdp+6yL7
dTzJJX3rb+NdsVbpozj/660DS1SN0osNa7Nm1cp2CXf39PdKJ5WrbY1UCuE5cD6n
W7qFTLZR/52RnN0UoththnNyjurEf3m8GTtFOrfmH6qT6psZmgRefLh/OZT6PXUT
ZKPBHFhOr1YkuwO2D15pnRZ/2OBBkExsjyv5Y/m8IJfd+qK8rPrzJavRNEjfClfN
3ScZEE1eOdrutuxRNpawEIB3gLfp/zWbZe/jMRyqrOAy1Bqy1JpwaeAJn96DShru
6S8xim6PkvqY4mqOdTTCz/sgy/XLRicCAwEAAaNTMFEwHQYDVR0OBBYEFAaOIh36
y0UgXPa9z7/hUwvaasqmMB8GA1UdIwQYMBaAFAaOIh36y0UgXPa9z7/hUwvaasqm
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBALqZN9Rk7LIPqjzb
h3Z4iTVYdZXnUckPKVF0pH2Xx4R5Bcgb3XbptpRViisit3Ltwn8CfR7SYq4mYbnN
/l3ty9neR1KPDtE8CgM1lLqw1t5iN+OW60S1cYlrJFGxGUdr5W9Z/toH9lDWCxsg
T9+ooe+9hx4F8bw3Nnslt+FiDzbjMNOGxPzw7RZFV8n8JzxpIOaXO5quDSuoDdir
kXV4FO0kl19EesaUyavy0Rc3sef8vyAvbT1CmjRd3LLpGWlaTrii0xVfq2YY7Jf7
6Tb9fpJLOoAv4nWC82zZ0U94c7ffM4P+P7/qMO1R1PM0qHdsEo/O+FXwUdnkOwNs
6+IZCAM=
-----END CERTIFICATE-----
server2.crt 
-----BEGIN CERTIFICATE-----
MIIDMjCCAhqgAwIBAgIUEt5YzaTYeiyClv/htnnbK8FJ700wDQYJKoZIhvcNAQEL
BQAwDzENMAsGA1UEAwwEUm9vdDAeFw0yNjA3MDMxMDE1MjZaFw0zNjA2MzAxMDE1
MjZaMBQxEjAQBgNVBAMMCTEyNy4wLjAuMjCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAJjuTx6SOgwTqubOWTGzTf5iQ3nKRyYCHypmcyDLKASaV9n6+oDz
WL9Lp9iR4uOrOyOr26eu8bud/yBnFiRz8pAP74ixjFIP8tgDZeSe4rr/4jAKi/Al
1OhQSjvKyaIpSz4uM4H39dQwDyL2hJnKDYmUa7J582b2EgYU7vro6ZvifCIh/i0q
ZIgVOJdWkjT+x8xAxfqW3/hC0cA03Ajc3XBPEBGOTASZca8IT10sdgUiBGMHMeBW
HLLzz887EdpPn864sy5cQj509ekEP7jc3EBxnxwpqyqktr+Q+h8ExWM7CVIy9Z+H
ORT2TxzxefoYFY28a6P7VJ2NNnRJFgIpPf0CAwEAAaOBgDB+MAkGA1UdEwQCMAAw
CwYDVR0PBAQDAgQwMBMGA1UdJQQMMAoGCCsGAQUFBwMBMA8GA1UdEQQIMAaHBH8A
AAIwHQYDVR0OBBYEFKsSvs+FuZ6lJawi4f7IjAUpfOOBMB8GA1UdIwQYMBaAFAaO
Ih36y0UgXPa9z7/hUwvaasqmMA0GCSqGSIb3DQEBCwUAA4IBAQBW6Vj7cwNkD6Mm
z7kmAl8Xhqste0KcafJzFXaJLHJLfH2ICQ5MtvtyRv+fFbfI2TqfYrQOZWybLJ1I
L/MpsccRqMGVvhpe3PNyQKgGnflGpLgN8DsswzrYqFUiWAamJ2GLEz/0DHwGqiy5
Vn4ATcx53Mm4tbWF+87Ul7AlfKaj7YgFq3t1UJWUWBt4GVcQJzSn2Yl2J7vnek4u
t7kYrnhw44IBt8Oz2StRH89gulbplVCwJRimmkJQyhK73M2PfRwTOaDSjHqE0FA7
t5JXK1zts2WyP6tZWtyUIDq6hSdvYjyxGffZ5kt810sjcyrk/TnOhFXRuiC5eoXX
DfQWbk1o
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDATCCAemgAwIBAgIURtJTQ4YzS/SJSsVG2pyuRg4tBg8wDQYJKoZIhvcNAQEL
BQAwDzENMAsGA1UEAwwEUm9vdDAgFw0yNjA3MDMxMDExNTlaGA8yMTI2MDYwOTEw
MTE1OVowDzENMAsGA1UEAwwEUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBANLlP546TAp9/dns0xk482z0ZCVdBbh7BaMx4sY/4Mdu0RatYdp+6yL7
dTzJJX3rb+NdsVbpozj/660DS1SN0osNa7Nm1cp2CXf39PdKJ5WrbY1UCuE5cD6n
W7qFTLZR/52RnN0UoththnNyjurEf3m8GTtFOrfmH6qT6psZmgRefLh/OZT6PXUT
ZKPBHFhOr1YkuwO2D15pnRZ/2OBBkExsjyv5Y/m8IJfd+qK8rPrzJavRNEjfClfN
3ScZEE1eOdrutuxRNpawEIB3gLfp/zWbZe/jMRyqrOAy1Bqy1JpwaeAJn96DShru
6S8xim6PkvqY4mqOdTTCz/sgy/XLRicCAwEAAaNTMFEwHQYDVR0OBBYEFAaOIh36
y0UgXPa9z7/hUwvaasqmMB8GA1UdIwQYMBaAFAaOIh36y0UgXPa9z7/hUwvaasqm
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBALqZN9Rk7LIPqjzb
h3Z4iTVYdZXnUckPKVF0pH2Xx4R5Bcgb3XbptpRViisit3Ltwn8CfR7SYq4mYbnN
/l3ty9neR1KPDtE8CgM1lLqw1t5iN+OW60S1cYlrJFGxGUdr5W9Z/toH9lDWCxsg
T9+ooe+9hx4F8bw3Nnslt+FiDzbjMNOGxPzw7RZFV8n8JzxpIOaXO5quDSuoDdir
kXV4FO0kl19EesaUyavy0Rc3sef8vyAvbT1CmjRd3LLpGWlaTrii0xVfq2YY7Jf7
6Tb9fpJLOoAv4nWC82zZ0U94c7ffM4P+P7/qMO1R1PM0qHdsEo/O+FXwUdnkOwNs
6+IZCAM=
-----END CERTIFICATE-----
server2.key 
-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQCY7k8ekjoME6rm
zlkxs03+YkN5ykcmAh8qZnMgyygEmlfZ+vqA81i/S6fYkeLjqzsjq9unrvG7nf8g
ZxYkc/KQD++IsYxSD/LYA2XknuK6/+IwCovwJdToUEo7ysmiKUs+LjOB9/XUMA8i
9oSZyg2JlGuyefNm9hIGFO766Omb4nwiIf4tKmSIFTiXVpI0/sfMQMX6lt/4QtHA
NNwI3N1wTxARjkwEmXGvCE9dLHYFIgRjBzHgVhyy88/POxHaT5/OuLMuXEI+dPXp
BD+43NxAcZ8cKasqpLa/kPofBMVjOwlSMvWfhzkU9k8c8Xn6GBWNvGuj+1SdjTZ0
SRYCKT39AgMBAAECggEABa+oq/GSbHQHwPSvrtAkqH51VVAu1Iw0JfKwuamsF324
of95tHU32ccBmuUTu1TYylL/xAyWatwtSgJjOaBBBte814eIeN2kcSExNu6sbfkJ
KzGdMeTqNWgU1oPL+vZPmKSFoEG8t3LBAVMKq6AuYCzvUy/DG9Mu6OB64UPrObND
neXZT8YZ2Ux0vEV9BAc0z+9tdWVjBy+l5ei6wpjhP69GZiVOsLmKTg/MDT4FN+Pi
WJbyHcL1IKTRxxNxDPInBKhEMrxKKAABeXlp5nwnz0gkgUoxK3YHZmxAPr6yCcHP
ffeMjpE5BaRKzhimKrOJB4LUES24ltjo+5v5GmZzYQKBgQDSbhiNQpmhOk4ICzwJ
8DMCAigaDm2cD/qC66OFrHhQfr7EC9MRKKC/8WlZYgNepxZ1ZM95+GJu5aTsh7d2
HknwJkxkbTadfRcch9HQun68Y814G0LBDuDRRc9OnBQW6Gr4jTFDP+uqQl6gAfu4
QOjATymrRa5S/21MkQ3Ryb5H4QKBgQC6DI1ETmfvXCOVpEUM9IjeEbiAjVYbUjBL
GEOhE0izOv8mjSEgifMSEXJMn58F4nW/UoxtDobTAhQ/WO5BUVCEeQnOAXhV57jU
/t/fBbdC7nrVnfFl9KmsOV3LcxUo0yE/x7UiHd1QlwtOTl1KPFQa9WpSehxjjQAS
mHYM5PhJnQKBgQCIGHCEm/hkkCL7jNiNzO4QdHifMYmuj58DoYcm4z8FQJP8k3E0
/cPJoEb0ajGnvAUIc+TEC+MNujSKTdRX7or/aKWrpf7WqJqT9zu59YQWL64p6eeo
mQjKEI5dVxCfKD5W9mpQBj1S5o3wipfUuRZPmmNmxDBUuaJlDMOVVRddwQKBgCUl
bmst8GiFEAHHq5W7mTwlc54PGhsYXNYRgSc+72wBooHy+aNCh8qauyR7VkfZgELz
21/G37pvltVTDzbxYk8gz4lXF8ynGGtGfDJONNnjPZk7EMCXiez+AzEkyBu/k8rl
N9AZAGAf2D0JPm0dAHnleBYBlXt24oXT9PX8HWqtAoGBALRX6V1U+bKwMih3N21b
1w/ELI7L1BBAPqJxiQPSOa7kshamZgFenbH1wFLIXz6YwaEOOmYiId6lFjcJaBbF
+R4HfxBhOuY6cvD0vEROIRntaqsj4zJXahlZZ9uG1EAYrY2tGKkCUMKN2IBE+WWS
3YTH4WIOsCZriuaHIAyjsCcv
-----END PRIVATE KEY-----

Expected behavior: The client will fail to establish the connection.

Actual behavior: The client succeeds in establishing the connection.

Impact

Xray-core from v26.1.13 to the latest version

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/xtls/xray-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.260113.0"
            },
            {
              "fixed": "1.260327.1-0.20260710210335-64fada32b5b9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-297"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-02T22:35:51Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nPinning a CA certificate via `pinnedPeerCertSha256` can lead to the success of MITM attacks in some cases.\n\n### Details\n\nhttps://github.com/XTLS/Xray-core/blob/45cf2898ab12e97a55dd8f1f3d78d903340bdc9e/transport/internet/tls/config.go#L333-L347\n\nIf `r.Config.ServerName` is empty, `DNSName` will be empty and `certs[0].Verify(opts)` will not verify against dNSName or iPAddress.\n\nIf a user pins a well-known and non-self-signed CA, an attacker can issue a leaf certificate through the Root CA (using the attacker\u0027s own domain name or IP address) and hijack the connections.\n\nIn Go crypto/tls, either ServerName or InsecureSkipVerify must be specified in the `tls.Config`. If the user specifies `pinnedPeerCertSha256`, InsecureSkipVerify will always be true so  ServerName can be empty.\n\nIn most cases, if the user does not specify the `serverName`, Xray-core will use the server address as the `r.Config.ServerName`.\n\nThanks to `GetTLSConfig(tls.WithDestination(dest))`, ServerName will usually not be empty.\n\nHowever, there are some leftovers:\n\n- https://github.com/XTLS/Xray-core/blob/45cf2898ab12e97a55dd8f1f3d78d903340bdc9e/transport/internet/hysteria/dialer.go#L348\n\n  `GetTLSConfig()` without `tls.WithDestination(dest)`.\n\n- https://github.com/XTLS/Xray-core/blob/45cf2898ab12e97a55dd8f1f3d78d903340bdc9e/transport/internet/grpc/dial.go#L139-L142\n\n  `GetTLSConfig()` without `tls.WithDestination(dest)`. Although ServerName will not be empty if `address` is a domain name, ServerName will be left empty if `address` is an IP address.\n\n  ServerName is not equivalent to SNI.\n\n  \u003e ServerName is used to verify the hostname on the returned certificates unless InsecureSkipVerify is given. It is also included in the client\u0027s handshake to support virtual hosting unless it is an IP address.\n\nIn these cases, if the user does not specify the `serverName`, Xray will not use the server address as the `r.Config.ServerName` and `r.Config.ServerName` will be left empty.\n\n\n### PoC\n\n\u003cdetails\u003e\n\nclient.json\n```json\n{\n\t\"log\": {\n\t\t\"loglevel\": \"debug\"\n\t},\n\t\"inbounds\": [\n\t\t{\n\t\t\t\"listen\": \"127.0.0.1\",\n\t\t\t\"port\": 1080,\n\t\t\t\"protocol\": \"socks\"\n\t\t}\n\t],\n\t\"outbounds\": [\n\t\t{\n\t\t\t\"protocol\": \"hysteria\",\n\t\t\t\"settings\": {\n\t\t\t\t\"address\": \"127.0.0.1\",\n\t\t\t\t\"port\": 443,\n\t\t\t\t\"version\": 2\n\t\t\t},\n\t\t\t\"streamSettings\": {\n\t\t\t\t\"security\": \"tls\",\n\t\t\t\t\"network\": \"hysteria\",\n\t\t\t\t\"tlsSettings\": {\n\t\t\t\t\t\"pinnedPeerCertSha256\": \"e4aa7ea894c9514ca42831cb0c7548a8eabd5e6f588702b9989790c4985d1b2f\"\n\t\t\t\t},\n\t\t\t\t\"hysteriaSettings\": {\n\t\t\t\t\t\"version\": 2,\n\t\t\t\t\t\"auth\": \"auth\"\n\t\t\t\t}\n\t\t\t}\n\t\t}\n\t]\n}\n```\n\nserver.json\n```json\n{\n\t\"log\": {\n\t\t\"loglevel\": \"debug\"\n\t},\n\t\"inbounds\": [\n\t\t{\n\t\t\t\"listen\": \"127.0.0.1\",\n\t\t\t\"port\": 443,\n\t\t\t\"protocol\": \"hysteria\",\n\t\t\t\"settings\": {\n\t\t\t\t\"version\": 2\n\t\t\t},\n\t\t\t\"streamSettings\": {\n\t\t\t\t\"security\": \"tls\",\n\t\t\t\t\"network\": \"hysteria\",\n\t\t\t\t\"tlsSettings\": {\n\t\t\t\t\t\"certificates\": [\n\t\t\t\t\t\t{\n\t\t\t\t\t\t\t\"certificateFile\": \"server2.crt\",\n\t\t\t\t\t\t\t\"keyFile\": \"server2.key\"\n\t\t\t\t\t\t}\n\t\t\t\t\t]\n\t\t\t\t},\n\t\t\t\t\"hysteriaSettings\": {\n\t\t\t\t\t\"version\": 2,\n\t\t\t\t\t\"auth\": \"auth\"\n\t\t\t\t}\n\t\t\t}\n\t\t}\n\t],\n\t\"outbounds\": [\n\t\t{\n\t\t\t\"protocol\": \"freedom\"\n\t\t}\n\t]\n}\n```\n\nBoth `server1.crt` and `server2.crt` are issued by the same CA.\n`server1.crt` is subjected to 127.0.0.1.\n`server2.crt` is subjected to 127.0.0.2.\n\n```\nxray tls hash --cert server1.crt\nLeaf SHA256:       7f0f1a28f96b7d74e60bbbc263a108ac1243345110f77c45e5bc2fe02851551d\nCA \u003cRoot\u003e SHA256:  e4aa7ea894c9514ca42831cb0c7548a8eabd5e6f588702b9989790c4985d1b2f\n\nxray tls hash --cert server2.crt\nLeaf SHA256:       32a842063280252bc746a913dce8e38b526021bfc7a2d784632d413dbee0c69c\nCA \u003cRoot\u003e SHA256:  e4aa7ea894c9514ca42831cb0c7548a8eabd5e6f588702b9989790c4985d1b2f\n```\n\nserver1.crt\n```\n-----BEGIN CERTIFICATE-----\nMIIDMjCCAhqgAwIBAgIUEt5YzaTYeiyClv/htnnbK8FJ70wwDQYJKoZIhvcNAQEL\nBQAwDzENMAsGA1UEAwwEUm9vdDAeFw0yNjA3MDMxMDE0MzZaFw0zNjA2MzAxMDE0\nMzZaMBQxEjAQBgNVBAMMCTEyNy4wLjAuMTCCASIwDQYJKoZIhvcNAQEBBQADggEP\nADCCAQoCggEBAIbLr7M4oU6JPvjnSfkks6oyBl6+j2Ykl32uJX953n/rd1+AO+60\n6zzx32eLh0EFGO7SvAsXEsklcGmrwduxCgv7RPjJyMK4pcZ8d3OF5ZxhBJH5i83K\ncZkTBNu/oKgAJ75BmjVh5LP3rnMASWTLntpK3sfRcXAaZpvvyCSeKQTsoxmRNSzB\nS3JPvtbbpQ7Q2RgH/ZOcRTNp7jjxCdXut1oTWM3R/MX2YSYf7+lIL0T7g04dp0oI\ny344uIZISNYFq6LSK2ZLbVqhqC45Zg+TQmqnC3fvhAUPIOxUeJKtf+E2F1qjuXWb\ny/dk5885n95ooZ2PqXi6mkfluNzt5CcoqU0CAwEAAaOBgDB+MAkGA1UdEwQCMAAw\nCwYDVR0PBAQDAgQwMBMGA1UdJQQMMAoGCCsGAQUFBwMBMA8GA1UdEQQIMAaHBH8A\nAAEwHQYDVR0OBBYEFLKSHMaY2Q/VrQYf+dnPctzkYeX9MB8GA1UdIwQYMBaAFAaO\nIh36y0UgXPa9z7/hUwvaasqmMA0GCSqGSIb3DQEBCwUAA4IBAQCvWejnbhNuGrFR\nL3FSeFcLXSyNEMl43E0ClUmQ6bZz1wC3C5nPwYijpUatf2s4pCTt6yBPLR4+AgdD\ne6IR8qJqU1HC6uKtr4beVLx1900K+7AM9nMIW9reOHVvSmiUb7zbw/xfBBbU/ssw\nM30/bM2KaI6d7av7Co1M4PoQfSop9PIN8TNAJSywCstmUara72/qt0I0QDJ433Cy\nU5tjtOLDBPszzeS4f7wbTb5V3KULebc6KkjUidrW8E3qFeXaQ/o34huNmYT9HXCS\n/v/eWrmUSsroYk+tyBARW2dXZ1CQgdOXd9cxKNaRTUm3glprCWQdNN8Gtu5yyWRQ\n29bSzHij\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\nMIIDATCCAemgAwIBAgIURtJTQ4YzS/SJSsVG2pyuRg4tBg8wDQYJKoZIhvcNAQEL\nBQAwDzENMAsGA1UEAwwEUm9vdDAgFw0yNjA3MDMxMDExNTlaGA8yMTI2MDYwOTEw\nMTE1OVowDzENMAsGA1UEAwwEUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC\nAQoCggEBANLlP546TAp9/dns0xk482z0ZCVdBbh7BaMx4sY/4Mdu0RatYdp+6yL7\ndTzJJX3rb+NdsVbpozj/660DS1SN0osNa7Nm1cp2CXf39PdKJ5WrbY1UCuE5cD6n\nW7qFTLZR/52RnN0UoththnNyjurEf3m8GTtFOrfmH6qT6psZmgRefLh/OZT6PXUT\nZKPBHFhOr1YkuwO2D15pnRZ/2OBBkExsjyv5Y/m8IJfd+qK8rPrzJavRNEjfClfN\n3ScZEE1eOdrutuxRNpawEIB3gLfp/zWbZe/jMRyqrOAy1Bqy1JpwaeAJn96DShru\n6S8xim6PkvqY4mqOdTTCz/sgy/XLRicCAwEAAaNTMFEwHQYDVR0OBBYEFAaOIh36\ny0UgXPa9z7/hUwvaasqmMB8GA1UdIwQYMBaAFAaOIh36y0UgXPa9z7/hUwvaasqm\nMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBALqZN9Rk7LIPqjzb\nh3Z4iTVYdZXnUckPKVF0pH2Xx4R5Bcgb3XbptpRViisit3Ltwn8CfR7SYq4mYbnN\n/l3ty9neR1KPDtE8CgM1lLqw1t5iN+OW60S1cYlrJFGxGUdr5W9Z/toH9lDWCxsg\nT9+ooe+9hx4F8bw3Nnslt+FiDzbjMNOGxPzw7RZFV8n8JzxpIOaXO5quDSuoDdir\nkXV4FO0kl19EesaUyavy0Rc3sef8vyAvbT1CmjRd3LLpGWlaTrii0xVfq2YY7Jf7\n6Tb9fpJLOoAv4nWC82zZ0U94c7ffM4P+P7/qMO1R1PM0qHdsEo/O+FXwUdnkOwNs\n6+IZCAM=\n-----END CERTIFICATE-----\n```\n\nserver2.crt\n```\n-----BEGIN CERTIFICATE-----\nMIIDMjCCAhqgAwIBAgIUEt5YzaTYeiyClv/htnnbK8FJ700wDQYJKoZIhvcNAQEL\nBQAwDzENMAsGA1UEAwwEUm9vdDAeFw0yNjA3MDMxMDE1MjZaFw0zNjA2MzAxMDE1\nMjZaMBQxEjAQBgNVBAMMCTEyNy4wLjAuMjCCASIwDQYJKoZIhvcNAQEBBQADggEP\nADCCAQoCggEBAJjuTx6SOgwTqubOWTGzTf5iQ3nKRyYCHypmcyDLKASaV9n6+oDz\nWL9Lp9iR4uOrOyOr26eu8bud/yBnFiRz8pAP74ixjFIP8tgDZeSe4rr/4jAKi/Al\n1OhQSjvKyaIpSz4uM4H39dQwDyL2hJnKDYmUa7J582b2EgYU7vro6ZvifCIh/i0q\nZIgVOJdWkjT+x8xAxfqW3/hC0cA03Ajc3XBPEBGOTASZca8IT10sdgUiBGMHMeBW\nHLLzz887EdpPn864sy5cQj509ekEP7jc3EBxnxwpqyqktr+Q+h8ExWM7CVIy9Z+H\nORT2TxzxefoYFY28a6P7VJ2NNnRJFgIpPf0CAwEAAaOBgDB+MAkGA1UdEwQCMAAw\nCwYDVR0PBAQDAgQwMBMGA1UdJQQMMAoGCCsGAQUFBwMBMA8GA1UdEQQIMAaHBH8A\nAAIwHQYDVR0OBBYEFKsSvs+FuZ6lJawi4f7IjAUpfOOBMB8GA1UdIwQYMBaAFAaO\nIh36y0UgXPa9z7/hUwvaasqmMA0GCSqGSIb3DQEBCwUAA4IBAQBW6Vj7cwNkD6Mm\nz7kmAl8Xhqste0KcafJzFXaJLHJLfH2ICQ5MtvtyRv+fFbfI2TqfYrQOZWybLJ1I\nL/MpsccRqMGVvhpe3PNyQKgGnflGpLgN8DsswzrYqFUiWAamJ2GLEz/0DHwGqiy5\nVn4ATcx53Mm4tbWF+87Ul7AlfKaj7YgFq3t1UJWUWBt4GVcQJzSn2Yl2J7vnek4u\nt7kYrnhw44IBt8Oz2StRH89gulbplVCwJRimmkJQyhK73M2PfRwTOaDSjHqE0FA7\nt5JXK1zts2WyP6tZWtyUIDq6hSdvYjyxGffZ5kt810sjcyrk/TnOhFXRuiC5eoXX\nDfQWbk1o\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\nMIIDATCCAemgAwIBAgIURtJTQ4YzS/SJSsVG2pyuRg4tBg8wDQYJKoZIhvcNAQEL\nBQAwDzENMAsGA1UEAwwEUm9vdDAgFw0yNjA3MDMxMDExNTlaGA8yMTI2MDYwOTEw\nMTE1OVowDzENMAsGA1UEAwwEUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC\nAQoCggEBANLlP546TAp9/dns0xk482z0ZCVdBbh7BaMx4sY/4Mdu0RatYdp+6yL7\ndTzJJX3rb+NdsVbpozj/660DS1SN0osNa7Nm1cp2CXf39PdKJ5WrbY1UCuE5cD6n\nW7qFTLZR/52RnN0UoththnNyjurEf3m8GTtFOrfmH6qT6psZmgRefLh/OZT6PXUT\nZKPBHFhOr1YkuwO2D15pnRZ/2OBBkExsjyv5Y/m8IJfd+qK8rPrzJavRNEjfClfN\n3ScZEE1eOdrutuxRNpawEIB3gLfp/zWbZe/jMRyqrOAy1Bqy1JpwaeAJn96DShru\n6S8xim6PkvqY4mqOdTTCz/sgy/XLRicCAwEAAaNTMFEwHQYDVR0OBBYEFAaOIh36\ny0UgXPa9z7/hUwvaasqmMB8GA1UdIwQYMBaAFAaOIh36y0UgXPa9z7/hUwvaasqm\nMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBALqZN9Rk7LIPqjzb\nh3Z4iTVYdZXnUckPKVF0pH2Xx4R5Bcgb3XbptpRViisit3Ltwn8CfR7SYq4mYbnN\n/l3ty9neR1KPDtE8CgM1lLqw1t5iN+OW60S1cYlrJFGxGUdr5W9Z/toH9lDWCxsg\nT9+ooe+9hx4F8bw3Nnslt+FiDzbjMNOGxPzw7RZFV8n8JzxpIOaXO5quDSuoDdir\nkXV4FO0kl19EesaUyavy0Rc3sef8vyAvbT1CmjRd3LLpGWlaTrii0xVfq2YY7Jf7\n6Tb9fpJLOoAv4nWC82zZ0U94c7ffM4P+P7/qMO1R1PM0qHdsEo/O+FXwUdnkOwNs\n6+IZCAM=\n-----END CERTIFICATE-----\n```\n\nserver2.key\n```\n-----BEGIN PRIVATE KEY-----\nMIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQCY7k8ekjoME6rm\nzlkxs03+YkN5ykcmAh8qZnMgyygEmlfZ+vqA81i/S6fYkeLjqzsjq9unrvG7nf8g\nZxYkc/KQD++IsYxSD/LYA2XknuK6/+IwCovwJdToUEo7ysmiKUs+LjOB9/XUMA8i\n9oSZyg2JlGuyefNm9hIGFO766Omb4nwiIf4tKmSIFTiXVpI0/sfMQMX6lt/4QtHA\nNNwI3N1wTxARjkwEmXGvCE9dLHYFIgRjBzHgVhyy88/POxHaT5/OuLMuXEI+dPXp\nBD+43NxAcZ8cKasqpLa/kPofBMVjOwlSMvWfhzkU9k8c8Xn6GBWNvGuj+1SdjTZ0\nSRYCKT39AgMBAAECggEABa+oq/GSbHQHwPSvrtAkqH51VVAu1Iw0JfKwuamsF324\nof95tHU32ccBmuUTu1TYylL/xAyWatwtSgJjOaBBBte814eIeN2kcSExNu6sbfkJ\nKzGdMeTqNWgU1oPL+vZPmKSFoEG8t3LBAVMKq6AuYCzvUy/DG9Mu6OB64UPrObND\nneXZT8YZ2Ux0vEV9BAc0z+9tdWVjBy+l5ei6wpjhP69GZiVOsLmKTg/MDT4FN+Pi\nWJbyHcL1IKTRxxNxDPInBKhEMrxKKAABeXlp5nwnz0gkgUoxK3YHZmxAPr6yCcHP\nffeMjpE5BaRKzhimKrOJB4LUES24ltjo+5v5GmZzYQKBgQDSbhiNQpmhOk4ICzwJ\n8DMCAigaDm2cD/qC66OFrHhQfr7EC9MRKKC/8WlZYgNepxZ1ZM95+GJu5aTsh7d2\nHknwJkxkbTadfRcch9HQun68Y814G0LBDuDRRc9OnBQW6Gr4jTFDP+uqQl6gAfu4\nQOjATymrRa5S/21MkQ3Ryb5H4QKBgQC6DI1ETmfvXCOVpEUM9IjeEbiAjVYbUjBL\nGEOhE0izOv8mjSEgifMSEXJMn58F4nW/UoxtDobTAhQ/WO5BUVCEeQnOAXhV57jU\n/t/fBbdC7nrVnfFl9KmsOV3LcxUo0yE/x7UiHd1QlwtOTl1KPFQa9WpSehxjjQAS\nmHYM5PhJnQKBgQCIGHCEm/hkkCL7jNiNzO4QdHifMYmuj58DoYcm4z8FQJP8k3E0\n/cPJoEb0ajGnvAUIc+TEC+MNujSKTdRX7or/aKWrpf7WqJqT9zu59YQWL64p6eeo\nmQjKEI5dVxCfKD5W9mpQBj1S5o3wipfUuRZPmmNmxDBUuaJlDMOVVRddwQKBgCUl\nbmst8GiFEAHHq5W7mTwlc54PGhsYXNYRgSc+72wBooHy+aNCh8qauyR7VkfZgELz\n21/G37pvltVTDzbxYk8gz4lXF8ynGGtGfDJONNnjPZk7EMCXiez+AzEkyBu/k8rl\nN9AZAGAf2D0JPm0dAHnleBYBlXt24oXT9PX8HWqtAoGBALRX6V1U+bKwMih3N21b\n1w/ELI7L1BBAPqJxiQPSOa7kshamZgFenbH1wFLIXz6YwaEOOmYiId6lFjcJaBbF\n+R4HfxBhOuY6cvD0vEROIRntaqsj4zJXahlZZ9uG1EAYrY2tGKkCUMKN2IBE+WWS\n3YTH4WIOsCZriuaHIAyjsCcv\n-----END PRIVATE KEY-----\n```\n\n\u003c/details\u003e\n\nExpected behavior: The client will fail to establish the connection.\n\nActual behavior: The client succeeds in establishing the connection.\n\n### Impact\n\nXray-core from v26.1.13 to the latest version",
  "id": "GHSA-5wf9-h793-w73c",
  "modified": "2026-10-02T22:35:51Z",
  "published": "2026-10-02T22:35:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/XTLS/Xray-core/security/advisories/GHSA-5wf9-h793-w73c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/XTLS/Xray-core/pull/6472"
    },
    {
      "type": "WEB",
      "url": "https://github.com/XTLS/Xray-core/commit/64fada32b5b9e6ae064a038fa0e4e2b766499bd5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/XTLS/Xray-core"
    },
    {
      "type": "WEB",
      "url": "https://github.com/XTLS/Xray-core/releases/tag/v26.7.11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Xray-core: Pinning a CA certificate via pinnedPeerCertSha256 can lead to the success of MITM attacks"
}

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
3.8 (Low)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "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
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-6Q89-C966-C783

Vulnerability from github – Published: 2026-10-12 18:31 – Updated: 2026-10-12 18:31
VLAI
Details

Progress MarkLogic Server 12.x releases before 12.1.0 and 11.x releases before 11.3.7 do not consistently validate TLS certificate hostnames for certain outbound connections. A network-positioned attacker could exploit this weakness to intercept or modify communications with an affected service.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-85974"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-297"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-12T17:17:38Z",
    "severity": "HIGH"
  },
  "details": "Progress MarkLogic Server 12.x releases before 12.1.0 and 11.x releases before 11.3.7 do not consistently validate TLS certificate hostnames for certain outbound connections. A network-positioned attacker could exploit this weakness to intercept or modify communications with an affected service.",
  "id": "GHSA-6q89-c966-c783",
  "modified": "2026-10-12T18:31:57Z",
  "published": "2026-10-12T18:31:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-85974"
    },
    {
      "type": "WEB",
      "url": "https://community.progress.com/s/article/Marklogic-Critical-Security-Alert-Bulletin-October-2026"
    }
  ],
  "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"
    }
  ]
}

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"
}

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)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "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
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
7.1 (High)
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
Show details on source website
To clipboard 

{
  "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"
}
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