| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A vulnerability has been identified in CPCI85 Central Processing/Communication (All versions < V5.40), SICORE Base system (All versions < V1.4.0). Affected devices allow a remote authenticated user or an unauthenticated user with physical access to downgrade the firmware of the device. This could allow an attacker to downgrade the device to older versions with known vulnerabilities. |
| The endpoint hosts a script that allows an unauthorized remote attacker to put the system in a fail-safe state over the network due to missing authentication. |
| On the exos 9300 server, a SOAP API is reachable on port 8002. This API does not require any authentication prior to sending requests. Therefore, network access to the exos server allows e.g. the creation of arbitrary access log events as well as querying the 2FA PINs associated with the enrolled chip cards. |
| An authentication bypass vulnerability has been identified in the REST and SOAP API components of Tripwire Enterprise (TE) 9.1.0 when TE is configured to use LDAP/Active Directory SAML authentication and its optional "Auto-synchronize LDAP Users, Roles, and Groups" feature is enabled. This vulnerability allows unauthenticated attackers to bypass authentication if a valid username is known. Exploitation of this vulnerability could allow remote attackers to gain privileged access to the APIs and lead to unauthorized information disclosure or modification. |
| The vulnerability allows an attacker to bypass the authentication requirements for a specific PAM endpoint. |
| Swissphone DiCal-RED 4009 devices allow a remote attacker to gain a root shell via TELNET without authentication. |
| CVE-2025-1701 is a high-severity vulnerability in the MIM Admin service. An attacker could exploit this vulnerability by sending a specially crafted request over the RMI interface to execute arbitrary code with the privileges of the MIM Admin service. The RMI interface is only accessible locally (listening on 127.0.0.1), limiting the attack vector to the local machine. This means that in a properly configured hospital environment, an attacker must have already compromised the network and additionally compromised the system where the MIM Admin service is running. From there, attackers with sufficient knowledge of MIM's implementation, library usage, and functionality with access to extend the MIM RMI library could force the MIM Admin service to run commands on the local machine with its privileges.
Users of MIM Software products exposed via RDP or multi-user application virtualization system should take note that the system being exposed is the environment hosting the virtualized MIM client.
This issue affects MIM Admin Service: before 7.2.13, 7.3.8, 7.4.3 |
| A vulnerability has been identified in which Rancher does not automatically clean up a user which has been deleted from the configured authentication provider (AP). This characteristic also applies to disabled or revoked users, Rancher will not reflect these modifications which may leave the user’s tokens still usable. |
| An unauthenticated remote attacker can gain full access on the affected devices as they are shipped without a password by default and setting one is not enforced. |
| A unauthenticated adjacent attacker could potentially disrupt operations by switching between multiple configuration presets via CAN. |
| An unauthenticated adjacent attacker could potentially disrupt operations by switching between multiple configuration presets via Modbus (RS485). |
| 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. |
| The MinigameCenter module has insufficient restrictions on loading URLs, which may lead to some information leakage. |
| The health module has insufficient restrictions on loading URLs, which may lead to some information leakage. |
| Tinycontrol LAN Controller v3 (LK3) firmware versions up to 1.58a (hardware v3.8) contain a missing authentication vulnerability in the stm.cgi endpoint. A remote, unauthenticated attacker can send crafted requests to forcibly reboot the device or restore factory settings, leading to a denial of service and configuration loss. |
| When configuring Arc (e.g. during the first setup), a local web interface is provided to ease the configuration process. Such web interface lacks authentication and may thus be abused by a local attacker or malware running on the machine itself.
A malicious local user or process, during a window of opportunity when the local web interface is active, may be able to extract sensitive information or change Arc's configuration. This could also lead to arbitrary code execution if a malicious update package is installed. |
| Missing Authentication for Critical Function vulnerability in ABB ALS-mini-s4 IP, ABB ALS-mini-s8 IP.This issue affects .
All firmware versions with the Serial Number from 2000 to 5166 |
| Ash Authentication provides authentication for the Ash framework. The confirmation flow for account creation currently uses a GET request triggered by clicking a link sent via email. Some email clients and security tools (e.g., Outlook, virus scanners, and email previewers) may automatically follow these links, unintentionally confirming the account. This allows an attacker to register an account using another user’s email and potentially have it auto-confirmed by the victim’s email client. This does not allow attackers to take over or access existing accounts or private data. It is limited to account confirmation of new accounts only. This vulnerability is fixed in 4.7.0. |
| An unauthenticated remote attacker who is aware of a MQTT topic name can send and receive messages, including GET/SET configuration commands, reboot commands and firmware updates. |
| A code injection vulnerability exists in Yonyou UFIDA NC v6.5 and prior due to the exposure of the BeanShell testing servlet (bsh.servlet.BshServlet) without proper access controls. The servlet allows unauthenticated remote attackers to execute arbitrary Java code via the bsh.script parameter. This can be exploited to run system commands and ultimately gain full control over the target server. The issue is rooted in a third-party JAR component bundled with the application, and the servlet is accessible without authentication on vulnerable installations. Exploitation evidence was observed by the Shadowserver Foundation on 2025-02-05 UTC. |
