Jodit Editor: Prototype pollution via Jodit.configure() / ConfigMerge

Jodit Editor is a WYSIWYG editor with written in pure TypeScript file and image editing capabilities. In versions prior to 4.12.18, Jodit.configure(options) — and the internal ConfigMerge / ConfigProto helpers — merged user-supplied options into the editor configuration without filtering prototype-mutating keys, potentially causing a Prototype Pollution vulnerability. A payload nested under an existing plain-object option such as controls could reach and mutate Object.prototype. Applications that pass user-controlled or partially user-controlled configuration into Jodit.configure() may be vulnerable. This issue was fixed in version 4.12.18.

Prototype Pollution via Unfiltered Delta or JSON Patch Input in jsondiffpatch

Versions of the package jsondiffpatch before 0.7.6 are vulnerable to Prototype Pollution via the jsondiffpatch.patch() and jsondiffpatch/formatters/jsonpatch.patch() APIs. An attacker can perform prototype pollution by supplying crafted delta or JSON Patch documents, as attacker-controlled property names and path segments are used to traverse and modify objects without restricting access to special properties like __proto__ or constructor.prototype, allowing modification of Object.prototype.

n8n: Prototype Pollution enables confused-deputy execution via public webhooks

n8n is an open source workflow automation platform. Prior to 2.25.7 and 2.26.2, a prototype pollution vulnerability allowed a crafted public webhook payload to inject attacker-controlled fields into workflow data during internal object copying. These fields could be surfaced and consumed as normal values by downstream built-in nodes. Where a workflow combines a public webhook with action nodes that consume the resulting fields, an attacker could cause the workflow to act as a confused deputy — targeting unintended records or issuing outbound requests using the workflow owner's configured credentials. This vulnerability is fixed in 2.25.7 and 2.26.2.

Prototype Pollution in JetBrains YouTrack Websandbox Bridge Before 2026.2.16593

In JetBrains YouTrack before 2026.2.16593 the websandbox bridge was vulnerable to a prototype pollution attack

Style Dictionary - Prototype Pollution in convertTokenData utility function

Style Dictionary, a build system for creating cross-platform styles, has a prototype pollution vulnerability starting in version 4.3.0 and prior to version 5.4.4. Impact users have: direct usage of `convertTokenData(tokens, { output: 'object' });`; indirect usage, via using Expand API; and/or indirect usage via SD's transform lifecycle. Impact is high for this when style-dictionary is used as an integration in a NodeJS server application. Impact is moderate for when style-dictionary is used as an integration in a Web application. Impact is low for most common cases where the user of style-dictionary also maintains the tokens, and access is limited via read/write access to the repository/workflows where it is used. A patch has been published in version `5.4.4`. The only known workaround is to sanitize token data first. Whether using DTCG format or old Style Dictionary format, check the token data object recursively for any object keys that include `__proto__`.

n8n: Microsoft SQL Node Prototype Pollution

n8n is an open source workflow automation platform. Prior to 2.24.0, an authenticated user with permission to create or modify workflows could achieve global prototype pollution via the Microsoft SQL node by supplying a crafted value as the table parameter. This pollutes Object.prototype process-wide for the lifetime of the n8n server process, causing application-wide validation failures and rendering the n8n instance completely non-functional until restarted. This vulnerability is fixed in 2.24.0.

n8n: HTTP Request Node Pagination Prototype Pollution to RCE

n8n is an open source workflow automation platform. Prior to 1.123.43, 2.22.1, and 2.20.7, an authenticated user with permission to create or modify workflows could achieve global prototype pollution via an unvalidated pagination parameter in the HTTP Request node. Combined with other techniques this could lead to RCE on the instance. This vulnerability is fixed in 1.123.43, 2.22.1, and 2.20.7.

n8n: XML Node Prototype Pollution Patch Bypass

n8n is an open source workflow automation platform. Prior to 1.123.43, 2.22.1, and 2.20.7, an authenticated user with permission to create or modify workflows could bypass the patch for CVE-2026-42232 in the XML node. When combined with other nodes, this could lead to RCE on the n8n host. This vulnerability is fixed in 1.123.43, 2.22.1, and 2.20.7.

piscina: Prototype Pollution Gadget → RCE via inherited options.filename

piscina is a node.js worker pool implementation. Prior to 6.0.0-rc.2, 5.2.0, and 4.9.3, piscina's constructor and run() paths read the filename option via plain member access. Both reads fall through the prototype chain when the caller's options object doesn't have filename as an own property. When Object.prototype.filename is polluted upstream the inherited value flows to worker_threads.Worker import and the attacker's .mjs runs in the worker. This vulnerability is fixed in 6.0.0-rc.2, 5.2.0, and 4.9.3.

deepstream is vulnerable to prototype pollution

deepstream is a server that allows clients and backend services to sync data, send messages and make rpcs at scale. Versions prior to 10.0.5 are vulnerable to Prototype Pollution. Exploitation can lead to potential privilege escalation from any authenticated user with write permission to any record. This issue has been fixed in version 10.0.5.

Prototype Pollution Vulnerability in ThingsBoard Allows Arbitrary Code Execution for Tenant Administrators

ThingsBoard contains a prototype pollution vulnerability which may lead to arbitrary code execution within a sandboxed context by a user who can log in to the affected product with the tenant administrator privilege (TENANT_ADMIN).

billboard.js before 3.15.1 was discovered to contain a prototype pollution via the function generate, which could allow attackers to execute arbitrary code or cause a Denial of Service (DoS) via injecting arbitrary properties.

A prototype pollution in the lib.requireFromString function of module-from-string v3.3.1 allows attackers to cause a Denial of Service (DoS) via supplying a crafted payload.

