| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| CVE-2024-4320 describes a vulnerability in the parisneo/lollms software, specifically within the `ExtensionBuilder().build_extension()` function. The vulnerability arises from the `/mount_extension` endpoint, where a path traversal issue allows attackers to navigate beyond the intended directory structure. This is facilitated by the `data.category` and `data.folder` parameters accepting empty strings (`""`), which, due to inadequate input sanitization, can lead to the construction of a `package_path` that points to the root directory. Consequently, if an attacker can create a `config.yaml` file in a controllable path, this path can be appended to the `extensions` list and trigger the execution of `__init__.py` in the current directory, leading to remote code execution. The vulnerability affects versions up to 5.9.0, and has been addressed in version 9.8. |
| The AWS ALB Route Directive Adapter For Istio repo https://github.com/awslabs/aws-alb-route-directive-adapter-for-istio/tree/master provides an OIDC authentication mechanism that was integrated into the open source Kubeflow project. The adapter uses JWT for authentication, but lacks proper signer and issuer validation. In deployments of ALB that ignore security best practices, where ALB targets are directly exposed to internet traffic, an actor can provide a JWT signed by an untrusted entity in order to spoof OIDC-federated sessions and successfully bypass authentication.
The repository/package has been deprecated, is end of life, and is no longer supported. As a security best practice, ensure that your ELB targets (e.g. EC2 Instances, Fargate Tasks etc.) do not have public IP addresses. Ensure any forked or derivative code validate that the signer attribute in the JWT match the ARN of the Application Load Balancer that the service is configured to use. |
| 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. |
| An issue was discovered in Kurmi Provisioning Suite 7.9.0.33. If an X-Forwarded-For header is received during authentication, the Kurmi application will record the (possibly forged) IP address mentioned in that header rather than the real IP address that the user logged in from. This fake IP address can later be displayed in the My Account popup that shows the IP address that was used to log in. |
| 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. |
| 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. |
| The HttpAuth plugin in pGina.Fork through 3.9.9.12 allows authentication bypass when an adversary controls DNS resolution for pginaloginserver. |
| Use of fixed learning codes, one code to lock the car and the other code to unlock it, in the Key Fob Transmitter in Cyclone Matrix TRF Smart Keyless Entry System, which allows a replay attack.
Research was completed on the 2024 KIA Soluto. Attack confirmed on other KIA Models in Ecuador. |
| 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. |
| Improper Certificate Validation (CWE-295) in the Controller 7000 OneLink implementation could allow an unprivileged attacker to perform a limited denial of service or perform privileged overrides during the initial configuration of the Controller, there is no risk for Controllers once they are connected.
This issue affects Controller 7000:
9.30 prior to vCR9.30.250624a (distributed in 9.30.1871 (MR1)). |
| 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.*. |
| 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. |
| 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. |
| 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. |
| OTP is a set of Erlang libraries, which consists of the Erlang runtime system, a number of ready-to-use components mainly written in Erlang, and a set of design principles for Erlang programs. A regression was introduced into the ssl application of OTP starting at OTP-25.3.2.8, OTP-26.2, and OTP-27.0, resulting in a server or client verifying the peer when incorrect extended key usage is presented (i.e., a server will verify a client if they have server auth ext key usage and vice versa). |
| matrix-rust-sdk is an implementation of a Matrix client-server library in Rust. matrix-sdk-crypto since version 0.8.0 and up to 0.11.0 does not correctly validate the sender of an encrypted event. Accordingly, a malicious homeserver operator can modify events served to clients, making those events appear to the recipient as if they were sent by another user. This vulnerability is fixed in 0.11.1 and 0.12.0. |
| 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. |
| 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. |
| 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. |
| 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. |
