| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A Local File Inclusion (LFI) vulnerability in OpenLLM version 0.6.10 allows attackers to include files from the local server through the web application. This flaw could expose internal server files and potentially sensitive information such as configuration files, passwords, and other critical data. Unauthorized access to critical server files, such as configuration files, user credentials (/etc/passwd), and private keys, can lead to a complete compromise of the system's security. Attackers could leverage the exposed information to further penetrate the network, exfiltrate data, or escalate privileges within the environment. |
| A security vulnerability was identified in Obsidian Scheduler's REST API 5.0.0 thru 6.3.0. If an account is locked out due to not enrolling in MFA (e.g. after the 7-day enforcement window), the REST API still allows the use of Basic Authentication to authenticate and perform administrative actions. In particular, the default admin account was found to be locked out via the web interface but still usable through the REST API. This allowed creation of a new privileged user, bypassing MFA protections. This undermines the intended security posture of MFA enforcement. |
| Versions of the package djoser before 2.3.0 are vulnerable to Authentication Bypass when the authenticate() function fails. This is because the system falls back to querying the database directly, granting access to users with valid credentials, and eventually bypassing custom authentication checks such as two-factor authentication, LDAP validations, or requirements from configured AUTHENTICATION_BACKENDS. |
| 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. |
| A vulnerability was reported in the Lenovo Scanner pro application during an internal security assessment that, under certain circumstances, could allow an attacker on the same logical network to disclose sensitive user files from the application. |
| The login mechanism via device authentication of CGFIDO from Changing Information Technology has an Authentication Bypass vulnerability. If a user visits a forged website, the agent program deployed on their device will send an authentication signature to the website. An unauthenticated remote attacker who obtains this signature can use it to log into the system with any device. |
| IoT Haat Smart Plug IH-IN-16A-S v5.16.1 is vulnerable to Authentication Bypass by Capture-replay. |
| On IROAD X5 devices, a Bypass of Device Pairing can occur via MAC Address Spoofing. The dashcam's pairing mechanism relies solely on MAC address verification, allowing an attacker to bypass authentication by spoofing an already-paired MAC address that can be captured via an ARP scan. |
| 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. |
| Successful exploitation of this vulnerability could result in the product failing to re-establish communication once the certificate expires. |
| The Electronic Official Document Management System from 2100 Technology has an Authentication Bypass vulnerability. Although the product enforces an IP whitelist for the API used to query user tokens, unauthenticated remote attackers can still deceive the server to obtain tokens of arbitrary users, which can then be used to log into the system. |
| Authentication Bypass by Spoofing vulnerability in 10up Restricted Site Access allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Restricted Site Access: from n/a through 7.4.1. |
| Click Studios Passwordstate Core before 9.8 build 9858 allows Authentication Bypass. |
| notion-go is a collection of libraries for supporting sign and verify OCI artifacts. Based on Notary Project specifications. This issue was identified during Quarkslab's audit of the timestamp feature. During the timestamp signature generation, the revocation status of the certificate(s) used to generate the timestamp signature was not verified. During timestamp signature generation, notation-go did not check the revocation status of the certificate chain used by the TSA. This oversight creates a vulnerability that could be exploited through a Man-in-The-Middle attack. An attacker could potentially use a compromised, intermediate, or revoked leaf certificate to generate a malicious countersignature, which would then be accepted and stored by `notation`. This could lead to denial of service scenarios, particularly in CI/CD environments during signature verification processes because timestamp signature would fail due to the presence of a revoked certificate(s) potentially disrupting operations. This issue has been addressed in release version 1.3.0-rc.2 and all users are advised to upgrade. There are no known workarounds for this vulnerability. |
| Vela is a Pipeline Automation (CI/CD) framework built on Linux container technology written in Golang. Prior to versions 0.25.3 and 0.26.3, by spoofing a webhook payload with a specific set of headers and body data, an attacker could transfer ownership of a repository and its repo level secrets to a separate repository. These secrets could be exfiltrated by follow up builds to the repository. Users with an enabled repository with access to repo level CI secrets in Vela are vulnerable to the exploit, and any user with access to the CI instance and the linked source control manager can perform the exploit. Versions 0.25.3 and 0.26.3 fix the issue. No known workarounds are available. |
| The session hijacking attack targets the application layer's control mechanism, which manages authenticated sessions between a host PC and a PLC. During such sessions, a session key is utilized to maintain security. However, if an attacker captures this session key, they can inject traffic into an ongoing authenticated session. To successfully achieve this, the attacker also needs to spoof both the IP address and MAC address of the originating host which is typical of a session-based attack. |
| 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. |
| 2N Access Commander version 2.1 and prior is vulnerable in default settings to Man In The Middle attack due to not verifying certificates of 2N edge devices.
2N has currently released an updated version 3.3 of 2N Access Commander, with added Certificate Fingerprint Verification. Since version 2.2 of 2N Access Commander (released in February 2022) it is also possible to enforce TLS certificate validation.It is recommended that all customers update 2N Access Commander to the latest version and use one of two mentioned practices. |
| 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. |
| Cognex In-Sight Explorer and In-Sight Camera Firmware expose
a proprietary protocol on TCP port 1069 to perform management operations
such as modifying system properties. The user management functionality
handles sensitive data such as registered usernames and passwords over
an unencrypted channel, allowing an adjacent attacker to intercept valid
credentials to gain access to the device. |