Prototype Pollution in Progress® Telerik® KendoReact

In Progress® Telerik® KendoReact versions v3.5.0 through v9.4.0, an attacker can introduce or modify properties within the global prototype chain which can result in denial of service or command injection.

Winter vulnerable to Prototype Pollution in Snowboard framework

Winter is a free, open-source content management system based on the Laravel PHP framework. The Snowboard framework in versions 1.1.8, 1.1.9, and 1.2.0 is vulnerable to prototype pollution in the main Snowboard class as well as its plugin loader. The 1.0 branch of Winter is not affected, as it does not contain the Snowboard framework. This issue has been patched in v1.1.10 and v1.2.1. As a workaround, one may avoid this issue by following some common security practices for JavaScript, including implementing a content security policy and auditing scripts.

i18next-http-middleware missingKeyHandler does not reject keys whose segments contain prototype-polluting names

i18next-http-middleware is a middleware to be used with Node.js web frameworks like express or Fastify and also for Deno. In versions prior to 3.9.7, the missingKeyHandler blocked the literal request-body keys __proto__, constructor, and prototype (added in 3.9.3, see GHSA-5fgg-jcpf-8jjw), but did not reject dotted variants such as "__proto__.polluted". Downstream backends that split the missing-key string on a configured keySeparator (notably i18next-fs-backend ≤ 2.6.5) hand these keys to an unguarded setPath() walker that writes to Object.prototype. Applications that expose missingKeyHandler to untrusted input AND use i18next-fs-backend ≤ 2.6.5 are directly exploitable for remote prototype pollution. Other downstream backends that split the missing-key string the same way may be similarly affected. Depending on the host application, polluted prototype properties may cause crashes, corrupted translation behaviour, configuration poisoning, or bypasses of property-based security checks. This issue has been fixed in version 3.9.7. If developers cannot upgrade immediately, they should do the following: do not expose missingKeyHandler to untrusted users (mount it behind authentication, or remove the route), add a request-body filter ahead of the handler that rejects any top-level key containing __proto__, constructor, or prototype after splitting on their configured keySeparator, and disable missing-key persistence (saveMissing: false) when accepting writes from untrusted input.

i18next-fs-backend: Prototype pollution via crafted missing-key string

Versions prior to 2.6.6 are vulnerable to prototype pollution via crafted missing-key strings when used to persist missing translation keys (e.g. via i18next-http-middleware's missingKeyHandler exposed to untrusted input). Backend.writeFile() splits each queued missing-key string on the configured keySeparator (default .) before calling the internal setPath() walker. The walker (getLastOfPath in lib/utils.js) did not guard against unsafe segments, so a key like "__proto__.polluted" was split into ["__proto__", "polluted"] and walked straight into Object.prototype, allowing an attacker to write arbitrary properties onto the global object prototype. Depending on the host application, polluted prototype properties may cause crashes, corrupted translation behaviour, configuration poisoning, or bypasses of property-based security checks. Applications are affected only if the missingKeyHandler (or another route that forwards untrusted request bodies to i18next.t(..., { ... }) with saveMissing: true) is reachable by untrusted users and the default behaviour of splitting missing-key strings on keySeparator is in use (i.e. keySeparator is not false). Apps that do not expose missing-key persistence to untrusted input are not directly affected through this attack path. This issue has been fixed in version 2.6.6. If developers using the library are unable to upgrade immediately, they should take the following precautions: do not expose i18next-http-middleware's missingKeyHandler to untrusted users (mount it behind authentication, or remove the route), disable missing-key persistence (saveMissing: false, or no backend.create implementation) when accepting writes from untrusted input, and set keySeparator: false in their i18next options to disable backend key splitting (note: this also disables nested translation keys).

jsonata-js jsonata Function Binding Frame System jsonata.js createFrame prototype pollution

A weakness has been identified in jsonata-js jsonata up to 2.2.0. The affected element is the function createFrame of the file src/jsonata.js of the component Function Binding Frame System. This manipulation causes improperly controlled modification of object prototype attributes. It is possible to initiate the attack remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.

Apostrophe has Server-Side Prototype Pollution in apos.util.set via patch operators that leads to process-wide authorization bypass

ApostropheCMS is an open-source Node.js content management system. In versions up to and including 4.30.0, `apos.util.set()` traverses dot-notation paths without sanitizing `__proto__`, allowing an authenticated editor to write arbitrary values to `Object.prototype` via the `$pullAll` patch operator. A confirmed gadget in `publicApiCheck()` causes this to bypass authorization on all piece-type REST API endpoints for every subsequent unauthenticated request, for the lifetime of the Node.js process. As of time of publication, no known patched versions are available.

Axios: DoS & Header Injection via Prototype Pollution Read-Side Gadgets in axios merge functions

Axios is a promise based HTTP client for the browser and Node.js. Prior to 0.32.0 and 1.16.0, axios exposes two read-side prototype-pollution gadgets. When Object.prototype is polluted by an upstream dependency in the same process (e.g. lodash _.merge / CVE-2018-16487), axios silently picks up the polluted values. (1) lib/utils.js line 406 builds merge()'s accumulator as result = {}, so result[targetKey] (line 414) walks Object.prototype and the polluted bucket's own keys are copied into the merged headers and ride out on the wire. (2) lib/core/mergeConfig.js line 26 builds the hasOwnProperty descriptor as a plain-object literal. Object.defineProperty reads descriptor.get/descriptor.set via the prototype chain, so a polluted Object.prototype.get or Object.prototype.set makes the call throw TypeError synchronously on every axios request. This vulnerability is fixed in 0.32.0 and 1.16.0.