CWE-345 vulnerabilities

AsyncHttpClient versions prior to 3.0.12 and 2.16.1 contain a vulnerability where the WebSocketHandler.upgrade method improperly processes WebSocket handshakes with missing or invalid Sec-WebSocket-Accept values. Although the handshake is aborted, the pipeline installation and onOpen event still proceed, allowing frames from an unverified peer to be decoded and delivered. This issue is resolved in versions 3.0.12 and 2.16.1.

HashiCorp Vault's PKI secrets engine ACME server had a vulnerability where it did not restrict certificate identities that were not validated by ACME challenges under the default directory policy. This could allow an ACME client to obtain a certificate with unverified identity claims, potentially enabling impersonation against systems trusting certificates from the affected Vault PKI mount. The issue is fixed in Vault Community Edition 2.1.2 and Vault Enterprise versions 2.1.2, 1.21.12, 1.20.17, and 1.19.23.

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.

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.

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).

### Summary In affected versions, the SDK's OAuth client let the MCP server decide which authorization server received the client's OAuth credentials. Credentials were not tied to the authorization server they belong to. A malicious or compromised MCP server could name its own authorization server. With no user interaction, the client would send it: - the `refresh_token` and `client_secret` stored from an earlier sign-in - the `client_secret` or signed assertion configured on a bundled provider ### Am I affected? Yes, if both of these hold: - your application uses the SDK's OAuth client over HTTP, through any of: - an `authProvider` on a transport - the `withOAuth()` middleware - direct calls to `auth()` or `fetchToken()` - it may connect to an MCP server you do not fully trust while holding credentials for a legitimate authorization server Affected versions: - `@modelcontextprotocol/sdk` 1.12.0 through 1.30.1 - `@modelcontextprotocol/client` 2.0.0 through 2.1.0, only for: - bundled providers without `expectedIssuer` - credentials stored or supplied without `issuer` - direct calls to `fetchToken()` - providers that read storage back through `OAuthTokensSchema` or `OAuthClientInformationSchema` Not affected: - MCP servers built with the SDK - stdio clients ### Fix Upgrade to: - 1.x: `@modelcontextprotocol/sdk` 1.31.0 or later - 2.x: `@modelcontextprotocol/client` 2.2.0 or later, and `@modelcontextprotocol/core` 2.2.0 or later if you import it directly The client now records the authorization server as `issuer` on saved credentials and does not send them to a different one. The user signs in again, or the call throws. In the following cases, upgrading to the patched version is not enough. You also need to make a change: - **Bundled providers** (`ClientCredentialsProvider`, `PrivateKeyJwtProvider`, `StaticPrivateKeyJwtProvider`, `CrossAppAccessProvider`): pass `expectedIssuer`, for example `expectedIssuer: 'https://auth.example.com'`. Without it they still use whichever authorization server the MCP server names. - **Credentials saved without `issuer`:** tokens and client information your `OAuthClientProvider` persisted (file, keychain, database) before upgrading, including everything 1.x saved before 1.31.0. They still go to whichever authorization server is named at first use. Add `issuer` to them, or clear them so users sign in again. - **Your own `OAuthClientProvider`:** save exactly what `saveTokens()` and `saveClientInformation()` are given, including `issuer`. For pre-registered credentials, include `issuer` in what `clientInformation()` returns. Not covered by this fix: - a new interactive sign-in, which still goes to the authorization server the MCP server names. Only complete sign-ins for servers you trust. - `refreshAuthorization()` and `exchangeAuthorization()` called directly - 2.x with `skipIssuerMetadataValidation: true` If an affected client may have connected to an untrusted MCP server, rotate its client secret or signing key and revoke its tokens. If you cannot upgrade yet, connect OAuth clients only to MCP servers you trust. 2.0.0 and 2.1.0 already accept `expectedIssuer`.

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.

Langflow is a tool for building and deploying AI-powered agents and workflows. From 1.5.0 until 1.10.3, an IP spoofing vulnerability in the Model Context Protocol (MCP) configuration installation endpoint (POST /api/v1/mcp/project/{project_id}/install) allowed authenticated remote attackers to bypass the "local-only" access restriction. By sending a spoofed X-Forwarded-For: 127.0.0.1 header, an attacker could make the server treat the request as originating from localhost, letting them write/overwrite an MCP client configuration file on the server's filesystem. This vulnerability is fixed in 1.10.3.

