CVE Database

An attacker could take over a Looker account in a Looker instance configured with OIDC authentication, due to email address string normalization.Looker-hosted and Self-hosted were found to be vulnerable. This issue has already been mitigated for Looker-hosted. Self-hosted instances must be upgraded as soon as possible. This vulnerability has been patched in all supported versions of Self-hosted. The versions below have all been updated to protect from this vulnerability. You can download these versions at the Looker download page https://download.looker.com/ : * 24.12.100+ * 24.18.193+ * 25.0.69+ * 25.6.57+ * 25.8.39+ * 25.10.22+ * 25.12.0+

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.

AMI’s SPx contains a vulnerability in the BMC where an Attacker may bypass authentication remotely through the Redfish Host Interface. A successful exploitation of this vulnerability may lead to a loss of confidentiality, integrity, and/or availability.

In Progress Telerik Report Server, version 2024 Q1 (10.0.24.305) or earlier, on IIS, an unauthenticated attacker can gain access to Telerik Report Server restricted functionality via an authentication bypass vulnerability.

Emby Server < 4.7.12.0 is vulnerable to a login bypass attack by setting the X-Forwarded-For header to a local IP-address.

An attacker can abuse the batch-requests plugin to send requests to bypass the IP restriction of Admin API. A default configuration of Apache APISIX (with default API key) is vulnerable to remote code execution. When the admin key was changed or the port of Admin API was changed to a port different from the data panel, the impact is lower. But there is still a risk to bypass the IP restriction of Apache APISIX's data panel. There is a check in the batch-requests plugin which overrides the client IP with its real remote IP. But due to a bug in the code, this check can be bypassed.

In the case of instances where the SAML SSO authentication is enabled (non-default), session data can be modified by a malicious actor, because a user login stored in the session was not verified. Malicious unauthenticated actor may exploit this issue to escalate privileges and gain admin access to Zabbix Frontend. To perform the attack, SAML authentication is required to be enabled and the actor has to know the username of Zabbix user (or use the guest account, which is disabled by default).