Threats tagged 'npm'

## Impact A vulnerability in `@payloadcms/plugin-form-builder` in versions < 3.90.0 allow submissions which could be crafted to execute remote code on the server. **You are affected if:** - You are using `@payloadcms/plugin-form-builder` ## Patches Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`.

### Impact An attacker who has read plus create or update access to a collection can submit a request that includes a SQL injection targeting a specific field path shape and operators in Payload's SQLite and Postgres. #### You are affected if: - You use `@payloadcms/db-sqlite` or `@payloadcms/db-d1-sqlite`. - You use `@payloadcms/db-postgres` or `@payloadcms/db-vercel-postgres` `< 3.73.0`. - A readable collection has a `json` field, or a` blocks` field with `blocksAsJSON: true`. - The attacker has read plus create or update access on it. #### You are not affected if: - You have no `json or `blocksAsJSON` fields. `richText` is not affected. - You run a patched version. ### Patches The patched version sanitizes the query input to prevent injection. Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`.

Payload is a free and open source headless content management system. In versions before 3.90.0 and canary versions before 4.0.0-canary.34, the server fails to enforce a field-level access.update restriction on the password field of an authentication collection. This issue is fixed in versions 3.90.0 and 4.0.0-canary.34.

Payload is a free and open source headless content management system. In versions from 3.0.0 before 3.90.0 and canary versions before 4.0.0-canary.34, a malformed multipart request body can cause multipart Content-Type processing to take an extremely long time, resulting in uncontrolled resource consumption. This issue is fixed in versions 3.90.0 and 4.0.0-canary.34.

PayloadCMS versions from 3.0.0 up to but not including 3.90.0, and canary versions from 4.0.0-canary.0 up to but not including 4.0.0-canary.34, contain a vulnerability where token refresh and password reset responses may expose hidden or read-restricted fields to unauthorized users. This exposure allows sensitive information leakage. The issue is resolved in versions 3.90.0 and 4.0.0-canary.34.

## Impact A readable collection could expose information about protected documents in a related collection. **You are affected if:** - You expose a readable collection with a relationship to a collection protected by access.read where constraints. ## Patches Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`. ## Workarounds There is no complete workaround. Upgrade Payload packages `>= 3.90.0` or `>= 4.0.0-canary.34`.

## Impact When using the Stripe payment adapter, an order confirmation could be processed more than once under certain conditions. You are affected if: - You use `@payloadcms/plugin-ecommerce` with the Stripe payment adapter. Deployments that do not use the Stripe payment flow are not affected. ## Patches Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`. ## Workarounds Ensure Stripe order confirmations can only be processed once. This is a temporary mitigation; upgrading to a patched version is recommended.

### Impact Users with read access to other user documents could access their active API keys. An exposed key grants the target account’s permissions until rotated or disabled. You are affected if: - An authentication collection enables `useAPIKey`. - Users have read access to other user documents containing active API keys. ### Patches Users should upgrade payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`. ### Workarounds Disable `useAPIKey` or restrict users to reading only their own authentication document. Rotate any API key that may have been exposed.

### 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`.

PayloadCMS versions before 3.90.0 and canary versions before 4.0.0-canary.34 contain a vulnerability in the optional Stripe REST proxy plugin. Authenticated users with access to this proxy can perform unintended Stripe operations. This issue is addressed in versions 3.90.0 and 4.0.0-canary.34.

### Impact A user with query access could use polymorphic join filters to infer hidden or read-restricted field values, including password-reset tokens. You are affected if: - You use an affected Payload version. - Users can query a collection with a polymorphic join to sensitive fields. ### Patches Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`. ### Workarounds There is no complete workaround. Restricting read access to sensitive collections reduces exposure but does not replace upgrading.

### Impact Under certain conditions, an attacker can craft a redirect link that sends a guest user to an untrusted destination after authenticating. ### Patches Users should upgrade Payload packages to `>= 3.88.0` or `>= 4.0.0-canary.27`. ### Workarounds Upgrading is recommended. Until then, remove user-controlled redirect values from authentication flows or restrict them to known local paths.

### Impact A user can submit a request that exploits a SQL Injection vulnerability in Payload. You are affected if: - You use an affected Payload version. - Untrusted users can query readable collections using dynamic filters or joins. You are not affected if you use MongoDB (`@payloadcms/mongodb`). ### Patches Users should upgrade Payload packages to `>= 3.88.0` or `>= 4.0.0-canary.27`. ### Workarounds Upgrading to a patched version is recommended. Until you can upgrade, restrict untrusted users from supplying dynamic query filters or join parameters and limit read access to affected collections.

PayloadCMS versions from 3.0.0 up to but not including 3.88.0, and canary versions from 4.0.0-canary.0 up to but not including 4.0.0-canary.27, contain a prototype pollution vulnerability in the @payloadcms/plugin-import-export plugin. This vulnerability allows unauthenticated users to submit prototype-sensitive field paths, leading to unintended application behavior and potential remote code execution. The issue is fixed in versions 3.88.0 and 4.0.0-canary.27.

### Impact Under certain conditions, an authenticated user could manage MCP API keys outside their intended account allowing an attacker to escalate privileges through account takeover. Applications that do not use `@payloadcms/plugin-mcp` are not affected. ### Patches Users should upgrade to `@payloadcms/plugin-mcp` version `3.88.0` or later. ### Workarounds Upgrading is recommended. Until then, disable the MCP plugin or restrict MCP API-key management to trusted users.

### Impact Under certain conditions, sorting readable records could reveal limited information about fields the requester was not permitted to read. You are affected if untrusted users can query a collection, control its sorting, and sort by protected fields. ### Patches Payload now applies field-level access checks to sort fields before executing queries. Users should upgrade to `>= 3.88.0` or `>= 4.0.0-canary.27`. ### Workarounds Upgrading is recommended. Until then, prevent untrusted users from controlling sort parameters or restrict their access to affected collections.

### Impact The password-hashing configuration used a lower work factor than what is recommended. ### Patches Payload now uses stronger password-hashing parameters and transparently upgrades older hashes following a successful login. Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`. ### Workarounds Upgrading is recommended. Until you can upgrade, protect database copies and backups from unauthorized access and require strong, unique passwords.

CVE-2026-105800 is a Server-Side Request Forgery (SSRF) vulnerability in the i18next-http-backend library. It occurs when an attacker controls the language or namespace input that is interpolated into the loadPath template, allowing injection of a colon character that causes the backend to request an unintended origin. This vulnerability affects versions of i18next-http-backend prior to 4.0.2 and was caused by an incomplete patch for a previous related vulnerability. The issue is fixed by rejecting colon characters in language and namespace values and ensuring URLs remain within the intended origin.

LangChain is a framework for building LLM-powered applications. Prior to 1.1.1, @langchain/redis does not escape attacker-controlled values in structured RediSearch TAG filters and structured RediSearch TEXT filters, allowing injected RediSearch syntax to alter or broaden the generated search query. When an application uses an attacker-influenceable filter as a tenant or document-access boundary, the modified query can expose indexed documents outside the attacker's intended scope. This issue is fixed in version 1.1.1.

The npm package @kxa/xbails version 0.0.5 is a malicious fork of the Baileys WhatsApp Web library that silently subscribes the victim's WhatsApp account to attacker-controlled channels without user consent. It achieves this by injecting code that issues an authenticated FOLLOW query using the victim's own WhatsApp session. The target channels are obfuscated or dynamically fetched to evade detection. This behavior does not involve credential theft, persistence, or arbitrary code execution.