| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Altair is a GraphQL client for all platforms. Prior to version 8.0.5, Altair GraphQL Client's desktop app does not validate HTTPS certificates allowing a man-in-the-middle to intercept all requests. Any Altair users on untrusted networks (eg. public wifi, malicious DNS servers) may have all GraphQL request and response headers and bodies fully compromised including authorization tokens. The attack also allows obtaining full access to any signed-in Altair GraphQL Cloud account and replacing payment checkout pages with a malicious website. Version 8.0.5 fixes the issue. |
| Agent Dart is an agent library built for Internet Computer for Dart and Flutter apps. Prior to version 1.0.0-dev.29, certificate verification in `lib/agent/certificate.dart` does not occur properly. During the delegation verification in the `_checkDelegation` function, the canister_ranges aren't verified. The impact of not checking the canister_ranges is that a subnet can sign canister responses in behalf of another subnet. The certificate’s timestamp, i.e /time path, is also not verified, meaning that the certificate effectively has no expiration time. Version 1.0.0-dev.29 implements appropriate certificate verification. |
| An Improper Certificate Validation on the UniFi iOS App managing a standalone UniFi Access Point (not using UniFi Network Application) could allow a malicious actor with access to an adjacent network to take control of this UniFi Access Point.
Affected Products:
UniFi iOS App (Version 10.17.7 and earlier)
Mitigation:
UniFi iOS App (Version 10.18.0 or later). |
| MicroWorld eScan AV's update mechanism failed to ensure authenticity and integrity of updates: update packages were delivered and accepted without robust cryptographic verification. As a result, an on-path attacker could perform a man-in-the-middle (MitM) attack and substitute malicious update payloads for legitimate ones. The eScan AV client accepted these substituted packages and executed or loaded their components (including sideloaded DLLs and Java/installer payloads), enabling remote code execution on affected systems. MicroWorld eScan confirmed remediation of the update mechanism on 2023-07-31 but versioning details are unavailable. NOTE: MicroWorld eScan disputes the characterization in third-party reports, stating the issue relates to 2018–2019 and that controls were implemented then. |
| SSL Verification Bypass vulnerabilities exist in ASPECT if administrator credentials become compromisedThis issue affects ASPECT-Enterprise: through 3.*; NEXUS Series: through 3.*; MATRIX Series: through 3.*. |
| Issue summary: Clients using RFC7250 Raw Public Keys (RPKs) to authenticate a
server may fail to notice that the server was not authenticated, because
handshakes don't abort as expected when the SSL_VERIFY_PEER verification mode
is set.
Impact summary: TLS and DTLS connections using raw public keys may be
vulnerable to man-in-middle attacks when server authentication failure is not
detected by clients.
RPKs are disabled by default in both TLS clients and TLS servers. The issue
only arises when TLS clients explicitly enable RPK use by the server, and the
server, likewise, enables sending of an RPK instead of an X.509 certificate
chain. The affected clients are those that then rely on the handshake to
fail when the server's RPK fails to match one of the expected public keys,
by setting the verification mode to SSL_VERIFY_PEER.
Clients that enable server-side raw public keys can still find out that raw
public key verification failed by calling SSL_get_verify_result(), and those
that do, and take appropriate action, are not affected. This issue was
introduced in the initial implementation of RPK support in OpenSSL 3.2.
The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue. |
| SSL Pinning Bypass in eWeLink Some hardware products allows local ATTACKER to Decrypt TLS communication and Extract secrets to clone the device via Flash the modified firmware |
| NeuVector supports login authentication through OpenID Connect. However, the TLS verification (which verifies the remote server's authenticity and integrity) for OpenID Connect is not enforced by default. As a result this may expose the system to man-in-the-middle (MITM) attacks. |
| A firmware downgrade vulnerability exists in the OTA Update functionality of GL-Inet GL-AXT1800 4.7.0. A specially crafted .tar file can lead to a firmware downgrade. An attacker can perform a man-in-the-middle attack to trigger this vulnerability. |
| This vulnerability affects NeuVector deployments only when the Report anonymous cluster data option is enabled. When this option is enabled, NeuVector sends anonymous telemetry data to the telemetry server.
In affected versions, NeuVector does not enforce TLS
certificate verification when transmitting anonymous cluster data to the
telemetry server. As a result, the communication channel is susceptible
to man-in-the-middle (MITM) attacks, where an attacker could intercept
or modify the transmitted data. Additionally, NeuVector loads the
response of the telemetry server is loaded into memory without size
limitation, which makes it vulnerable to a Denial of Service(DoS)
attack |
| An improper certificate validation vulnerability was reported in the Lenovo Universal Device Client (UDC) that could allow a user capable of intercepting network traffic to obtain application metadata, including device information, geolocation, and telemetry data. |
| PaperCut Print Deploy is an optional component that integrates with PaperCut NG/MF which simplifies printer deployment and management. When the component is deployed to an environment, the customer has an option to configure the system to use a self-signed certificate. If the customer does not fully configure the system to leverage the trust database on the clients, it opens up the communication between clients and the server to man-in-the-middle attacks.
It was discovered that certain parts of the documentation related to the configuration of SSL in Print Deploy were lacking, which could potentially contribute to a misconfiguration of the Print Deploy client installation. PaperCut strongly recommends to use valid certificates to secure installations and to follow the updated documentation to ensure the correct SSL configuration. Those who use private CAs and/or self-signed certificates should make sure to copy their Certification Authority certificate, or their self signed certificate if using only one, to the trust store of their operating system and to the Java key store |
| Akka.NET is a .NET port of the Akka project from the Scala / Java community. In all versions of Akka.Remote from v1.2.0 to v1.5.51, TLS could be enabled via our `akka.remote.dot-netty.tcp` transport and this would correctly enforce private key validation on the server-side of inbound connections. Akka.Remote, however, never asked the outbound-connecting client to present ITS certificate - therefore it's possible for untrusted parties to connect to a private key'd Akka.NET cluster and begin communicating with it without any certificate. The issue here is that for certificate-based authentication to work properly, ensuring that all members of the Akka.Remote network are secured with the same private key, Akka.Remote needed to implement mutual TLS. This was not the case before Akka.NET v1.5.52. Those who run Akka.NET inside a private network that they fully control or who were never using TLS in the first place are now affected by the bug. However, those who use TLS to secure their networks must upgrade to Akka.NET V1.5.52 or later. One patch forces "fail fast" semantics if TLS is enabled but the private key is missing or invalid. Previous versions would only check that once connection attempts occurred. The second patch, a critical fix, enforces mutual TLS (mTLS) by default, so both parties must be keyed using the same certificate. As a workaround, avoid exposing the application publicly to avoid the vulnerability having a practical impact on one's application. However, upgrading to version 1.5.52 is still recommended by the maintainers. |
| Multiple MFPs provided by Brother Industries, Ltd. does not properly validate server certificates, which may allow a man-in-the-middle attacker to replace the set of root certificates used by the product with a set of arbitrary certificates. |
| When the Amazon Redshift Python Connector is configured with the BrowserAzureOAuth2CredentialsProvider plugin, the driver skips the SSL certificate validation step for the Identity Provider. An insecure connection could allow an actor to intercept the token exchange process and retrieve an access token.
This issue has been addressed in driver version 2.1.7. Users should upgrade to address this issue and ensure any forked or derivative code is patched to incorporate the new fixes. |
| 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. |
| A vulnerability has been identified in Siemens License Server (SLS) (All versions < V4.3). The affected application does not properly restrict permissions of the users. This could allow a lowly-privileged attacker to escalate their privileges. |
| Calling Verify with a VerifyOptions.KeyUsages that contains ExtKeyUsageAny unintentionally disabledpolicy validation. This only affected certificate chains which contain policy graphs, which are rather uncommon. |
| An Improper Certificate Validation vulnerability could allow an authenticated malicious actor with access to UniFi Protect Cameras adjacent network to make unsupported changes to the camera system. |
| An insufficient certificate validation issue in the Palo Alto Networks GlobalProtect™ app enables attackers to connect the GlobalProtect app to arbitrary servers. This can enable a local non-administrative operating system user or an attacker on the same subnet to install malicious root certificates on the endpoint and subsequently install malicious software signed by the malicious root certificates on that endpoint. |