| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Ecosystem Agent version 4 < 4.1.5.2597 and Ecosystem Agent version 5 < 5.1.4.2473 did not properly validate SSL/TLS certificates, which could allow a malicious actor to perform a Man-in-the-Middle and intercept traffic between the agent and N-able servers from a privileged network position. |
| 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. |
| Successful exploitation of this vulnerability could result in the product failing to re-establish communication once the certificate expires. |
| Therefore Corporation GmbH has recently become aware that Therefore™ Online and Therefore™ On-Premises contain an account impersonation vulnerability. A malicious user may potentially be able to impersonate the web service account or the account of a service using the API when connecting to the Therefore™ Server. If the malicious user gains this impersonation user access, then it is possible for them to access the documents stored in Therefore™. This impersonation is at application level (Therefore access level), not the operating system level. |
| A vulnerability has been identified in Solid Edge SE2025 (All versions < V225.0 Update 11). Affected applications do not properly validate client certificates to connect to License Service endpoint. This could allow an unauthenticated remote attacker to perform man in the middle attacks. |
| Improper certificate validation vulnerability exists in 'デジラアプリ' App for iOS prior to ver.80.10.00. If this vulnerability is exploited, a man-in-the-middle attack may allow an attacker to eavesdrop on and/or tamper with an encrypted communication. |
| A replay attack vulnerability was discovered in a Zigbee smart home kit manufactured by Ksix (Zigbee Gateway Module = v1.0.3, Door Sensor = v1.0.7, Motion Sensor = v1.0.12), where the Zigbee anti-replay mechanism - based on the frame counter field - is improperly implemented. As a result, an attacker within wireless range can resend captured packets with a higher sequence number, which the devices incorrectly accept as legitimate messages. This allows spoofed commands to be injected without authentication, triggering false alerts and misleading the user through notifications in the mobile application used to monitor the network. |
| A flaw exists in the verification of application installation sources within ColorOS. Under specific conditions, this issue may cause the risk detection mechanism to fail, which could allow malicious applications to be installed without proper warning. |
| An issue in the TLS certification mechanism of Guardian Gryphon v01.06.0006.22 allows attackers to execute commands as root. |
| An Improper Certificate Validation vulnerability in the OPC-UA client and ANSL over TLS client used in Automation Studio versions before 6.5 could allow an unauthenticated attacker on the network to position themselves to intercept and interfere with data exchanges. |
| PingOne MFA Integration Kit contains a vulnerability related to the Prompt Users to Set Up MFA configuration. Under certain conditions, this configuration could allow for a new MFA device to be paired with a target user account without requiring second-factor authentication from the target’s existing registered devices. A threat actor might be able to exploit this vulnerability to register their own MFA device with a target user’s account if they have existing knowledge of the target user’s first factor credential. |
| An issue in Annonshop.app DecentralizeJustice/ anonymousLocker commit 2b2b4 allows attackers to send messages erroneously attributed to arbitrary users via a crafted HTTP request. |
| Instead of typical session tokens or cookies, it is verified on a per-request basis if the originating IP address has once successfully logged in. As soon as an authentication request from a certain source IP is successful, the IP address is handled as authenticated. No other session information is stored. Therefore, it is possible to spoof the IP address of a logged-in user to gain access to the Access Manager web interface. |
| PingOne MFA Integration Kit contains a vulnerability where the skipMFA action can be configured such that user authentication does not require the second factor authentication from the user's existing registered devices. A threat actor might be able to exploit this vulnerability to authenticate as a target user if they have existing knowledge of the target user’s first-factor credentials. |
| A vulnerability in the meeting-join functionality of Cisco Webex Meetings could have allowed an unauthenticated, network-proximate attacker to complete a meeting-join process in place of an intended targeted user, provided the requisite conditions were satisfied. Cisco has addressed this vulnerability in the Cisco Webex Meetings service, and no customer action is needed.
This vulnerability existed due to client certificate validation issues. Prior to this vulnerability being addressed, an attacker could have exploited this vulnerability by monitoring local wireless or adjacent networks for client-join requests and attempting to interrupt and complete the meeting-join flow as another user who was currently joining a meeting. To successfully exploit the vulnerability, an attacker would need the capability to position themselves in a local wireless or adjacent network, to monitor and intercept the targeted network traffic flows, and to satisfy timing requirements in order to interrupt the meeting-join flow and exploit the vulnerability. A successful exploit could have allowed the attacker to join the meeting as another user. However, the Cisco Product Security Incident Response Team (PSIRT) is not aware of any malicious use of the vulnerability that is described in this advisory. |
| Incorrect validation of OCSP certificates vulnerability in TheGreenBow VPN, versions 7.5 and 7.6. During the IKEv2 authentication step, the OCSP-enabled VPN client establishes the tunnel even if it does not receive an OCSP response or if the OCSP response signature is invalid. |
| The authentication mechanism on web interface is not properly implemented. It is possible to bypass authentication checks by crafting a post request with new settings since there is no session token or authentication in place. This would allow an attacker for instance to point the device to an arbitrary address for domain name resolution to e.g. facililitate a man-in-the-middle (MitM) attack. |
| The affected devices do not validate the server certificate when connecting to the SolaX Cloud MQTTS server hosted in the Alibaba Cloud (mqtt001.solaxcloud.com, TCP 8883). This allows attackers in a man-in-the-middle position to act as the legitimate MQTT server and issue arbitrary commands to devices. |
| go-witness and witness are Go modules for generating attestations. In go-witness versions 0.8.6 and earlier and witness versions 0.9.2 and earlier the AWS attestor improperly verifies AWS EC2 instance identity documents. Verification can incorrectly succeed when a signature is not present or is empty, and when RSA signature verification fails. The attestor also embeds a single legacy global AWS public certificate and does not account for newer region specific certificates issued in 2024, making detection of forged documents difficult without additional trusted region data. An attacker able to supply or intercept instance identity document data (such as through Instance Metadata Service impersonation) can cause a forged identity document to be accepted, leading to incorrect trust decisions based on the attestation. This is fixed in go-witness 0.9.1 and witness 0.10.1. As a workaround, manually verify the included identity document, signature, and public key with standard tools (for example openssl) following AWS’s verification guidance, or disable use of the AWS attestor until upgraded. |
| Auth0 Account Link Extension is an extension aimed to help link accounts easily. Versions 2.3.4 to 2.6.6 do not verify the signature of the provided JWT. This allows the user the ability to supply a forged token and the potential to access user information without proper authorization. This issue has been patched in versions 2.6.7, 2.7.0, and 3.0.0. It is recommended to upgrade to version 3.0.0 or greater. |
