| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Zebra before 6.4.0 contains an uncontrolled resource consumption vulnerability that allows unauthenticated peers to force full proof verification by serving forged block bodies with valid header hashes. Attackers can flip authorizing-only bytes such as a coinbase scriptSig, wasting Sapling, Orchard, and Ironwood proof verification without penalty and stalling sync for 67 seconds. |
| wolfSSH does not validate that the ECDSA curve identifier in a KEXDH_REPLY host key blob matches the algorithm negotiated during key exchange. In ParseECCPubKey() (src/internal.c), the blob's algorithm string is used to derive the curve via NameToId/wcPrimeForId without checking against the negotiated ssh->handshake->pubKeyId, and the RFC 5656 curve identifier string is discarded via GetSkip() rather than compared. An active network man-in-the-middle attacker can substitute a host key blob containing a different ECDSA curve, causing the client to import the key on the wrong curve. Because the attacker controls the private key for the substituted curve, signature verification passes. Exploitation requires an active MitM position and a lax public key check callback (e.g., TOFU, algorithm-name-only check, or fingerprint match against the parsed key). |
| Contrast 1.8.0 before 1.24.1 contains an improper verification vulnerability in Coordinator peer recovery that fails to confirm the serving peer uses the same manifest generation. Attackers with write access to manifest history can replay a superseded history head so withdrawn workloads obtain trusted mesh certificates, or with the secret seed disclose the Mesh CA key. |
| CWE-345: Insufficient Verification of Data Authenticity vulnerability exists that could allow modified firmware to be uploaded when an authorized admin user begins a firmware update procedure which could result in control over the device. |
| A flaw has been found in Insta InstaKNXServiceApp 1.2.3.1469. Affected by this issue is the function CreateWebClientAndDownloadFileList of the component Firmware Update Handler. Executing a manipulation can lead to insufficient verification of data authenticity. It is possible to launch the attack remotely. Attacks of this nature are highly complex. The exploitation is known to be difficult. There are still doubts about whether this vulnerability truly exists. The vendor explains: "[T]he entry suggests that the device does not verify the authenticity of the update. This is incorrect. The device performs an authenticity check after the complete update has been transferred. If this check fails, the update is not installed and the previously installed firmware continues to run". |
| An authenticated administrator could initiate an administrative import using a file whose contents were not fully verified, because the import validated only the file's header rather than the complete file. This could allow unverified or forged content to be accepted and processed, affecting the integrity of the imported data. |
| Unauthenticated Bypass Vulnerability in Pay With MetaMask For WooCommerce – Cryptocurrency Payment Gateway <= 1.7.2 versions. |
| A vulnerability was determined in InstantSoft icms2 up to 2.18.2. The affected element is the function validatePaypalOrder of the file system/controllers/billing/actions/paypal.php of the component Billing Module. Executing a manipulation of the argument bid/sig can lead to insufficient verification of data authenticity. The attack may be launched remotely. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way. |
| The Nexi XPay Build WordPress plugin through 7.6.2 does not correctly validate the security token on its payment notification route, accepting the request when the target order has no stored token, which allows unauthenticated attackers to mark arbitrary orders as paid, or to mark genuinely paid orders as failed. |
| The Airwallex Online Payments Gateway WordPress plugin before 1.36.0 does not verify that an incoming payment notification genuinely comes from the payment provider when no webhook secret has been configured, allowing unauthenticated attackers to forge one and mark orders as paid without paying. |
| Insufficient verification of data authenticity (CWE-345) in the external OIDC login callback in Cloud Foundry UAA v4.5.0 to v79.6.0 (inclusive) allows an authenticated UAA user to bypass the OAuth authorization-code exchange and establish an authenticated external-OIDC browser session, via submitting a UAA access token or a cross-client ID token as the callback’s id_token parameter.
The issue only manifests when a UAA zone is configured with an OIDC identity provider whose issuer exactly matches that zone’s own /oauth/token endpoint (a “self-UAA” OIDC configuration). In this configuration, the callback takes a supplied id_token directly instead of requiring the authorization code exchange, and does not verify that the token was actually issued as an ID token for the specific self-OIDC relying-party client. An attacker holding any valid UAA JWT for themselves — including a plain access token with only uaa.user scope, or a valid ID token issued to an unrelated client such as cf — can present it as the callback’s id_token and be authenticated into a mapped local (“shadow”) account. Because the resulting session is not verified against the originating token’s true audience or user_id, its effective privilege depends entirely on the shadow account’s group memberships, which can include administrative scopes such as clients.write.
Exploitation requires a valid UAA user JWT, a valid browser login state for the target zone, and the presence of a self-referential OIDC provider configuration — this is not a pre-authentication vulnerability, and does not by itself grant privileges beyond those already held by the mapped shadow account. |
| The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. Prior to 3.0.12 and 2.16.1, WebSocketHandler.upgrade aborts a handshake whose Sec-WebSocket-Accept value is missing or invalid but continues into pipeline installation and onOpen delivery. Frames coalesced with the invalid 101 response can be decoded and delivered from a peer that did not prove the handshake, although the request future fails and the channel closes. This issue is fixed in versions 3.0.12 and 2.16.1. |
| Postfix through 3.8.5 allows SMTP smuggling unless configured with smtpd_data_restrictions=reject_unauth_pipelining and smtpd_discard_ehlo_keywords=chunking (or certain other options that exist in recent versions). Remote attackers can use a published exploitation technique to inject e-mail messages with a spoofed MAIL FROM address, allowing bypass of an SPF protection mechanism. This occurs because Postfix supports <LF>.<CR><LF> but some other popular e-mail servers do not. To prevent attack variants (by always disallowing <LF> without <CR>), a different solution is required, such as the smtpd_forbid_bare_newline=yes option with a Postfix minimum version of 3.5.23, 3.6.13, 3.7.9, 3.8.4, or 3.9. |
| Dell SmartFabric Manager, versions prior to 2.2.1, contains an Insufficient Verification of Data Authenticity vulnerability. A low privileged attacker with remote access could potentially exploit this vulnerability, leading to Elevation of privileges. |
| Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. From 42.3.3 until 42.10.0, 43.5.0, and 44.0.0-beta.6, Electron's sandboxed preload code cache did not verify that a cached entry matched the preload it was served for. A compromised renderer could write attacker-controlled cache data and cause Electron to reuse it for a later load, executing the renderer's code in the more privileged preload context. The issue affects applications that load untrusted content. This issue is fixed in versions 42.10.0, 43.5.0, and 44.0.0-beta.6. |
| Vault's PKI secrets engine ACME server did not restrict certificate identities that ACME challenges do not validate when issuing certificates under the default directory policy. This may allow an ACME client to obtain a certificate containing unverified identity claims, potentially enabling impersonation toward systems that trust certificates issued by the affected Vault PKI mount. This vulnerability (CVE-2026-105818) is fixed in Vault Community Edition 2.1.2, and Vault Enterprise 2.1.2, 1.21.12, 1.20.17, and 1.19.23. |
| go-chi/chi versions 0.9.0 before 5.3.0 contains an IP spoofing vulnerability in the RealIP middleware, which resolves the request source IP (Request.RemoteAddr) using the first IP in the X-Forwarded-For header without validating trusted proxies. A malicious client can prepend a forged IP as the first value of the X-Forwarded-For header to spoof the request source IP, potentially bypassing access controls or falsifying request logs. |
| PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT PyJWKClient is affected because redirect destinations are not revalidated against the JWKS trust boundary. This occurs when a configured trusted JWKS endpoint returns an attacker-influenced redirect. As a result, PyJWKClient follows the redirect and consumes the redirected response as key material. Consequently, forwarded credentials may be disclosed or verification keys may be substituted. This issue is fixed in version 2.14.0. |
| This vulnerability exists in the ERP system due to improper validation of payment callback parameters and inadequate authentication controls in API endpoint. An unauthenticated remote attacker could exploit this vulnerability by manipulating the parameter to cause the application to establish an authenticated session for an arbitrary user without valid payment verification.
Successful exploitation of this vulnerability could allow the attacker to bypass authentication and gain unauthorized access to other user accounts on the targeted system. |
| MCP TypeScript SDK is the official TypeScript SDK for Model Context Protocol servers and clients. Starting in version 1.12.0 and prior to versions 1.31.0 and 2.2.0, the SDK's OAuth client support let the MCP server a client connected to decide which authorization server received the client's OAuth credentials. Stored and pre-provisioned credentials were not bound to the authorization server they belong to. A malicious or compromised MCP server could name its own authorization server in its protected resource metadata. Without any user interaction, the client would send that server the `refresh_token` and `client_secret` stored from an earlier sign-in (1.x), or the configured `client_secret` or signed assertion of a bundled non-interactive provider (1.x and 2.x). Only those applications that use the SDK as an MCP client over HTTP with an `authProvider`: your own `OAuthClientProvider`, or the bundled `ClientCredentialsProvider`, `PrivateKeyJwtProvider`, `StaticPrivateKeyJwtProvider` or (2.x) `CrossAppAccessProvider` and that may connect to an MCP server the owners does not fully trust while holding credentials for a legitimate authorization server are affected. `@modelcontextprotocol/sdk` 1.31.0 (1.x) and `@modelcontextprotocol/client` 2.2.0 (2.x) patch the issue. A workaround for those who cannot upgrade is available. 2.0.0 and 2.1.0 already accept `expectedIssuer`. On 1.x, the only workaround is to connect OAuth-enabled clients only to MCP servers you trust. |
