| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| MCP Java SDK is the official Java SDK for Model Context Protocol servers and clients. Prior to 1.0.0, the java-sdk contains a DNS rebinding vulnerability. This vulnerability allows an attacker to access a locally or network-private java-sdk MCP server via a victims browser that is either local, or network adjacent. This allows an attacker to make any tool call to the server as if they were a locally running MCP connected AI agent. This vulnerability is fixed in 1.0.0. |
| jq is a command-line JSON processor. Before commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784, jq used MurmurHash3 with a hardcoded, publicly visible seed (0x432A9843) for all JSON object hash table operations, which allowed an attacker to precompute key collisions offline. By supplying a crafted JSON object (~100 KB) where all keys hashed to the same bucket, hash table lookups degraded from O(1) to O(n), turning any jq expression into an O(n²) operation and causing significant CPU exhaustion. This affected common jq use cases such as CI/CD pipelines, web services, and data processing scripts, and was far more practical to exploit than existing heap overflow issues since it required only a small payload. This issue has been patched in commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784. |
| Acceptance of extraneous untrusted data with trusted data in Windows COM allows an unauthorized attacker to elevate privileges locally. |
| Inappropriate implementation in PDF in Google Chrome prior to 147.0.7727.55 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page. (Chromium security severity: Low) |
| OpenFGA is a high-performance and flexible authorization/permission engine built for developers and inspired by Google Zanzibar. In versions prior to 1.13.1, under specific conditions, models using conditions with caching enabled can result in two different check requests producing the same cache key. This can result in OpenFGA reusing an earlier cached result for a different request. Users are affected if the model has relations which rely on condition evaluation andncaching is enabled. OpenFGA v1.13.1 contains a patch. |
| Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Prior to version 1.4.0, Ed25519 signature verification accepts forged non-canonical signatures where the scalar S is not reduced modulo the group order (`S >= L`). A valid signature and its `S + L` variant both verify in forge, while Node.js `crypto.verify` (OpenSSL-backed) rejects the `S + L` variant, as defined by the specification. This class of signature malleability has been exploited in practice to bypass authentication and authorization logic (see CVE-2026-25793, CVE-2022-35961). Applications relying on signature uniqueness (i.e., dedup by signature bytes, replay tracking, signed-object canonicalization checks) may be bypassed. Version 1.4.0 patches the issue. |
| Botan is a C++ cryptography library. From version 3.0.0 to before version 3.11.0, during X509 path validation, OCSP responses were checked for an appropriate status code, but critically omitted verifying the signature of the OCSP response itself. This issue has been patched in version 3.11.0. |
| OneUptime is an open-source monitoring and observability platform. Prior to version 10.0.42, OneUptime's SAML SSO implementation (App/FeatureSet/Identity/Utils/SSO.ts) has decoupled signature verification and identity extraction. isSignatureValid() verifies the first <Signature> element in the XML DOM using xml-crypto, while getEmail() always reads from assertion[0] via xml2js. An attacker can prepend an unsigned assertion containing an arbitrary identity before a legitimately signed assertion, resulting in authentication bypass. This issue has been patched in version 10.0.42. |
| nimiq/core-rs-albatross is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Prior to version 1.3.0, an elected validator proposer can send an election macro block whose header.interlink does not match the canonical next interlink. Honest validators accept that proposal in verify_macro_block_proposal() because the proposal path validates header shape, successor relation, proposer, body root, and state, but never checks the interlink binding for election blocks. The same finalized block is later rejected by verify_block() during push with InvalidInterlink. Because validators prevote and precommit the malformed header hash itself, the failure happens after Tendermint decides the block, not before voting. This issue has been patched in version 1.3.0. |
| Side-channel information leakage in Navigation in Google Chrome prior to 147.0.7727.55 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
| Insufficient policy enforcement in History Navigation in Google Chrome prior to 147.0.7727.55 allowed a remote attacker who convinced a user to engage in specific UI gestures to inject arbitrary scripts or HTML (UXSS) via a crafted HTML page. (Chromium security severity: Low) |
| Inappropriate implementation in Navigation in Google Chrome prior to 147.0.7727.55 allowed a remote attacker who had compromised the renderer process to leak cross-origin data via a crafted HTML page. (Chromium security severity: Low) |
| Insufficient validation of untrusted input in WebSockets in Google Chrome prior to 147.0.7727.55 allowed a remote attacker who had compromised the renderer process to bypass same origin policy via a crafted HTML page. (Chromium security severity: Low) |
| When calling base64.b64decode() or related functions the decoding process would stop after encountering the first padded quad regardless of whether there was more information to be processed. This can lead to data being accepted which may be processed differently by other implementations. Use "validate=True" to enable stricter processing of base64 data. |
| Insufficient verification of data authenticity in Windows App Installer allows an unauthorized attacker to perform spoofing over a network. |
| Solstice::Session versions through 1440 for Perl generates session ids insecurely.
The _generateSessionID method returns an MD5 digest seeded by the epoch time, a random hash reference, a call to the built-in rand() function and the process id.
The same method is used in the _generateID method in Solstice::Subsession, which is part of the same distribution.
The epoch time may be guessed, if it is not leaked in the HTTP Date header. Stringified hash refences will contain predictable content. The built-in rand() function is seeded by 16-bits and is unsuitable for security purposes. The process id comes from a small set of numbers.
Predictable session ids could allow an attacker to gain access to systems. |
| A vulnerability has been identified in SINEC NMS (All versions < V4.0 SP3 with UMC). The affected application contains an authentication weakness due to insufficient validation of user identity in the UMC component.
This could allow an unauthenticated remote attacker to bypass authentication and gain unauthorized access to the application. (ZDI-CAN-27564) |
| OpenClaw before 2026.3.24 contains an arbitrary code execution vulnerability in local plugin and hook installation that allows attackers to execute malicious code by crafting a .npmrc file with a git executable override. During npm install execution in the staged package directory, attackers can leverage git dependencies to trigger execution of arbitrary programs specified in the attacker-controlled .npmrc configuration file. |
| MLFlow versions up to and including 3.4.0 are vulnerable to DNS rebinding attacks due to a lack of Origin header validation in the MLFlow REST server. This vulnerability allows malicious websites to bypass Same-Origin Policy protections and execute unauthorized calls against REST endpoints. An attacker can query, update, and delete experiments via the affected endpoints, leading to potential data exfiltration, destruction, or manipulation. The issue is resolved in version 3.5.0. |
| Flux notification-controller is the event forwarder and notification dispatcher for the GitOps Toolkit controllers. Prior to 1.8.3, the gcr Receiver type in Flux notification-controller does not validate the email claim of Google OIDC tokens used for Pub/Sub push authentication. This allows any valid Google-issued token, to authenticate against the Receiver webhook endpoint, triggering unauthorized Flux reconciliations. Exploitation requires the attacker to know the Receiver's webhook URL. The webhook path is generated as /hook/sha256sum(token+name+namespace), where the token is a random string stored in a Kubernetes Secret. There is no API or endpoint that enumerates webhook URLs. An attacker cannot discover the path without either having access to the cluster and permissions to read the Receiver's .status.webhookPath in the target namespace, or obtaining the URL through other means (e.g. leaked secrets or access to Pub/Sub config). Upon successful authentication, the controller triggers a reconciliation for all resources listed in the Receiver's .spec.resources. However, the practical impact is limited: Flux reconciliation is idempotent, so if the desired state in the configured sources (Git, OCI, Helm) has not changed, the reconciliation results in a no-op with no effect on cluster state. Additionally, Flux controllers deduplicate reconciliation requests, sending many requests in a short period results in only a single reconciliation being processed. This vulnerability is fixed in 1.8.3. |