DigitalCanion has discovered a vulnerability in the backup restoration functionality that allows an attacker with access to the configured backup repository to introduce arbitrary files into the system during restoration. The specific flaw exists within the backup restoration mechanism, which fails to properly validate the paths, file types, integrity, and authenticity of files contained within a restored TGZ archive. The application does not perform file-signature verification before extracting the archive, allowing a specially crafted backup to contain attacker-controlled files. An attacker with access to the backup SFTP or other configured repository can therefore provide a malicious TGZ archive that, when restored by the system, may place arbitrary files on the underlying Linux system. Depending on the location and permissions of the extracted files, this behavior can potentially be leveraged to achieve arbitrary code execution with root privileges and compromise the underlying virtual machine. The absence of enforced backup passwords further reduces the protection provided by the backup mechanism and may facilitate unauthorized access to the repository.

CVE-2026-71887 is a vulnerability in Bouncy Castle for Java (BC-JAVA) versions 1.81 up to but not including 1.86. The high-level OpenPGP API improperly verifies cryptographic signatures by accepting a signing subkey that lacks the required embedded Primary Key Binding signature in its Subkey Binding signature, violating RFC 9580 requirements. This flaw allows an attacker to misattribute a genuine signature made by the victim's public signing subkey to an attacker-chosen identity, without forging a new signature or recovering private keys. The issue is fixed in version 1.86.

CVE-2026-85515 is a vulnerability in Bouncy Castle for Java before version 1.86 and certain LTS and FIPS editions that causes improper validation of integrity check values in OpenPGP encrypted messages. Specifically, truncated encrypted messages may be accepted without error, and on some code paths, no integrity check is performed at all, allowing altered ciphertext to be accepted as valid plaintext. This affects the SEIPD version 1 path more severely, where no integrity verification occurs, and the AEAD path where truncated chunks may be silently dropped without error. The issue has been fixed in versions 1.86, 2.73.13, 1.0.14, 2.0.14.1, and 2.1.14.

CVE-2026-103878 is a vulnerability in Apache Directory LDAP API versions from 2.1.0 up to but not including 2.1.9. It involves insufficient verification of data authenticity during a StartTLS extended operation initiated after a Search request, which can cause sensitive data to be transmitted in cleartext before the TLS handshake completes. This vulnerability is fixed in version 2.1.9.

CVE-2026-102140 is a vulnerability in Kiteworks Core where an authenticated administrator can import files without full verification of their contents. The import process only validates the file header, allowing unverified or forged content to be processed. This flaw affects data integrity but does not impact confidentiality or availability. The vulnerability affects Kiteworks Core versions prior to 9.5.1. The CVSS score is 4.9, indicating a medium severity level.

CVE-2026-55174 is a medium severity vulnerability in the shrec UltrafastSecp256k1 library prior to version 4.2.0. The issue involves insufficient verification of data authenticity in the ECDSA adaptor pre-signature verification process, where forged adaptor pre-signatures with an "r" value not cryptographically bound to the adaptor point "T" can be accepted. This flaw has been addressed in version 4.2.0.

An Editor can set file-provisioning metadata (the grafana.app/managedBy, grafana.app/managerId and grafana.app/sourcePath annotations) when creating a dashboard through the dashboard API, because these fields were stored without an authorization check. The dashboard then appears file-provisioned, and administrators can no longer update or delete it through Grafana. The impact is limited to the same organization and no data is exposed.

CVE-2026-102711 is an out-of-bounds read vulnerability in Eclipse ThreadX versions 6.0.1 through 6.5.2.202603. The vulnerability arises because the Module Manager loaders trust the sizes and offsets declared in a module image preamble without verifying the actual image length. A crafted module image can declare a larger code size than the actual image, allowing reading or accessing memory beyond the intended boundaries and placing entry points outside the legitimate code area.

PyJWT versions from 2.1.0 up to but not including 2.15.0 contain a vulnerability in the OKPAlgorithm.from_jwk function where the private JWK import does not verify that the public key component x corresponds to the private key component d. This can lead to a mismatch between the identity derived from x and operations performed with d. If an integration accepts private key parameters from a proof header without rejecting them, an attacker could misuse a stolen sender-constrained token without possessing the legitimate private key. The issue is fixed in version 2.15.0.